Android apps - trouble in the transporter room
25/06/2014
by Greg Jotham: AQuA's Chief Quality Auditor
Since the earliest days of science fiction, the concept of teleportation – instantly moving a solid object from one place to another – has always been a popular plot device. Gene Roddenberry, who could be said to be one of the greatest popularisers of science fiction with his creation of Star Trek™, seized upon it as the solution to a problem: needing a space ship’s crew to visit a different planet every week, but not being able to afford multiple examples of the expensive special effects of it landing and taking off. Instead the series used lighting, camera tricks and some glitter to create the technology of the transporter room, and the idea entered popular consciousness, where it is now firmly lodged.
There was always one problem with this – in order to transmit something in this way, you have to disintegrate it at one end, and re-assemble it at the other.
So, if you were talking about live human beings, the drawback is that you were technically obliged to kill them before transporting them. Writers who depended on this plot device mostly dealt with the issue by the well-known technique of Let’s Not Talk About That Right Now, apart from a very few plots that required a (generally tragic) problem to arise.
On the occasions when the issue was addressed, it was clear that you needed to have a very, very good record indeed of what made up a person, in order to be able to put him or her back together at the end of the journey.
This has some interesting parallels in the world of Android applications. We’re used to apps just starting and running as we’d expect, and to them providing complex functionality in a multitasking environment.
There are, however, a small number of apps that create user complaints, because they completely go to pieces when you turn the device around, changing it from portrait to landscape orientation or vice versa. Connections fail, data built up is lost, and in the worst cases the screen display becomes seriously misaligned or corrupted. When doing performance testing with the AT&T ARO (AT&T Application Resource Optimizer) test tool, we’ve sometimes seen that apps that need to download data when they start, will download it all over again when the device is rotated.
Why does this happen? In many cases, because they’ve been through a badly-maintained transporter room.
To make it a little clearer ...
When you rotate an Android device from one orientation to another, you’re potentially making big changes to the environment in which the app is operating. The screen isn’t necessarily just exchanging how many pixels it can display in the X and Y coordinates – reserved areas like status bars and onscreen buttons have to be taken into account, and hardware specifics might stop this being a simple exercise in addition and subtraction. Plus, on some devices you might be swapping between a physical keyboard and a virtual one. By default, the Android OS deals with this in a very simple way – the application instance is destroyed, then recreated in the new environment. You’ve just put the app through the transporter. What you get out at the other end is completely dependent on how much of a record was kept of what state the app was in – if there are bits in the wrong places or parts missing, then the record wasn’t good enough.
Keeping a good enough record to get a complex app back in the same state as you left it is down to the developer – the OS only covers the basics. What this boils down to is finding tools and techniques that will help preserve state across the destroy / create divide.
Some relevant parts of the Android developer documentation may help with this:
Managing the Activity Lifecycle
http://developer.android.com/guide/components/activities.html#Lifecycle
Handling Runtime Changes
http://developer.android.com/guide/topics/resources/runtime-changes.html
Activity - config changes
http://developer.android.com/guide/topics/manifest/activity-element.html#config
These issues are also often discussed at length in forums like StackOverflow:
StackOverflow: Activity restart on rotation Android
http://stackoverflow.com/questions/456211/activity-restart-on-rotation-android?lq=1
And there are technical blog posts, like these examples covering detailed implementation of specific solutions:
Android Design Patterns - Handling Configuration Changes with Fragments
http://www.androiddesignpatterns.com/2013/04/retaining-objects-across-config-changes.html
devahead BLOG - Preserving the state of an Android WebView on screen orientation change
http://www.devahead.com/blog/2012/01/preserving-the-state-of-an-android-webview-on-screen-orientation-change/
The mistakes that can be made in development are mostly the things we don’t know we need to think about, especially when using emulators and always-on high-capacity WiFi networks that don’t reflect the real-life user environment. Real devices on real networks should always be used at some point in the development process, to be sure of a good user experience. AQuA recommends use of the Testing Criteria and the ARO test tool to get the best picture of whether your app is working efficiently, and to identify problems and their possible causes.
With a little science, and some attention to detail, it is possible to get the same app out of the orientation transporter that you put in – and the users will be happy instead of wondering how they suddenly got Frankenstein’s monster.
› back
