Background Processing in Android Apps
We tend to develop bespoke enterprise Android apps for use by engineers, surveyors, salespeople, etc. who are out in the field and the data they see on the app (e.g. job details) and the data they capture on the app (e.g. text inputs, photos, videos, customer signatures) usually needs to be synced with other systems so management back in the office can update details which appear on the apps and likewise see data and reports which have been captured on the apps. We will generally do this by using background threads so we do not affect app performance when carrying out resource-intensive activities such as uploading saved videos to cloud-based systems.
The reason we do this on so called "background threads" is because every Android app has a main thread which is in charge of handling the User Interface (UI) - i.e. the app screens you see - and if we are doing too much work on this thread then the app can slow down, hang or even crash. Therefore, any long-running computations or operations (e.g. syncing data with servers) will mostly need to be done on a different background thread.
However, sometimes we need the data syncing operations to be performed on the main thread (e.g. we need to receive data from a remote location instantly when requested via say a button submission on the Android app) and in this case we can use a foreground service. If we use a foreground service this tells the Android operating system that the app is doing something important and shouldn’t be killed and users are aware of this action because they can see a notification (non-dismissible) in the notification tray.
If the task is deferrable and needs to run even if your device reboots or the app restarts, then we can use the Android WorkManager library (read more here
). This is especially useful on newer versions of Android as the latest versions (Android 6 - Marshmallow and upwards) restrict background work when the app (or a foreground service notification) isn’t visible to the user.