3 ms·

I'm assuming you're referring to the behavior where activities are restarted on rotation and onSaveInstanceState() gets called. This behavior is the default be

by tjohns 10y ago

I'm assuming you're referring to the behavior where activities are restarted on rotation and onSaveInstanceState() gets called. This behavior is the default because it prevents developers from needing to think about their UI changing dimensions (including runtime screen size/density changes!)... but it's certainly not required by the framework. If you set android:configChanges="orientation" in your application manifest, your app won't be automatically restarted. However, you'll become responsible for swapping out any UI resources at that point. (Keep in mind that Android lets you declare completely different UI layouts and drawables for different device configurations, so depending on how you wrote your app, you may need to re-inflate part of your UI.) Or just implement onSaveInstanceState() and let the OS do everything for you.

snuxoll 10y ago
Yet both Windows Mobile and iOS handle this flawlessly without having to wire all sorts of extra code up. Sure, it's possible to do it with Android, but it's a hell of a lot more work than any other platform.
BoorishBears 10y ago
>This behavior is the default because it prevents developers from needing to think about their UI changing dimensions (including runtime screen size/density changes!)... but it's certainly not required by the framework. No, the framework uses it to let you automatically handle those changes, the reason it's there is because early Android devices were weak (obviously) and the pipe dream was that we'd write apps that didn't mind randomly getting their processes killed as long as we used onSaveInstanceState... man-centuries later and it's clear the dream didn't pan out. I wonder how many billions of NPEs it was worth to be able to say Android does what iOS don't (multitasking) back then. And that android:configChanges line misses out on many other triggers that cause you to need to handle onSaveInstanceState (like someone plugging in a keyboard). Even with every flag set for configChanges you still need to implement onSaveInstanceState for process death to work as intended. The Android framework really is garbage. I might be biased though, I spent the day trying to trick it into not going to 7(!) FPS because our designers had the audacity to request we translate a video in an animation (and don't get me started on the insanity that is animations on Android [the X ways we've now gotten to do it which all have their own limitations]).

by tjohns 10y ago

snuxoll 10y ago

Yet both Windows Mobile and iOS handle this flawlessly without having to wire all sorts of extra code up. Sure, it's possible to do it with Android, but it's a hell of a lot more work than any other platform.

BoorishBears 10y ago

>This behavior is the default because it prevents developers from needing to think about their UI changing dimensions (including runtime screen size/density changes!)... but it's certainly not required by the framework. No, the framework uses it to let you automatically handle those changes, the reason it's there is because early Android devices were weak (obviously) and the pipe dream was that we'd write apps that didn't mind randomly getting their processes killed as long as we used onSaveInstanceState... man-centuries later and it's clear the dream didn't pan out. I wonder how many billions of NPEs it was worth to be able to say Android does what iOS don't (multitasking) back then. And that android:configChanges line misses out on many other triggers that cause you to need to handle onSaveInstanceState (like someone plugging in a keyboard). Even with every flag set for configChanges you still need to implement onSaveInstanceState for process death to work as intended. The Android framework really is garbage. I might be biased though, I spent the day trying to trick it into not going to 7(!) FPS because our designers had the audacity to request we translate a video in an animation (and don't get me started on the insanity that is animations on Android [the X ways we've now gotten to do it which all have their own limitations]).