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?
What is the modern (2019) approach to download media (Images, videos, audios, etc...) from URL with Kotlin?
Apparently there are a lot of different mechanisms you can use in terms of background fetching:
Service
JobService
IntentService
JobScheduler
BroadcastReceiver
AsyncTask
DownloadManager
PoolExecutors
As well as any possible combination of these and maybe others not even listed here...
I could find at least 1 example for almost every item in the list above, however I couldn't find a "standard", "recommended" or "official" approach either from Google or the Android Dev Community.
(Not asking for a silver bullet here, just wondering what is the most or some of the most consistent and of course modern ways for such a common task)
Service is the fastest - You can download as much as needed immediately. You will need to elevate it to foreground (with sticky notification) to start and/or keep it alive when your app is not in foreground.
JobScheduler + JobService is less intrusive but its time of execution is managed by the system, so it's not suitable for immediate request. You can however schedule it to run periodically to check if there's something new to download.
DownloadManager is a system service. Unlike other methods download does not happen within your apps process. You don't need to write any connection methods yourself then, but You're relying on unknown implementation which may vary per-device. Any problems that occur like throttling/stuck queue/cancellation are out of your control.
I have specific case to ping my server every 10-60 minutes (it still depends) but only when app is opened.
This feature is created to inform that session is still open where session is defined as period from app open to app close. I don't have to worry about process kill.
What is better to use? AlarmManager or Handler.postDelayed() ?
The targeted platform is android tv so imagine the case is when watching film in context of my app for example.
Personally I first thought to use AlarmManager but I realized it's way more code to produce compared the circumstances.
Is handler causing more CPU usage increase ?
AlarmManager starts your app in the future when it is not running. So I think Handler.postDelayed() is a more efficient choice if you will only ping the server when the app is open.
Note: The Alarm Manager is intended for cases where you want to have your application code run at a specific time, even if your application is not currently running. For normal timing operations (ticks, timeouts, etc) it is easier and much more efficient to use Handler.
See AlarmManager.
You should definitely use AlarmManager for this use case. I can think of several reasons right away:
If you use Handler and want to post a "cancellable" Runnable to it, then you'll have to store references to both the Handler and the Runnable in order to be able to cancel the execution (e.g. if user leaves your app). It means that you'll have to either store them in an Application context, or create a Service for this feature. Using Application for this kind of stuff is generally discouraged, and Service is a bit of an overkill.
AlarmManager is the standard API for this kind of stuff. Any other developer reading your source code (or yourself in few months) will have a much easier time understanding the feature.
I don't see how you can have less code using Handler approach - all you need in order to use AlarmManager is a single method that creates PendingIntent, which is being passed to both set and cancel methods in AlarmManager...
As for CPU usage, I'm sure that the scale will be insignificant, therefore it won't matter.
In general, I think that Handler#postDelayed should not be used to control flows that involve user interactions. It just feels wrong and clumsy.
I have been developing for Android for little less then 2 years, and I am still puzzled by this seemingly simple question.
When should one implement a service?
From my experience there are some rare cases but I am questioning this because on every phone there are quite a lot of them running and I doubt it's just a poor application design.
This is essentially core of my question but following are some of my experiences and thoughts about the subject which can explain my question in more detail.
In all apps that I have developed only one really required a service. It was a background sound recorder and I was using it as Foreground service with notification since I wanted buttons to be able to control it (like music players do for example).
Except this I never really saw a requirement for the constantly running service because:
A) Intent listeners (Manifest registered BroadcastReceivers) are quite a useful feature and using them as you know is usually enough for many use-cases (for example showing notifications).
B) If scheduled execution is a must one can subscribe to alarm events.
C) I know that service in Android is quite different then for example in Windows since in Android services are just a "package" to organize your code in and have a the system manage the lifetime of the object. Services use the Main Thread but it's customary to spawn new threads in them.
D) In the development documentation services are suggested for network communication and background calculations but I don't get why you should not just use AsyncTasks for that. I am a big fan of these and use them extensively for lot of things from downloading data from the internet to doing FFT calculations under time critical conditions.
E) I get the usefulness of Foreground services but why are people using background services so much (excluding the system apps).
Those are my thoughts about the SERVICE and I hope someone with more experience will be able to explain these PROS and CONS (along with others that I probably missed).
When should one implement a service?
When you have work -- delivering value to the user -- that:
Needs some time to complete, perhaps longer than you have time for in the component wishing the work to be done, or
Is delivering that value under user control (e.g., music player, controlled by play/pause buttons in a UI), or
In rare cases, needs to be running continuously, as it delivers value continuously
there are quite a lot of them running and I doubt it's just a poor application design
Some are likely to be poor implementations, either due to technical misunderstandings, or other concerns (e.g., making marketing happy) trumping making users happy.
It was a background sound recorder and I was using it as Foreground service with notification since I wanted buttons to be able to control it (like music players do for example)
That is a reasonable use for a service, IMHO.
Intent listeners are quite a useful feature and using them as you know is usually enough for many use-cases (for example showing notifications)
I assume that by "Intent listeners" you mean manifest-registered BroadcastReceivers. In that case, if the work to be done by the BroadcastReceiver will take more than a millisecond, that work should be delegated to an IntentService for completion. onReceive() is called on the main application thread, and it is not safe for a manifest-registered BroadcastReceiver to fork a bare thread, as the process could go away shortly after onReceive() returns. However, in these cases, the service is usually short-lived (e.g., do some network I/O and disk I/O, then go away).
In the development documentation services are suggested for network communication and background calculations but I don't get why you should not just use AsyncTasks for that
An AsyncTask is a fine solution for background work that is:
Requested by the UI (activity or fragment), and
Will take less than a second or so, and
Is non-critical
For example, if you are downloading avatars to show in a ListView, AsyncTask is probably a fine choice, whether you use them directly or use some image-fetching library that uses them internally.
Conversely, if the user buys an MP3 through your app, and you need to download that MP3 file, an AsyncTask is not a good solution. That could easily take over a second. While the download is going on, the user could switch away from the app (e.g., press HOME). At that point, your process is eligible to be terminated... perhaps before your download is complete. Using an IntentService to manage the download is a signal to the OS that you are really doing work here, adding value to the user, and so the process will be left alone for a little while.
Note that if the background work might take 15+ seconds, WakefulBroadcastReceiver or my WakefulIntentService is probably a good idea, so the device does not fall asleep while you are trying to wrap up this bit of work.
I can name some of the Service uses from my experience:
to implement
location listener,
sound module, generating various voices
in app content updates,
API, provide services to other apps
in app billing
Communication with webservices (if requests frequency is high)
actually (excluding 5.) they all are working for the whole app duration, they are using some of the other android services, also they manage their state. I suppose one of the important thing here is state management during application life cycle changes.
I prefer to look at AsyncTasks in a same way as Executors (ExecutorService), they should be executed sequentially and for small tasks.
In the android website, you can find a table when to use Service, Thread, or WorkManager (the new API for scheduling jobs, currently in alpha as of this comment posted). https://developer.android.com/guide/background/#table-choose
The website also state that you need to use started service only as last resort. The Android platform may not support started services in the future. Refer to this link https://developer.android.com/topic/performance/scheduling#services
You should avoid using started services that run perpetually or perform periodic work, since they continue to use device resources even when they aren't performing useful tasks. Instead, you should use other solutions that this page describes, and that provide native lifecycle management. Use started services only as a last resort. The Android platform may not support started services in the future.
If you consider UI and bound services, u would think that both can exist and not be doing anything for certian periods. In such scenarios, your UI can be recreated a lot of times however service does not. And this is where service is important. Lets say you are processing images and then rotate device you want processing to continue while UI is being recreated. You recording a voice and then rotate device. These are one of the places where I find service very important. (Having lot of heavy data processing, interaction with web, that could be few seconds)
I love IntentService and try and use it whenever I have to write a Service.
However I have to perform a long task (~4 seconds) at least once, when the application starts. The task is to load a raw resource (a certificate) and use it for all web service calls. Currently I'm loading it each time a web service call is made, which is obviously not a real solution.
Because IntentService is stateless I can't keep the certificate around between requests. What are my options other than writing a "normal" Service and implementing the lifecycle carefully to check when the certificate should be (re)loaded.
Thanks.
The task is to load a raw resource (a certificate) and use it for all web service calls.
Loading a raw resource should take milliseconds. Use Traceview to figure out why it is taking ~4 seconds.
Currently I'm loading it each time a web service call is made, which is obviously not a real solution.
Loading a raw resource every time seems like a perfectly viable solution. It's not like you have another choice.
What are my options other than writing a "normal" Service and implementing the lifecycle carefully to check when the certificate should be (re)loaded.
That would be a really bad idea.
Users greatly dislike developers who keep services running when they shouldn't. Users attack apps like this with task killers and force-stops in Settings. Once that happens, on Android 3.1+, your app will never run again until the user starts up one of your activities.
Also, Android will terminate your everlasting service after a while, once again to protect users from poorly-written services.
Focus instead on optimizing the ~4 second operation.