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 -~----------~----~----~----~------~----~------~--~---
