Open-event-droidgen: Inconsistent app state if download interrupted

[iamareebjamal]

Actual Behaviour

Currently, if the first download is interrupted, the app goes in an inconsistent state where the next app launch will assume the data is downloaded

Expected Behaviour

This is simply due to the step at which the shared preference of the data downloaded is stored. It is set to true as soon as the user presses Yes on download data dialog, whereas it should be set to true when the complete data is downloaded

Steps to reproduce it

• Uninstall app or remove data
• Click Yes when prompted to download data
• Interrupt download before completion by exiting the application
• Re-enter application

Would you like to work on the issue?

Yes
@the-dagger @mananwason Shall I send the PR?

[arp95]

@iamareebjamal
data download is happening on a separate thread. so even if i exit the app the process of downloading should go on right?

[iamareebjamal]

No. That's not true. Threads are attached to the process, so they are ended too when process exits.

[arp95]

@iamareebjamal
i dont think you are right.
when we use async task the process keeps on going on despite exitng or something else. As this is a similar thing it should go on and thus wont exit.

[iamareebjamal]

Try exiting the app while download is going on.

[mahikaw]

@iamareebjamal I tested this on my phone too. Seems like a valid bug :+1:

[Ronak-59]

I too faced the same issue. What I did is, Cleared the data of app, restarted it again. When it prompted for data download, I clicked on "yes". Then after a moment, I turned off my wifi switch and closed the app. Now when I restarted the app, the data is not syncing. All the tracks shows "No Sessions yet!"

[arp95]

i dont have the problem with the issue. its just that if the process occurs on a background thread the process never exits.
anyways the issue seems valid.

[iamareebjamal]

We are removing listeners and binding the asynchronous tasks to activity lifecycle. Running async tasks such that process doesn't exit until it is completed is a memory leak situation. As soon as the activity is destroyed, all its instances must be garbage collected in the next GC run and if a background task is holding it as a strong reference, then it may not be garbage collected, hence, causing a memory leak. So in order to prevent that, we explicitly make sure that background tasks do not continue when activity is destroyed. Some libraries like Picasso do it via WeakReference. Furthermore, keeping the task running may even crash the application as when it is completed, it will try to update the UI, which is destroyed, hence causing an anonymous crash