@Frank Weiss I understand the difference between the two. The problem that I was trying to solve is that the behavior differs when an item is selected by the user versus by the program. When selected by the user, the appearance changes to reflect its selected state but when selected by the program it does not. In my program I select an item in the list and expected that when I did so, the appearance (in my case lighting up the radio button) would reflect its state of selection, but it did not, hence my post. If you are wondering why I would programmatically select an item in a list, it is because I am rearranging the list based on user input (Move Up and Move Down buttons) and I want the original item that the user selected to stay selected and for its appearance to reflect its selected state.
On Apr 8, 8:24 pm, Frank Weiss <[email protected]> wrote: > I kind of hate to butt into this laborious thread, but I want to add my 2 > cents. > > @DonFrench: IMO you have confused the behavior and the appearance of radio > buttons a bit. By behavior, I mean the underlying state of the control > group. The behavior is clearly 1-of N (although none selected is another > possible state). How that is displayed (appearance) is another matter. The > default appearance on Android seems to be two concentric gray circles, with > the inner one green to indicate the selected state. However, in principle, > the appearance of the selected state can be of almost limitless and creative > alternatives: > > 1) Bolded label > 2) Drop shadow to indicate 3-D depressed state > 3) Blinking text > 4) Darker or lighter background, or different color > 5) Arrow icon > 6) Underlined label > 7) Checkmark > 8) Square box with checkmark > 9) Open vs closed door icon > 10) How about a detent dial, like on classic stereo gear source selectors > etc. > > It's debatable whether a consistent appearance (or style) accross all > Android applications is better than the latitude of creative design. I'm > pretty sure that game developers want to have their own hallmarks. I think > describing the problem in terms of the behavior instead of appearence and > elaborate analogs would make the conversation about programming the darn > things much easier. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using "remove me" as the subject.
