We are developing an Android application, where there is a need to upload several photos to our server in an asynchronous way. Consider that as soon as a picture is taken, it will start being uploaded. As soon as it has finished being uploaded, the next one (all of them will be placed in a queue) will start being uploaded.
However, it is also important to support cancellation functionality, meaning that the user can interact with the app in a way that will remove an image from the queue or even cancel a running upload.
After searching for possible solutions, we have come to the following possible scenarios:
1) Use an IntentService for the queue mechanism and implement our own logic inside it. However, there are some worries as to how easy it is going to be to support cancellation.
2) Use the SD card and a local database to store the files and a Service to check for new files. This has been described here:
Android (or iOS) - Image Upload Queue
3) Find a way to use the built-in Android DownloadManager for uploads (can it really be done?)
4) Use AsyncTask and isCancelled() function.
5) Or ideally find another built-in Android/Java mechanism to do all of the above in a seamless way.
Any ideas?
Related
Our app needs to download files with the following requirements:
User can dynamically add or cancel downloads
Files are downloaded one at a time
Sometimes in background we need to schedule several file downloads
It would be nice to display a notification displaying download progress and a cancel button
We had all this implented in a foreground service that would maintain a queue of tasks and having an aidl interface with methods that allowed to enqueue new downloads or cancel active/enqueued.
Since Android 12 we can no longer start foreground service when the app is in background, so we can't reliably download files anymore in this situation (requirement #3)
As far as I can understand, the recommended way of implementing such task is using WorkManager, but I can't find a good way of doing it.
I consider two approaches, but both are far from perfect:
Every downloaded file is a separate Work. It's easy to cancel when needed and we only need to suply a file URL and that's it.
But the downsides are: there's no way to enqueue several downloads at once (requirement #3), we need to wait for previous work to finish and then enqueue the next one.
Using ExistingWorkPolicy.APPEND doesn't help here - our downloads are independent and if one is cancelled or fails, others should stay in the queue.
Another annoying issue with this approach is that if we display a notification from our ListenableWorker via startForeground(), then for each file download it will be shown and hidded instead of just updating its contents for every new downloaded file.
Use a long running ListenableWorker that would download many files. But this requires somehow delivering enqueue and cancel(fileUrl) messages to the running worker instance (what we did previously using our service with the aidl/binder stuff). As far as I can see, the WorkManager API doesn't support anything like that. So the only thing we can do is to use some static vars to deliver those messages, which would work (if our worker works in the same process as the main app - hopefully, I can rely on that). But using statics in such a way is always kind of a code smell, I would avoid it if possible.
Are there any other possibilities to do this using WorkManager? Maybe I'm missing some part of the API?
I have a question regarding on how mobile OSs such as iOS and Android work regarding a cancelled download. I was wondering if there is any guaranteed way to restore a download from the point where it was cancelled.
I do understand that for instance iOS does not provide access to its temporary downloaded files, but you could continue a download as long as you were using
cancel(byProducingResumeData ..)
However, there is no guarantee that the resumed data will still be available at the moment you start the download again. Furthermore, there is an overload in storing this checkpoint in case the app is terminated meanwhile.
I was wondering if there is a way to provide some sort of custom URLCache to the URLSessionConfiguration so that the temporary files of a download are stored at a location (on disk maybe) where it is certain to have access if you try to start the download again.
Same question for Android: is the data flushed on cancel or there is a nice controlled way to go back to it?
I have the requirement of downloading several images and videos and the requirement entails "one time" download so there isn't really any caching required and that's why I am not using Volley. Volley for videos could be expensive.
Next, I stumbled upon built-in Android's DownloadManager which seems to facilitate downloads on a queue, the API doesn't seem bad overall but I was wondering how it might compare to using a Service with a ScheduledThreadPoolExecutor(an option dictated by one of the Commonsware's post)?
Note: My use case is strictly not that of downloading images for a grid with chances of repeated requests. My requests have to be single time downloads only. The request may be a mix of few images and videos.
Could the ScheduledThreadPoolExecutor inside Service be significantly faster?
I was wondering how [DownloadManager] might compare to using a Service with a ScheduledThreadPoolExecutor
DownloadManager does not require your process to be running, and it handles all of the issues with retry policies and so forth. On the other hand, DownloadManager:
Requires that the download be initiated from a simple URL (i.e., no session cookies)
Shows the user the results via the Downloads app
Can only easily download to external storage
Downloads one item at a time
May delay the download start for a while (e.g., if something else is being downloaded)
ScheduledThreadPoolExecutor is unlikely to be part of an in-process solution, though a ThreadPoolExecutor might. That would only be necessary if you needed to try downloading N videos at a time and you didn't want to use any multi-threading option offered by your HTTP client API (e.g., OkHttp). Since you want to download these things in the background (presumably), and you do not know what the user is doing in the foreground, I recommend only downloading one video at a time, so you do not make it difficult for the user to use the Internet from whatever is going on in the foreground.
Could the ScheduledThreadPoolExecutor inside Service be significantly faster?
You are comparing apples and asteroids.
Neither ScheduledThreadPoolExecutor nor Service perform HTTP downloads. An in-process HTTP client API (HttpUrlConnection, OkHttp, Volley, etc.) performs HTTP downloads, as do some out-of-process options (notably DownloadManager).
A proper comparison would be between DownloadManager and the combination of:
An in-process HTTP client API, and
Some form of service, to allow the download to go on even if the user navigates away from your UI
From a pure speed standpoint, any HTTP client API will be limited by the network and so should perform roughly equivalently. Volley is not well-suited for large downloads because it puts the entire result in memory, and you don't have heap space for a video. Other options will let you stream the results to a file.
I have a use case where I want to download some files from the server and store them locally before starting another activity that is dependent on this file. This kind of design can be found on karaoke kind of applications where clicking on one song would
Load the required files from the server
Once the download is finished, open the required activity.
Let us assume that my app is a karaoke app. My question is how to design this flow. Basically, on clicking on one song, I want to show progress on the screen and when the download is finished, I want to move to the activity. Another requirement is that once I am inside the karaoke activity screen and playing a song, I have an option which leads to loading of another lesson. If a user uses that option, I want to again download the required files. Based on this requirement, should I:
Have the file loading thing as a separate activity?
OR
It can be used as Fragmentinside the activity where I choose a particular song. In this case, once entering the karaoke screen, if I choose an option which leads to downloading some files and reloading of this activity, is this the best design?
I would recommend two different approaches depending on how long you plan on keeping the data that you've downloaded. If it is single use than a bound service would be ideal. However, if you are planning on keeping the downloaded content for more than a single use, I would recommend you use a content provider and possibly a sync adapter(Depending on how frequent/predictable content downloading is). This combo would help guide you into not having to think about the 'design' as much(Since it is pretty standard at this point), plus it would provide a lot of features that you may/may not find useful: you can make your internal data 'public' via the content provider/authority(s), you can make an 'account' on the phone associated with your app so that the user can manage its syncing via the sync manager(actually via widgets/apps using the sync manager, but still), and most importantly a set of clean(ish)/standard means to interact with it/propagate UI, etc.
My simple version would be an Activity that spawns either a async-AIDL service with callback (which is in my opinion the only way to use a bound service) that would allow you to asynchronously design your 'starter' activity, its "currently downloading" spinner (which can get progress updates via the callback if you design it that way). Then once the download is complete then send the results (via a parcel file descriptor in the Intent's bundle) to the new activity that makes use of it.
However, if you are planning on using the data more than once, I'd recommend downloading the content like you did above, but then also store it in a content provider for easy access later. Providers also have a lot of nice associated functionality related to cursor loaders, etc. that will help keep a list of the content currently being stored nice and clean/up-to-date/dynamic/etc. However, this is a lot more work to setup once, then later it would save you time in reduced.
A sync adapter is best when the data to be downloaded is predictable, either based on user's account or temporally (such as someone having an account to download data from (email account, etc.) or when the target is fairly constant, but the data should be updated every hour or so(such as the current weather)). So this will depend a lot on your application's exact specifics.
Here is an assignment for an Android App Development course I wrote that is an even more simplified version of the first option (it has intent service + broadcast receiver for returning download results back to the Activity). Obviously since this is an assignment it has sections cut out to make skeleton code, but the documentation is ABSURDLY detailed and should be fairly easily implemented.
https://gitlab.com/vandy-aad-3/aad-3-assg-2/tree/master
Here is the extension of that assignment for that same course that focuses on implementing a simple content provider's 4 main methods (Create, Read, Update, & Delete). Everything else about the provider is given to you.
https://gitlab.com/vandy-aad-3/aad-3-assg-3/tree/master
Obviously the content being downloaded in both applications is probably not what you intended, but that is a simple swap to replace in what you do want.
Not to shill to hard, but here is the (free) Specialization that this course is a part of: https://www.coursera.org/learn/androidapps
Point one : Don't download video file within the Activity level. You can start a Service to handle it. Once the download function is finished you can start the second Activity. While download function is in progress you can show a ProgressBar
Point Two : Best Design is show a ProgressBar with percentage to user. Or disable the function. After download complete enable or start the second activity.
I am writing an Android application that interfaces with a RESTful service. This web service essentially fronts a file system, and provides metadata as well CRUD access to the files. My application retrieves the metadata, and exposes it to 3rd party apps through a ContentProvider.
I need to add the ability for 3rd party applications, running on the same device as my app, to CRUD the actual files by making requests to/from my app (not directly with the server). This means they need to either send or receive the contents of the files (which are typically XML or images) through my app.
I have thought of two approaches for implementing this:
Option 1 - Using ContentProvider.openFile
This seems like an obvious choice for giving 3rd party applications the ability to read files from my ContentProvider. I think it starts getting tricky when those applications need to create or update files through my `ContentProvider'. I'll need a callback when they are finished in order to know when to send the new/changed file back to the server. I believe I could use a FileObserver for that purpose though.
Option 2 - Using a Messenger through a Service
With this approach, I can send the files between my application and client applications through the Messenger. The files would have to be passed through a Bundle, so I am not sure what the best format is for transmitting them (File, FileDescriptor, byte array, something else??). I don't have a good handle on whether or not this would cause problems if the files get to be large.
Option 3 - a hybrid approach
Use folder(s) on external storage as a drop box
Communicate CRUD requests, and drop box contents, through a Messenger/Service
Use the ContentProvider to store the status of requests
3rd party app receives status updates through a ContentObserver
Summary
I think using ContentProvider would be the ideal solution, but it seems that the API does not fully support my use case. I am concerned that trying to go down that path might result in a kludgy implementation. If I go with a Messenger and Service approach, I am uncertain of the most robust way to transfer the files through a Bundle.
The hybrid approach seems pretty robust, but the most complex to implement. Files aren't actually being passed around, so performance should be good. However, I fear this is over-architecting the solution.
What is the best approach for transferring files between applications running on the same Android device? Of course, I am open to other options which I have not outlined in my question.
Content provider is definitely the way to go. If you consider that google uses this approach for almost everything then it becomes appaentr that this is the intended design method.
I'm not extolling the virtues of them, but in the land of the blind, the one eyed content provider is king.
Update
There is an example of how to do this in CommonsWare book, see the link provided.
Source of Content Provider/Files
Use the synch framework for content providers. Simply maintain a list of requests and then schedule the sync to download those file. You can also do this on network tickles etc. you can use broadcast intents or contentobserver to notify clients that the file is downloaded.
In essence this is probably similar to your 3rd option but importantly it uses the Android supplied tools rather than rolling your own.
Ad Endum
Best place to start is the android SDK sample in: android-sdk\samples\android-8\SampleSyncAdapter but be warned that there's a load of contacts related stuff that masks the juicy bits. It took me a while to figure out that I could delete almost all of it except the syncadapter
http://developer.android.com/reference/android/os/ParcelFileDescriptor.html can be sent between processes. I believe that there is a subtly where these are explicitly blacklisted from being allowed to be put in intents. They can be sent through AIDL though.
Also, do NOT use the sdcard for this. This is just asking for trouble. One sdcard is world readable, so anyone can see it. Also, you do not always have access to write to the sdcard (it is removed or put in UMS).
Using the SD card is definitely the recommended way to go to share files on Android.
However, I would go with a modified hybrid solution which makes use of startActivityForResult() and onActivityResult() (docs here) on the client side to communicate CRUD requests (and getting the Uri to the file(s) on the SD card if needed) if you don't mind creating a dummy activity as a front end to your service. Clients, once finished with the file(s), can call startActivityForResult() again to alert your app to changes.
Of course this can be done with startService()/bindService() however it doesn't provide an easy way for clients to obtain a status result especially if you need IPC.
Although content providers/resolvers feel like the correct way to go about things, I do feel it is more for single direction requests specific to providing/consuming content.