I am still new to android and working on an application that works on Android (API >= 21). This application displays data that is previously downloaded from a server on the local network so I need to implement a service to download the content, on-demand & Periodically, on the device.
SyncAdapter
I've implemented this "Downloader" using SyncAdapter and it was working fine but at the end the code was really verbose:
The application does not have ContentProvider. The content is downloaded as files.
It runs on a local closed network so there is no need for authentication.
The application had 3/4 extra classes that not doing any real job.
JobScheduler
After some reading and searching, I decided to go with JobScheduler.
"JobScheduler is guaranteed to get your job done." medium article
It looks easy and has clear API, I said, so I re-implemented my "Downloader" with JobScheduler and the result was really good. The application was able to download the content, writing a good log to trace errors and operations. The Job runs when the device is Idle and kicks off/stopped, on demand, as expected.
I used alarm manager to implement the periodical calls of the job and turning wifi on. Oh, I forgot to mention that the application is the responsible of turning on the wifi because it is inside a case and works as Kiosk
The problem is that there is a catch. This is not mentioned in the documentation, or I was blind not to see it, at all. The Job is limited to 1 minute only (1 minute on lolipop and more on Android >= 0) then the onStopJob() will be called. So my is cancelled before completing the download when the data is a little big. Of course I can keep my thread going and continue download in the background but in this case I can't benefit from the API to maintain a good log, reschedule my job and manage Wifi status.
I need another implementation
I need something similar to SyncAdapter or JobScheduler that runs when the Wifi is on and when the device is Idle.
I am not sure whether triggering a service from JobScheduler is the solution I am left with. I need a little certain information before implementing the same thing for the third time.
Any idea?
Related
I'm trying to get a feature in my app that opens an ftp connection every night, compares the content of the ftp server to the contents of the sharedPreferences JSON and if there is a difference, upload the missing data to the ftp server.
So far I think I need to use an AlarmManager for this, so that the code runs even when the app is closed at night.
This is a completely new thing to me and I'm looking up some documentation and StackOverflow questions about it, but I can't really figure out if this is what I need to use for what I'm trying to do.
I found the following question which contains a nice example of AlarmManager. But can it also retrieve data from sharedPreferences? I was also wondering if I can run an async task (using coroutines).
EDIT: I read something about a workmanager. Would this be a better solution for what I'm trying to achieve?
Workmanager is introduced from Android 8. It is better then AlarmManager because it can manage the doze mode and more when you phone is in sleep mode. You can configure the workmanager to do the work each x mins with conditions (if the device connected, if the phone has % of battery ..)
The great issus with AlarmManager is that you don't garatute that it will be launched at the specific time because the system will manage all alarm with priority...
For more details : link
Yes, you can fetch data from shared preferences from your BroadcastReceiver. And you can also run asynchronous tasks from your BroadcastReceiver, such as coroutines or threads.
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.
Basically, there is a Google way, which suggests using Service for long running operations (which I use at the time). On the other hand, there are a lot of examples in community by honored developers, which avoid using Service and at most incorporate Fragment's setRetainInstance(boolean retain).
While Google has declared that a lot of bad stuff might happen if we don't use a Service, I still feel anxious because there are, it seems, so many projects leaving Service aside.
Can you consolidate the Google's case or provide suggestions for abandoning Service?
P.S. I'm developing "classic" rest-client applications.
P.S.S. I forgot to mention that Service is used in pair with ContentProvider(for cachging purposes, guard against system app forceshutdowns).
Thanks.
If the network request is very likely to take under a second, or if you don't mind it if your process terminates before the request completes, using simple threading from the UI layer is fine, IMHO.
But once the user leaves your app (HOME, responds to an incoming call, etc.), the lifetime of your process is limited, and it could be very short if you do not have a service to tell the OS that you're still doing important work for the user.
So, if the network request is more in the 1-15 second range, and you'd like to feel fairly confident that the work will run to completion, use an IntentService or something along those lines.
If the network request is likely to be longer than that, such as a large download, now you have to worry about the device going to sleep and such. My WakefulIntentService was designed for this sort of scenario, where it will keep the device awake long enough to get the work done, then let the device go back asleep.
Some developers use services for all significant network I/O, skipping them only for truly ephemeral stuff like thumbnail images to populate a ListView or RecyclerView. So long as the service is only running when it is actively delivering value to the user, this is perfectly fine.
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)
/** Start of pseudocode **/
1) After a specified delay, the application requests data from a Bluetooth device.
2) The application saves and analyzes the data.
3) IF the analysis results are abnormal, the application sets off an alarm and returns to step 1) with a shortened delay.
ELSE the application returns to step 1) as normal.
/** End of pseudocode **/
I currently have an implementation working that utilizes a Timer and TimerTasks to analyze some data in a .txt file repeatedly after various delays. Later on in the application's development the data will be received from a Bluetooth device (the Android emulator doesn't support Bluetooth).
I can't have the main UI thread busy handling this stuff - I need some form of asynchronous (multi-threaded) approach (ie. the TimerTask).
I also need this analysis process to continue even if the user switches to another application.
Do I need to use a Service/IntentService to ensure this Bluetooth reception & analysis procedure remains active?
As a beginner Android developer, I would appreciate any advice on the subject. I am currently trying to understand Services and IntentServices.
If you are trying to understand Service and IntentService, I would recommend you to take a look at this post and related posts. It compares various task execution mechanisms in Android and provides a rough guideline on when to use what.
Yes, services are designed exactly for that: asynchronous tasks that can take a long time and need to keep running even when the activity is closed.
I have done similar task in the past with reading bluetooth data using service. You may need to look into using headless service. The service runs even when you go to other apps and when you come back binds with your activity.