I was learning about JobScheduler with a Tutorial from 2015, and when I was creating a class of this service,it complains asking me to put the annotation #RequiresApi(api = Build.VERSION_CODES.LOLLIPOP), which means, doesn't work for old versions? And if it is, GCMNetworkManager would be the one ?
which means, doesn't work for old versions?
Yes annotation specifies that API wont work under LOLLIPOP version
And if it is, GCMNetworkManager would be the one ?
Alternatives to JobScheduler are
AlarmManager
GCMNetworkManager
SyncAdapter
You should choose one that suits your need with minimal device resource utilisation.
Note: Avoid using services that run perpetually or perform periodic work, since they continue to use device resources even when they are not performing useful tasks.
Related
Android 12 brings restrictions on foreground service usage and dev team offers a WorkManager as an alternative.
Google team wrote a good article on what should be used and when. My use case is close to long-running operations which is covered here. However, it requires to define a category of service type which seems doesn't cover my use case.
My use case is to run minting a token from mobile wallet on ethereum chain and wait for callback. I use privately hosted eth chain which mines a block each 15 seconds. Keeping in mind this time schedule might increase in future depends on changes in business requirements I want the app to support a longer request even at this stage of the development. That's why I need to run it as a long running operation.
FOREGROUND_SERVICE_TYPE_SPECIAL_USE looks like a right fit, but it is supported only on the latest SDK. Compilation under the my current compile SDK (33) supports only this options
[camera=64, connectedDevice=16, dataSync=1, location=8, mediaPlayback=2, mediaProjection=32, microphone=128, phoneCall=4]
That's from an error shown by compiler.
Android compileSdk = 34 is not supported, but anyway it is still under preview. This limited options from the compiler error messages tells me I WorkManager long running operations are not a good fit for my use case. Altogether it brings me to the questions:
Which type of foreground service type should I choose?
Shall I reject WorkManager for this use case at all?
What could be an alternative for WorkManager on post Android 12 devices for foreground-service operations?
Is there a way to enqueue work in work manager from multiple processes? Right now I’m getting this message when I’m trying to do it from the "non-ui" process
I/WM-GreedyScheduler: Ignoring schedule request in non-main process.
Work manager version I'm using is 2.4.0. I know there is 2.5.0-alpha2 right now, but I cannot use that in production
WorkManager 2.5.0-alpha02 is the first version of WorkManager that has multi-process support.
There is no mechanism for using WorkManager across multiple processes in any previous version of WorkManager (hence why these new APIs were added in the first place) so you'll need to either upgrade to that version of WorkManager or wait for it to become beta/RC/stable.
So I know WorkManager utilizes JobScheduler on supported APIs but there doesnt seem to be any way to make WorkManager work persistent across reboots? Is the only option to request the BOOT_COMPLETED permission and reschedule jobs?
To answer your question: You don't need to do anything if the device is rebooted. WorkManager keeps scheduling your Work without any additional requirement from your side.
WorkManager persists Work requests in its internal Room database. This allows it to guarantee Work execution across device restart.
The documentation covers this as this blog "Introducing WorkManager" that the team wrote last year.
WorkManager is actually used to persist deferrable tasks even after your app exits and the device restarts, please refer to the docs. It uses JobScheduler for api 23 and above and broadcastReceiver and AlarmManger on api 14 to 22. You can use constraints to check battery status, network coverage ...etc depending your particular usecase. You just have to be careful not to remove or rename your existing classes after they are added in the queue because WorkManager uses it's internal database to store those classes and your app will crash if you remove them or rename them.
So, I'll start by saying I have already done a lot of research on this, but I'm still stuck.
So here's the goal: Preform a database action (insert a reminder message into local sqlitedb) and send a notification at pre-set times given by some user settings.
And here's the problem: It doesn't work when the app is closed.
I have tried using AlarmManager with a broadcast pending intent and with a service pending intent. Neither seemed to work in the problem scenario. After looking into it some more, I found that on newer versions of Android, they are paring back some of the functionality of AlarmManager in favor of JobScheduler, a new API that 1) seems to be overkill for what I'm doing and 2) won't work on older devices. Sending alarms while the app is closed seems to be one of those "pared-back" features. What should I do? What do I use? What does everyone else usually do? Have I misunderstood something? Please help; I can't find anything on Google!
There are a few methods of running "jobs" pre-lollipop.
You can use the JobSchedulerCompat library, but this library has a huge difference compared to the default Lollipop API:
On Lollipop jobs are batched and scheduled for all apps at once. The library however does not have access to other apps data and therefore can't combine jobs from two different apps using the library.
Another option is to use JobScheduler for lollipop and greater devices and then use AlarmManager for pre-lollipop devices by checking
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP){}
Finally, you can use the Sync-Adapter API. The Sync adapter encapsulates the code for the tasks that transfer data between the device and a server. Based on the scheduling and triggers you provide in your app, the sync adapter framework runs the code in the sync adapter component. To add a sync adapter component to your app, you need to add the following pieces:
Sync adapter class.
Bound Service.
Sync adapter XML metadata file.
Declarations in the app manifest.
In my android app I have created a function that updates some fields in SQLite database, now I run this function manually and it is doing the job, but I want to run this function automatically once in a month. How it is possible.
To run your task periodically i recommend you to take a look at it JobScheduler api which is latest and more powerful for scheduling the job take a look at this https://developer.android.com/reference/android/app/job/JobScheduler.html
if your app targets api >21 you must use jobscheduler if u want to support the lower version take a look at firebase job dispatcher:https://github.com/firebase/firebase-jobdispatcher-android