Use Application class with caution

Android gives us many opportunities to learn about the users and how they control the devices. In order to get this information, we have all kinds of callbacks and services starting from fragment lifecycle and ending with activity recognition API.

Of course, Android developers warn us to use all the various platform features appropriately. Nevertheless, it is quite easy to neglect the warnings and to be tempted to behave smarter, so that your app has the necessary information even before the user had actually requested it.

In order to keep users up to date, you need to implement some sort of synchronisation algorithm, which will retrieve data from the backend. Since network resources are relatively cheap and devices are powerful nowadays you may decide to make it simple. One option may be to check for updates when the app starts and then, according to some internal logic, while the app is active. You may also want your UX to be more friendly and thus you may introduce a broadcast receiver to listen to the network connection and update the UI to indicate connection is broken or is up again.

This is how your Application class may look like.

And here you can see the broadcast receiver registration.

Finally, The receive itself may contain a synchronization logic.

After the first live test the solution seems to work and the goal of keeping users up to date is achieved. There are even ways to improve it. You may check if your app data requires an update within your “connection change listener“. Let’s say with some exponential(relatively to the app opening) request logic.

Unfortunately,it’s a trap! While introducing Application class and a broadcast receiver for connectivity changes you have missed two critical warnings. „There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way.“ and regarding the broadcast receivers „A side-effect of this approach is that your app will wake the device each time any of these receivers is triggered — potentially much more frequently than required.”

In the case described above the application will be brought to live once connectivity changes. SinceMyApplication class is an entry point of the app, its onCreate() method is executed each time the app is woken up. The reason for it to start is the broadcast receiver, which is declared in the manifest. It listens to the connectivity changes not only when your app is active but ALL THE TIME while a device is on. So your app will be started each time the connection state alters.

  • Do not have any logic/hard work in your Application class except for initialisation (dependency graph)
  • Keep the data up to date only if it is the key of your business logic(messaging, news, etc.)
  • If keeping up to date is not critical but you still want to have it use platform sync adapters or push notifications to synchronise in a platform friendly way or indicate a refresh is needed.
We are always looking for talented developers, UI/UX designers and product managers, check out the latest openings here

We have recently spent 4 days developing 4 apps to help refugees during project #refugeeswelcome #hackweek15. More on the story here

Konstantin Shilovskiy

Android Developer HeyJobs (previously Memorado)