No Exit

While updating the Android version of PocketBible over the last couple of weeks, we took what we thought would be the non-controversial step of removing Exit from the action bar menu. In the light of some complaints, I thought I’d explain.

History

While the removal of the Exit function from PocketBible for Android seems abrupt and a step backwards in terms of giving users control over what’s going on on their device, the fact is that it’s the presence of the Exit function that is an anomaly.

Back in 1993-94 we experimented with Bible software on the Newton MessagePad. Including an Exit option on that platform was allowed, but the OS did a good job of managing memory without it and it wasn’t absolutely necessary.

Introduced in 1996, Palm OS discouraged apps from having a way to exit. It managed apps itself. Users weren’t supposed to think of “apps” so much as accomplishing a task. The idea of “launching” and “closing” were foreign to the “Zen of Palm”.

At about that same time, Windows CE was telling developers that mobile users didn’t need an explicit way to close their apps; the operating system would handle it. The app didn’t ever terminate itself; it was just told when it was about to be terminated, then it was terminated by the operating system.

iOS came along in 2007. Apple strongly discouraged developers from including any kind of exit functionality. Again, the OS managed memory better than the user could. Keeping apps around meant they launched faster.

Including the ability to exit an app was not recommended in Android (2008). Once again, the OS was better able to manage resources than the user.

So we come into last week’s decision to remove Exit from the action bar menu with a 30-year history of mobile operating systems discouraging or disallowing “exit” or “close” functionality in apps.

Benefits

The main advantage to the user of allowing the OS to manage running apps is that frequently used apps are more quickly and easily available.

Android facilitates this behavior by being able to intelligently decide which apps it should terminate to make memory or other resources available for the currently running app. It has ways of controlling how much CPU time is used by background apps so they can continue to work if necessary without affecting the responsiveness of the foreground app. (PocketBible doesn’t do any work when it’s in the background, but many apps do.)

Allowing Android to decide when to load and unload apps lets it more effectively manage battery life by minimizing loading activities and controlling background activities.

Android is able to predict which apps a user is likely to launch and keep them ready in memory as part of reducing launch time as described above. Similarly, it can terminate infrequently used apps when you’re done with them.

The Dark Secret

Don’t tell anyone, but that Exit option didn’t actually terminate PocketBible. What we did was programatically press the “back” button on the bottom of the screen while ignoring our own navigation history. So it was as if you had pressed “back” a dozen times to get past all the verses you had visited, then pressed it one more time to go back to the launch/home screen. We maintain your navigation history for your next session, of course, but internally that’s all we were doing.

Android has a “halt” method we can invoke to force the app to stop, but using it is strongly discouraged. It doesn’t allow for a controlled exit of the program and can cause data loss. So, yeah. Exit didn’t exit.

So How do I Exit the App?

Easy. You can exit PocketBible the same way you exit all your other apps, and with fewer screen taps than you were doing before. Just tap the “Home” button (or perform the “Home” gesture if that’s how you have it configured).

In other words, you could say we didn’t remove Exit, we just moved it to the bottom of the screen and made it look like a little circle. Yeah, that’s what we did — we just moved it to make it more convenient.

You’re welcome! 🙂