It is the correct behavior. A ListView selection is here only for **navigation** it is not meant as a persistent data selection tool. For this, you have to use ListView's choice mode. Think of ListView's selection as just a slightly different form of focus: it's there to allow phones with only a dpad/trackball to navigate through the list and click an element. Context-based actions are performed in Android using the contextual menus (or long click/long press.) No contextual action should be placed in the main menu (the one that appears with the menu key.)
If the user selects a list row, then somehow pops up a dialog, then dismiss the dialog, the list row will still be selected *unless* the user entered touch mode. This will definitely get rid of the ListView selection. So again, do *not* use ListView's selection as a persistent state: it is not, it's just a navigation tool for the user. Nothing more. On Sat, Sep 6, 2008 at 12:33 PM, Mark Murphy <[EMAIL PROTECTED]> wrote: > > Romain Guy wrote: >>> When you open the AlertDialog, the row in the ListActivity is no longer >>> selected. I'd argue this is a bug -- opening a dialog should not affect >>> the state of the underlying activity -- but there might be a good reason >>> the Android team did it this way. >> >> It is not a bug. There is only one selection/focused widget on screen >> at a time. Opening a dialog makes the underlying window loses the >> focus, and when a window doesn't have focus, it does not contain any >> selection or focused widget. > > The problem, though, isn't so much that "it does not contain any > selection", is that you positively get rid of the selection, thereby > changing the state. > > For example: > > -- Have a ListActivity with an option menu choice that displays a dialog > -- User selects a row in the list > -- User opens and closes the option menu -- the row is still selected > -- User opens the option menu and chooses the option that displays a > dialog, then cancels out of the dialog, with no code that modifies the > list contents -- the row selection is gone > > By doing this, you're delegating the Principle of Least Surprise to the > developer, since the user would not expect, for a no-change set of > actions, to have to re-select the row. And the developer's own Principle > of Least Surprise has failed, as the activity loses just as much focus > when the option menu is displayed as when the dialog is displayed, yet > the results differ -- in one case, UI state remains intact; in another > case, UI state is altered. > > Moreover, onSaveInstanceState() is not called before a dialog is popped > over the activity, meaning we have to roll our own state-saving logic to > deal with any state the act of popping a dialog will reset. > > Are you *sure* this is the correct behavior? > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com > Warescription: All titles, revisions, & ebook formats, just $35/year > > > > -- Romain Guy www.curious-creature.org --~--~---------~--~----~------------~-------~--~----~ 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] Announcing the new Android 0.9 SDK beta! http://android-developers.blogspot.com/2008/08/announcing-beta-release-of-android-sdk.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
