Question

I am developing internal Android apps for the company I work for. In various places in the apps I need to connect to an internal server. This server is shutdown for maintenance for a period of time every night so there are times when it is not available. There may also be times when the wi-fi connection on the tablet drops.

If a tablet can't connect to the server (either due to wi-fi being down or because the server is down) I want the app to work in an offline mode - basically displaying data from the local database rather than getting live data from the server database. Also any data to be uploaded to the server should be queued until back online.

I am considering having a background service that runs a check every X seconds to see if the wi-fi is connected and if so, check if the server is available (via an HTTP HEAD request). It would then send out a broadcast to say if online or offline and other apps could receive this broadcast and save the connection status. Then whenever there is any activity in the apps requiring access to the server, they can check the status first and decide how to behave.

The downside to this is that the service would constantly be running in the background and could cause performance issues / battery drainage, although having done a little testing I haven't seen any evidence of this yet so I don't know whether it would actually ever be a problem.

So what I'm wondering is whether this method is a good idea or not and if there is a better way to check whether online or offline.

Was it helpful?

Solution

You are leaving the radios turned on practically the whole time and this will undoubtedly use up battery.

I do see your motivation, however. A decent compromise is to assume that the app is online unless it turns out not to be. If it turns out not to be, and it would like to be, then poll for a connection at long intervals, lengthening as time goes on. 1 second, 5 seconds, 15 seconds, 1 minute, 5 minutes, 15 minutes.

In addition, every time the app would - as a result of user activity - try to connect to the server, let it try. That will keep the "am I online?" status a little bit fresher, and there is a general principle in mobile app design that when radios are activated because the user asks for them to be, that is not a waste of battery.

Finally, if your UI can accommodate some sort of Refresh action (a button or a pull-down action) then by all means let that attempt to connect.

Note: iOS has the ability for an app to be notified by the operating system about a change in connectivity state. I don't know if there is something similar in Android. The nice thing about this is that the OS can decide when to do its connectivity checks (for example, when it has the radios on for something else already). Even so, that connectivity monitoring is only done when an attempt to contact the server has been made, and failed.

OTHER TIPS

Using a background service won't really help you. The problem is that after a succesful check for wi-fi and server you can't be sure that they are still online while you make your call to get the online data because they may went immediately offline after the succesful check.

A better alternative would be to just try to get the live data and if this fails use the local data. So you have always the same flow of your code.

Licensed under: CC-BY-SA with attribution
scroll top