-1

The title isn't good, please read bellow to understand better my problem

I have an Android application, one of its tasks is time consuming and will often take between 2-5 minutes to be finished... this task is done by a background service which has a reference to the starter activity.

99% of users doesn't want to wait all this time looking to a loading bar and will simple open another app or something like... what might lead to android destroying the referenced activity...

Ignoring the context leak of this story... my problem is:

When the service finishes its task it will try to call a method to return the values to the parent activity, but as it was destroyed now I can't do it...

So when user re-opens the app the last known state by that activity is "loading" so it keeps loading forever... (or retry to rerun the task what will lead to another 5 minutes wait and so on...)

how can i avoid this situation?

==============update=================

After getting a very good answer that would probably solve most of problems like mine i decided to add more information to let clear my problem.

The time consuming background service ISN'T process intensive, actually the reason it takes so long is because it is validating with the service some user "credentials" (when i say some, is really more than one)

So i can't store the result and trust it is valid on next run

I do know the this protocol needs to be improved but is going to take a bigger archtecture change so i would like to know if someone has any idea how to handle it on its actual requirements

Rafael Lima
  • 3,079
  • 3
  • 41
  • 105

1 Answers1

2

Is there a need to do run the background task every time your Activity starts?

Typically, if your Activity needs these values to work and it takes so long to calculate or fetch these values, you would store these values after the background service has finished with them.

Basically, you're creating a cache for your data. So when your Activity starts, it checks the cache for data. If it finds the data, then it loads it immediately. If it doesn't find the data, then it runs the background task (typically the initial run).

It's also common to have a timestamp of when the data was stored in your cache, so if time apart is too long, you could either:

  • Show the outdated data, while running the background task. Background task finishes and stores new data to cache, then notifies Activity that there's new data. Activity updates with the new data.

  • Don't show outdated data, instead, you wipe the cache of the old data and run the background task.

Basically, this solution simply has your Service store the values calculated into a storage location, whether it's a database, SharedPreferences, files, or etc.

You avoid the need to have your Service return values to an Activity, since there's no guarantee the Activity still exists. Instead, the Service only notifies the Activity that it added newly updated data to the storage location, so if the Activity still exists, it'll update without a problem. And if the Activity is killed already, then it'll simply fetch the data when it starts up again.

Jackey
  • 3,184
  • 1
  • 11
  • 12
  • your approach is very good but might not be the answer for me... please read the update – Rafael Lima Feb 12 '19 at 02:22
  • Credential Verification definitely can't be used with the answer I gave. At least, not on the client side. If it was reversed and you used the answer on the server side, where you cached the validated result, this would reduce the time to near instant. The server would just need to quickly check the user's ID to see if it was previously validated instead of doing it each time. This way, the trust in it's validity is based on your own servers rather than than the user's device. Sadly, I'm not sure if you can make such changes due to not knowing what changes you can make to your servers. – Jackey Feb 12 '19 at 04:07