2

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.

Improve this question
2
  • 3
    Back when I was writing mobile apps I just made it a point to consider that the network might be unavailable for every call I'd make, so every server call was preceded with "is the network still there?". I'd also consider that every server call might time out and I'd code accordingly.
    – Dan Pichelman
    Jun 9, 2016 at 13:35
  • Yes, I was wondering about doing the check each time. Although even if I do a network check before each request I intend to still consider the possibility that the request might fail, whether it be because the server has just gone down, timeout or something else
    – omelette
    Jun 9, 2016 at 14:11

2 Answers 2

Reset to default
2

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.

Improve this answer
1
  • Although having the radios on all the time logically will use up battery, I have left a tablet doing a server check every 5 seconds for the last 16 hours and the battery only dropped about 5% which seems pretty minimal. Saying that, I'm all for doing things the most efficient way if I can and I'm interested in the idea about lengthening intervals. If I am always assuming a status of online whenever there is any user activity, are you suggesting I just do the polling at long intervals for the background data being uploaded?
    – omelette
    Jun 10, 2016 at 8:42
4

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.

Improve this answer
3
  • True, but if the background service tells me I'm offline, I will know not to waste time trying to access the server until the next 'online' broadcast from the service. I thought this might be helpful as the activities needing the data can go straight to the local database rather than trying the server, and also if I have data queued to be uploaded to the server in multiple apps I can pause these queues until online again
    – omelette
    Jun 9, 2016 at 14:01
  • 1
    So what will you do if the service tells you that you are online, you try to process the queue/getting data and what if at that moment the server or wifi is offline ? I guess you are switching to offline modus, aren't you ?
    – Heslacher
    Jun 9, 2016 at 14:03
  • Yes, even if I think I'm online, if a request to get data from the server fails I would effectively go to offline mode and fall back on the local data. If a job in the uploads queue failed I would keep retrying it.
    – omelette
    Jun 9, 2016 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.