Thread Tools
This thread is privately moderated by Jack Crossfire, who may elect to delete unwanted replies.
Apr 22, 2014, 08:11 PM
Registered User
Jack Crossfire's Avatar
Thread OP
Discussion

Android programming becomes hard


when you need to make an app always persistent. This single need is what differentiates modern programming from the way things were done 15 years ago, when an app stayed in memory until the user hit exit. It makes it very hard to write a GPS logger, a stopwatch, or a groundstation.

The world of Intents, Services, IntentServices, Bundles, Binders is still a mystery. Most of the information is hidden on vogella.com, in which every page begins with a picture of some ugly head probably belonging to Vogella himself. His competitor is androidhive.info, on which every page begins with a picture of a guy in need of an attitude adjustment.

It feels like Google went through many ideas, while trying to solve the problem of app persistence. They may have originally allowed apps to stay persistent. The system now no longer makes anything persistent. Many of the structures that used to hint at persistence are no longer meaningful.

Nowadays, there is only 1 way to get persistence. You have to simulate it by setting a system alarm. The system alarm calls onStartCommand in an existing app Service. If the app was terminated, it reinstantiates it with everything set to null again. It's up to the app to detect it was restarted & reload its entire state from flash. Then the onStartCommand called by the alarm needs to set the alarm to call itself again & save its new state to flash.

It's an inefficient, bootstrapping way of keeping an app running. No matter what, if the operating system terminates your app, there's going to be a delay in the timing as everything is reinstantiated & restored from flash. The user has to manually hit an exit button to get the app to stop bootstrapping itself.

The mane problem is the need to store your entire state on flash during every alarm call. It requires lots of code beyond merely instantiating the data structures, to store the data structures on flash. Every tick of a seconds timer needs to be written. It can lead to millions of flash writes if it isn't optimized to store just the variables that changed. It's probably easier for a simple GPS logger, which just needs to append to a temp file. A map editor or an exercise timer with lots of data structures has a much harder job maintaining its state.

It's not clear if Intent.getExtras was intended as a way for an app to store its state between terminations, if it can store a complex data structure like a map, or if that too is reset to null. Nowadays, fuggedaboutit. Intent.getExtras just stores data in the current alarm call. For all the complex exchange of data from bundling & binding, it's been a lot simpler to pass around pointers.
Last edited by Jack Crossfire; Apr 22, 2014 at 09:38 PM.
Sign up now
to remove ads between posts


Quick Reply
Message:
Thread Tools