Android: Run work on a separate thread and relay back to activity

[koeks525]

Hi MyBroadband Developers,

I have been having a lot of fun re-building my 4th year Android application, adding all sorts of extras that I left out in 2017.

Currently, when communicating with my Web API, I use JobIntentService, which, from my understanding, allows the developer to run short tasks in the background. Once the job is done, I send a broadcast back to the activity/fragment that registered to receive the specified broadcast.

I realized this morning that there is a problem with the way I am going about communicating with my API - A user could "minimize" the app and do other things on their phone. onStop is called, which unregisters the receiver, then onResume is called when the user goes back into the app (this registers the receiver). This will create situations where a task executes, it completes its work, it sends a broadcast but the broadcast is not received because the user may have the app "minimized"

So my question to the MyBroadband Developers is, what would be the best way to run network related tasks on Android in such a way it prevents the situation I described in the previous paragraph?

 

[scudsucker]

I'm not an Android dev but the description of the problem would suggest a queue, and indeed Android has MessageQueue which may work for you.

 

[_kabal_]

Look at RXjava. It really simplifies these issues in android

 

[zippy]

Be careful about creating an app that kills batteries and gives Android a bad rap. Every app on a mobile platform should be designed to work only when the user has it open, and I mean when the user KNOWS it’s open. Have you considered delegating the background network activity to a server instead? When the app is opened it can refresh it’s state from the server.

 

[[)roi(]]

A simple java.util.concurrent.Future will suffice for async tasks; RXJava can be a bit heavy weight for a beginner.

The future btw can be monitored:

• Linking in stream transformation and firing off a closures on completion and failure.
• Plus you can cancel the future if the device exits ready state e.g. locked, minimised, etc

Managing state transitions
As to how to handle the state transition is really going to depend on how you have architected state management in your app overall; or more specifically how to manage the state transitions between the views, controllers and models.

State / Action / Reducer pattern.
I like using the state / action pattern which essentially is a lightweight version of Redux and/or Flux that allows fairly easy decoupling of MVC:

• I either tie in a singleton for global app state including model data.
• or a state per MVC (Model / View / Controller)
• or a combination of both (it really depends on app complexity)

Basically we predefined set of app actions that can be dispatched, the use reducer(s) to merge the action(s) with the state store and finally add subscribers (essentially closures) that will perform continuation processing and / or UI updates when the state changes.

Here's a fairly simple write up on this: https://www.lestard.eu/2018/05/19/implement-your-own-redux-in-java/