Android Studio 3 - Work Manager

A few days ago, Android has added a new and more efficient way to run background services. We will explore here the main features.
-
We create a new, empty project. As always, the name is at our personal discretion.
We open also the application build configuration and its manifest file.
In the manifest file, we add an action, which allows Google to harvest information, once the application is added to the app store.
Before the application tag, we add a few permissions, in order to allow Internet access and interrogate the network status.
Then, we add the permission to react on the boot status. Essentially, this permission registers the application at system level, because it will receive a notification when the system is ready to use.
Under the application tag, we add a broadcast receiver for this system event. We give it a significant name. Then we add an intent filter and the respective action.
Then, we click on the broadcast name, and choose to create a new class. Within the class, we add the required functions. This class has no user interface.
In the function which receives the event, we add for now a log entry.
If we use this broadcast receiver also for other notifications, we additionally have to filter the actions.
In order to add the work-in-progress addition, we go to the application configuration and add the following line.
Now, we add a worker class, which is called every time from the system, when our programmed event occurs.
We may create as many worker classes as needed, for every background task we want to perform. Each class should be as small as possible, since the work manager allows to call all tasks with very powerful features, which give us full control over the code flow. In other words, it is not advisable to pack as many as possible features into a single procedure, because the new features allow us to gain better control over predefined steps.
We create now the respective function, and we make it public to the package and static. A public static function becomes available to all other classes of our project.
Now we can start our application and run one worker instance at each button press. We filter our log entries with our tag. The first message informs us about the request, and shortly after, we are informed about the execution of the background task.
To automate the button press, we can add the creation of a new task from within the task itself. We would do that, if our events happen more frequently than every 15 minutes. We also disable or hide the button, to avoid a second manual start.
If we now press the button, the function is called once manually and then by the background task.
How can we tell it is background? Well, stop your application and see! As long as your device is running, the task starts itself over and over.
I add the same command in the broadcast receiver.
Now, I will run the application on my real phone and reboot. After the device becomes available again, the system calls the background task without my direct intervention.
The background task continues after a short pause, even when I force to stop the application. This behaviour eventually is a bug, but right now it is a feature, which makes workers much more attractive than a service.
That's all for today. Thank you for watching!