I'm considering building my first iOS app in the following months. This is going to a hybrid app:
https://fanmixco.github.io/toastmasters-timer-material-design/
At this point is fully migrated to Android and Windows 10. However, one of my greatest challenges in Android was the screen rotation:
Why the android activity get's destroyed on rotation?
What is the advantage of letting an activity be destroyed on rotation?
This situation was quite complex to handle since each time my app was rotated the activity was destroyed and I needed to add several workarounds in order to keep the app running, restoring the previous states, colors, stop the timers before the rotation because they kept running in background, etc.
I didn't experience anything similar in Windows 10 and I'd like to know if the iOS View Life-Cycle behaves closely, are the views destroyed during the rotation of any device? Because my workarounds are reusable, but they add certain complexity and reduce performance.
These are some of the sites that I read:
iOS View Controller Life Cycle
View Controller Lifecycle iOS applications
iOS > Android: View Life Cycle
Nevertheless, I haven't found anything precise about this topic.
P.S.
I'd like to find if there is any documentation or examples since I invested a considerable amount of time in the Android Specific Situation to avoid finding at the last minute that I needed to reuse the workarounds.
I'm not sure if this question should be here or in Software Engineering. If I should move it just let me know and I'm going to do it.
When the screen is rotated the views are not destroyed. However it is re-laid out/re-drawn based on the constraints on the view. But this won’t destroy properties or mess with state on the view.
Related
I'm working on an app that doesn't support screen rotation. Do I really need to save the instance state of all my activities? How rare is it for android to kill activities? If the activity is killed and restored it will just look to the user as it did when they first came to it, which was probably quite a while ago anyway if the system has killed it. It doesn't seem like such a bad user experience to me if it is rarely going to happen. What do you think?
It is a catastrophic UX if an application loses its state just because I went to the settings to change the screen brightness. This happens frequently on 512MB RAM devices - which are still sold in large quantities. There are even devices with 256MB produced right now.
Yes, it happens a lot. It will happen to certain users much more frequent than to others. Those users will have no pardon with your app.
it really depends on the type of screens you are developing. When the activity contains a lot of data for example, it should be convenient to save the state of your activity (not all activities).
If you have several fields that the user must refill, it can be a bad experience especially if the virtual keyboard of device is not that easy (assume you are using a Galaxy mini for example)
In other words, it is a good practice but its up to you to decide if the user experience will be degraded or not
Serge
FWIW, I have written several single orientation apps for our current product and I feel that it's still important to save state. It just makes for a more usable application when everything is how you left it when you return.
In general, it's not that much work either. First, keep in mind that if you assign an ID to views in your layout's, the default Activity.onSaveInstanceState() will do most of the work. It will remember Checkbox states, EditText contents, etc. There are relatively few things you need to save. Here are some of the things I've saved with the state:
Relevant Activity parameters
ListView position information
Current Tab in TabView
Activity parameters are by far the most common.
As we know, android destroys and restarts an Activity when the user switches between portrait and landscape modes which we can prevent by overriding the onConfigurationChanged() callback. Can any one please explain to me what the actual need for the system to destroy and start the activity? Are there any side effects if I override onConfigurationChanged()?
While this behavior is really powerful, since your application adapts
automatically to the device's configuration at runtime, it is
sometimes confusing for new Android developers who wonder why their
activity is destroyed and recreated. Facing this "issue," some
developers choose to handle configuration changes themselves which is,
in my opinion, a short-term solution that will complicate their life
when other devices come out or when the application becomes more
complex. The automatic resource handling is a very efficient and easy
way to adapt your application's user interface to various devices and
devices configurations. It sometimes comes at a price though.
Ref: http://android-developers.blogspot.com/2009/02/faster-screen-orientation-change.html
The main purpose of restarting the Activity is because Android needs to change layouts, resources, etc. to adapt to the new screen orientation. As you may know, each orientation (usually) has its own Application Resources. The designers of Android decided it would be best to simply restart the Activity because so much reworking needs to be done in changing resources.
This is especially important after Honeycomb came out with the appearance of Fragments. Depending on your orientation, you can be displaying a completely different set of Fragments and associated sets of data.
I would strongly recommend against overriding onConfigurationChanged(). Instead, read the link HandlerExploit provided in his answer. It shows how to handle orientation changes more efficiently using onRetainNonConfigurationInstance().
I am developing an Android app. I have already crossed more than 20 Activities. So I am bit concerned about it. I mean if there are more Activities in an Android app, does it affect the performance of App like Speed, Memory or any other issue?
Though it is not a standard question but still I feel its something which might help others too
Yes Suraj more activities will affect performance
An activity is the equivalent of a Frame/Window in GUI toolkits. It takes up the entire drawable area of the screen (minus the status and title bars on top). Activities are meant to display the UI and get input from the user
An Activity (calling-Activity) can spawn another Activity (sub-Activity) in 2 ways:
Fire and forget – create an event (Intent) and fire it
Async callback – create an event (Intent), fire it, and wait for it’s response in a callback method (of the calling-Activity).
So the effect of activities will depend on performance of your device, its processor and memory etc.
Even if any activity will remain in stack and not finish then it affects device performance.
Even you have to take a look at security measures.
I'm wanting to use android:configChanges="orientation|keyboardHidden" for a few of my activities so that my onCreate doesn't get called again, but I thought I'd see if anyone had a list of pros and cons first because this link says that it should only be used as a last resort.
It's weird that Google doesn't really talk more about the reasoning behind it, but there are really three main reasons I can think of to avoid using that approach:
In my experience, some view types (particularly WebViews and MapViews on Android 2.1 or lower) can behave rather oddly after the orientation change if they haven't been recreated (zoom buttons mispositioned, for example).
It prevents you from using orientation-specific layouts (see the new Market app's landscape view, for example).
It can keep you from discovering buggy behavior from your application relating to other types of reasons your Activity might be destroyed and recreated (e.g. low-memory or other normal kills while backgrounded). That is, if your activity can gracefully handle a restart due to rotation, it can probably handle a restart due to background-killing. If you skip handling rotation, though, you may not encounter a restart due to background-killing under normal testing until a user with an older low-memory phone writes in with a bug report.
The last reason is the big one; especially with older low-RAM phones and with the supposedly more-aggressive autokilling behaviors in Gingerbread, your activities need to know how to quickly be recreated after a destruction by saving their state, regardless of orientation handling. And once your activities can handle those kinds of destruction/recreation, you're probably all set for rotation change kills anyways. You can gain some speed by absorbing the rotation event (since you don't have to go back through layout inflation and all that) but that's about all, at that point.
If you do decide to swallow rotations I highly recommend always using an emulator or device with the Development.apk's "Immediately destroy activities" option checked, and then making sure that switching apps or backing through your task stack still work correctly.
In my experience absorbing rotations can actually a good choice for an improved user experience, especially on activities with complex layouts that may take a few moments to recreate, but you really need to test carefully and effectively make sure that your activity would still work even without the rotation-ignoring.
A big Pro of using this approach is that it requires very little effort on your part, and that your app will survive config changes without resorting to crashes.
The small drawback is that using configuration specific resources (for landscape or portrait orientation) don't get applied automatically.
In my (perhaps little) experience, I think its not really worth the effort to do all the plumbing.
"Proper" handling of these config changes requires a lot of plumbing on your part, and things get even more dramatic if you have to support progress dialogs during screen orientation changes.
Although most people will opt for the quick fix by changing the manifest, and configuring their activity with android:configChanges=”keyboardHidden|orientation”, I think it’s important to realize that there are alternatives to this.
It requires more code, but it does give you better insight in how the overall system works.
I'm really struggling here, and it's holding me back.
What is the correct way to handle OpenGL, and an Activity - which launches sub-activities, or goes back to the home screen. And have it resume just exactly where it was.
I have it semi-working as it stands, textures/VBOs are reloaded at onResume() when needed.
But sometimes, when launching sub-activities and returning, or going to home screen and returning, onCreate is being triggered again. This messes up the whole thing, and I end up with a black screen.
I'm sure I'm doing the whole thing wrong. Can someone explain how one should handle an Activity like this?
What platform are you working with?
The reason I ask is that prior to Eclair this whole area was riddled with bugs with the result that suspending/resuming OpenGL basically only worked by accident. However, these do seem to have been fixed by Eclair and our app seems to be suspending and resuming fairly reliably.
What you're supposed to do is to register a callback to your SurfaceHolder so you get notified when the surface appears and disappears. In the surfaceDestroyed() method you shut down EGL completely, and then in your surfaceCreated() method you reinitialise it. You shouldn't be doing any of this from your Activity's onCreate()/onResume() methods, as the surface may not appear and disappear at the same time.
That said, our application was designed for Cupcake, when things were pretty primitive. I gather that these days there are utility classes available that do all the heavy lifting for you, so if you're using one of those things may work differently; and if you're not, you may want to look into them.