| GitHub Issue | n/a |
|---|
| Type | Bug |
|---|
| Priority | Medium |
|---|
| Status | Closed |
|---|
| Resolution | Invalid |
|---|
| Resolution Date | 2011-06-30T08:28:24.000+0000 |
|---|
| Affected Version/s | Release 1.7.0 |
|---|
| Fix Version/s | Sprint 2011-26 |
|---|
| Components | Android |
|---|
| Labels | 3.0, android, pixelated, radio_button, xoom |
|---|
| Reporter | Natalie Huynh |
|---|
| Assignee | Bill Dawson |
|---|
| Created | 2011-04-29T16:35:03.000+0000 |
|---|
| Updated | 2011-07-11T12:08:05.000+0000 |
|---|
Steps to Reproduce:
1. Launch Kitchen Sink
2. Run Controls > Picker > Basic Picker
3. Select Picker to see the radio button options
Actual Result:
The radio button looks pixelated
Expected Result:
The button should be more sharp
That's what the "classic" Android native Spinner looks like in Honeycomb. KitchenSink runs on Honeycomb in compatibility mode, which means controls that contain their own styling, like the Spinner (what we call "Picker"), use styling based on pre-Honeycomb versions of Android. Those styles are ugly on Honeycomb. We can't yet make KitchenSink a true Honeycomb-styled app for a few reasons: * We would need to change *a lot* of KitchenSink code to get it to look decent. (You'll see an example of this coming up.) * We can't assume that our users (i.e., app developers using Titanium SDK, not end-users) have the Honeycomb-ready Android Platform & SDK tools installed. Specifically, I'm not sure how the build-time tools would react to
android:targetSdkVersion="11"in the AndroidManifest.xml if they are old tools. (ThattargetSdkVersionthing is how you tell an app that it can run in full Honeycomb mode on Honeycomb tablets, rather than in compatibility mode. If you compile and run KitchenSink targeting Honeycomb instead of compatibility mode, the picker (Spinner) selection list looks nice -- see attached ks_honey.png. But that screenshot also shows you that the button that is supposed to say "Set to Grapes" looks like crap <--- that's the kind of thing we'd have to deal with in many places before allowing KitchenSink to run outside of compatibility mode. Basically: a) KitchenSink needs to be largely re-written. b) To enable apps to run in full Honeycomb-supported mode *by default*, we would need to tell our user community that we henceforth assume they all have SDK Tools level 11 and Platform Tools level 5, just as we now tell them they must have API level 7. We need a bigger ticket for this stuff, not just one targeting the radio button, so I'll be discussing with Don.