progexplorer

The WorkManager library was born to perform background processing (outside MainThread ) of applications that the user is not interacting with, dealing with the restrictions imposed on background processing by Android and integrating and simplifying some existing solutions. Remember that an app is considered to be running in the background as long as each of the following conditions are satisfied: None of the app's activities are currently visible to the user. The app isn't running any foreground services that started while an activity from the app was visible to the user. Restrictions Doze mode If a user leaves a device unplugged and stationary for a period of time, with the screen off, the device enters Doze mode. This mode prevents apps from accessing the network and defers their jobs, syncs, and standard alarms. It, therefore, restricts the use of background services, which can only use these resources in a short period of time called the maintenance window. Android Oreo Whe

Alarms are used to start one of your app's component after a specified delay or at a exact time even outside the lifetime of your application. They are implemented with the AlarmManager class.  With AlarmManager you can schedule your application's component to be run at some point in the future. You need to register your app with a PendingIntent , a wrapper for an Intent object whose component name specify the component to start when the alarm goes off. With the PendingIntent , AlarmManager can automatically send a broadcast, start an activity or a service of your app when the alarm goes off, i.e., AlarmManager can perform the action you described on your behalf at a later time. Types of Alarms They can be: One-time : goes off at a specified time and only. Repeating : goes off at a specified time and then   after each pass of the specified interval. If the trigger time you specify is in the past, the alarm triggers immediately . And: Elapsed real time : uses the "time sinc

Android apps can send or receive broadcast messages from the Android system and other Android apps.These broadcasts are sent when an event of interest occurs. Apps can register to receive specific broadcasts in a specific part of its code (defined as a object of the  BroadcastReceiver  class). When a broadcast is sent, the system automatically routes broadcasts to  BroadcastReceiver of the apps that have subscribed to receive that particular type of broadcast.  The broadcast message itself is wrapped in an  Intent  object whose action string identifies the event that occurred (for example android.intent.action.AIRPLANE_MODE ). The intent may also include additional information bundled into its extra field. More about intents on Intent . Receiving broadcasts Apps can receive broadcasts in two ways: through manifest-declared receivers and context-registered receivers . Manifest-declared receivers If you declare a broadcast receiver in your manifest, the system launches your app (if the

An Intent is a messaging object you can use to request an action from another app component . There are three fundamental use cases: Starting an activity Starting a service Delivering a broadcast Types of intents There are two types of intents : Explicit intents specify which application will satisfy the intent , by supplying either the target app's package name or a fully-qualified component class name . You'll typically use an explicit intent to start a component in your own app , because you know the class name of the activity or service you want to start.  Implicit intents do not name a specific component , but instead declare a general action to perform, which allows a component from another app to handle it. Intent content The primary information contained in an Intent is the following: Component name : The name of the component to start. This is optional, but it's the critical piece of information that makes an intent explicit , meaning that the intent should

Generally, every Android application runs in its own Linux process . This process is created for the application when some of its code needs to be run, and will remain running until it finishes, until the user finishes it or until the system kills it to recover memory for other more important applications . To determine which processes should be killed when low on memory, Android places each process into an "importance hierarchy" based on the application components  (in particular Activity , Service , and BroadcastReceiver ) running in them and the state of those components . These process types are (in order of importance): 1) Foreground process : a process is considered to be in the foreground if any of the following conditions hold: It is running an Activity at the top of the screen that the user is interacting with (its onResume() method has been called). It has a BroadcastReceiver that is currently running (its BroadcastReceiver.onReceive() method is execut

Background tasks  (or background processing) are any task that executes outside Main Thread , i.e., executes on a background thread . Any task that takes more than a few milliseconds should be delegated to a background thread . Background tasks fall into one of the following main categories: Immediate : task need to complete while the user is interacting with the application. Deferred : task allow for slight variations in when it run that are based on conditions such as network availability and remaining battery. Exact : task need to run at an exact time. This decision tree (extracted from: Guide to background processing | Android Developers ) helps you decide which category is best for your background task : Each of those categories of background tasks can be implemented in a recommended way: Immediate tasks -> Kotlin coroutines . Deferred tasks -> WorkManager . Exact tasks -> AlarmManager (*). (*) Note that  AlarmManager is not a strict way to implement a background task

  What to do if you need to implement an action when the user presses the button to return to the previous screen (both the up button and the back button) on a Fragment ? In this case, the FragmentManager.OnBackStackChangedListener listener can help, as it is fired whenever the fragment is added and removed from the back stack . Just be careful as it is not only when the fragment is removed from the back stack , but also when it is added. How to implement it? In the fragment 's method onCreate , create a  FragmentManager.OnBackStackChangedListener and add it to the parentFragmentManager with the method addOnBackStackChangedListener() . The code below show an example. override fun onCreate(savedInstanceState: Bundle?) { super .onCreate(savedInstanceState) parentFragmentManager .addOnBackStackChangedListener(FragmentManager.OnBackStackChangedListener { //do something } ) }