hey... ditto.
cheers. On Jun 9, 2:08 pm, Chronos <[email protected]> wrote: > hmmm... no relevant input ? not even some comments ? > > On 28 Mai, 10:20, Chronos <[email protected]> wrote: > > > Hello there ;) > > > I am still confused about configuration changes. I considered this a > > bug in earlier API versions and didn't care much about it. But since > > this behaviour is still the same in the 1.5 SDK, I wonder if I do not > > misunderstand something completely... :/ > > > If I want to handle a change of orientation on a device, I should be > > setting android:configChanges="orientation" in the manifest and > > implement the onConfigChanged() method of the corresponding activity. > > We have already read several times that we also have to listen for > > "keyboardHidden" changes on the G1. BUT I FAIL TO UNDERSTAND WHY ! And > > it seems, there are others who don't understand this... > > > If my application does not care whether a keyboard is exposed or not - > > why should I be listening for it at all ? I can assume two cases in > > which this is going to cause serious trouble: > > > - If more than "orientation|keyboardHidden" changes at once, > > onConfigurationChanged() won't be called. Assume, a user crosses > > country borders (MCC change) in exact the same moment, he changes > > orientation... onConfigurationChanged() won't be called - the > > application is broken :(. > > - Let's assume an upcoming device has some other configuration > > property linked to orientation (which programmers don't know in > > advance) - perhaps orientation and touchscreen, because a device has > > some weird and limited type of touchscreen - onConfigurationChanged() > > wouldn't be called either; the application would be broken and must be > > adapted to that device. This rudely offends the resource abstraction > > paradigma of the android platform. > > > In conclusion, to overcome this "design bug" (as I see it now), I > > would have to listen for ALL configuration changes since I don't know > > which devices (especially device configurations) will be used in the > > future. This makes the configChanged property useless. But > > unfortunately there is no "all" constant available for > > android:configChanges and I am not able to enter numeric constants (a > > bitmask); if in a later version of the android API another > > configuration value is to be introduced, my workaround doesn't work > > and my application is broken again D:. > > > Please prove me wrong or help me clarify this, before there are LOTS > > of different devices out there... Thanks in advance ;) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
