Chathuranga Shan

Guide to background Task handling – Part 5 (AlarmManger)

Mon, 22 Apr 2024 07:40:49 +0000

If you have been following this series you may have noticed already we haven’t found any Andoird component that can handle a background task to execute at the exact given time. The closest we come to achieving something like that is by using PeriodicWorkRequestBuilder in WorkManager . Even when using WorkManager that it won’t wake your phone from Doze mode. AlarmManager is the suitable component that can be used to execute a background task in a fixed time in the future.

How does AlarmManager work?

AlarmManager allows developers to schedule tasks that must be executed at a specific time or after a specific interval. It is a system service that runs in the background and handles all the scheduled tasks. When an alarm is triggered, the AlarmManager sends a broadcast intent to the system, which starts the specified service or activity. The AlarmManager Itself is not capable of running a background task but rather capable of triggering a component that is capable of executing a background task. commonly uses Service with AlarmManager for executing background tasks.

One of the most significant advantages of using AlarmManager is that it allows developers to schedule tasks even when the application is not running. The only downside is that AlarmManager will get reset if the device is restarted. But there is a workaround for that which we will discuss in this article.

Guide to background Task handling – Part 4 (WorkManager)

Sun, 31 Dec 2023 18:43:50 +0000

WorkManager is an Android component for handling background tasks that need to schedule and survive app restarts and system reboots. WorkManager also can be used for executing one-time background tasks which replaced the functionality of now deprecated IntentService and JobIntentService . WorkManger can handle Immediate, Long running and Deferrable types of background workloads.

WorkManger is a feature pack component compared to other background tasks handling components we discussed so far. Let’s look at the WorkManger features.

Robust scheduling

As I mentioned above briefly work-manager can handle all three types of background tasks. When it comes to scheduling a unique tag and name can be given to a worker to replace, restart, cancel or monitor it. Work-manger schedule data is stored in SQLite database which allows itself to run persistently. In addition to that work manager build in mind with power-saving features so as developers we do not need to worry about it.

Guide to background Task handling – Part 3 (Coroutines)

Sat, 30 Sep 2023 11:35:43 +0000

In this article, we will explore the concept of coroutines as a means of handling background tasks in our applications. Coroutines are the go-to solution when it comes to handling Immediate impersistent tasks. A lot of Android libraries come with coroutines support out of the box making it easier to perform those libraries’ functionalities incorporated with coroutines.

Coroutines are a type of function that allows you to pause the execution of a function, perform another task, and then return to the paused function to continue execution from where it left off. This makes them ideal for handling asynchronous tasks such as network calls, database operations, and other long-running tasks.

Advantages of Coroutines

Simplicity: Coroutines are easy to use and implement compared to other concurrency models such as threads and reactiveX.
Efficiency: Coroutines are lightweight and have less overhead compared to threads, making them more efficient when handling a large number of tasks.
Readability: Coroutines use a sequential style of coding, making them more readable and easier to understand than callback-based coding.

let’s try to break down each of the concepts in the Coroutines.

Guide to background Task handling – Part 2 (Services)

Wed, 30 Aug 2023 05:53:48 +0000

In this article, we are going to look at Android services. Service is best used when there is a task that needs to be executed in the background without user interaction. However, there are service types that users can interact with. Usually, services are used for implementing long-running tasks.

Types of Services

There are three types of services to choose from based on the nature of the task.

Foreground Service

When we need an application user to notice a background task is processing we use this service type. This service can survive even after the application is destroyed. Users will see a notification when this type of service is running in the background. For example, downloading large files would use a foreground service to handle that task.

Background Service

When there is a background task that needs to implement and it is not necessary to inform the user we can use background service. For example, Performing a cashing mechanism in which the user doesn’t need to know a background service can handle that task.

Bind service

When there is a task that needs to be handled in the background with user interaction a bind service can be used. This interaction can be a form of sending result data back to the UI layer or sending a request to the service to perform an additional task from the UI layer. A bound service runs only as long as another application component is bound to it.

Guide to background Task handling – Part 1 (Threads, Runnable and Handler)

Sat, 29 Jul 2023 11:55:52 +0000

In Android development, being able to handle tasks in the appropriate thread is an essential skill to have. In this series, I’m planning to cover all the available methods in Android for handling tasks in the background. As the first article of this series, I will explain the basics of background tasks and will explain how to handle a background task using a thread.

What is a background task?

The simplest answer is any task that needs to execute outside the main thread is qualified as a background task. But there are many variations of background tasks. it can be in the range of doing small network calls in the background to doing background tasks even though the application is closed. The following graph summarises the range of background tasks that we might need to implement during our Android application development.

Switching to Hilt from Dagger

Wed, 18 May 2022 16:33:15 +0000

I had been using Dagger for all my projects as the dependency injection solution. It was the go-to library for managing dependencies in your application when developing an application with testability and code separation in mind. The Dagger library was not originally designed for the Android framework. Because of that Dagger was not that easy to work within the Android framework but once you figure out how to use it, it’s the best solution available for android project dependency injection. The Hilt library is the new dependency injection solution for android which replaces the Dagger. The Hilt was built specifically for Android project development. It reduced the significant amount of code that we need to write and it has built-in support for ViewModel injection.

In this article, I’m using my old project which I used in the MVVM error handling article series. I have expanded that project into an indoor plant selling sample application. This way we have a few screens to work with plus it covers most of the dependency injection scenarios that we face in real-world application development. You can find the code in this repository. Refer to dagger_to_hilt_start branch for the start point of the application. you will be able to see the end result of this implementation on dagger_to_hilt_end branch. In this article, I will mainly focus on explaining how to perform the transition to Hilt from Dagger. Even though I will get into the details of the Hilt library I will include some parts of official documentation in this article because there is no point in rewriting the same details. So let’s clean the project and delete all the files inside “di” folder.

Android MVVM architecture with clean error handling – Part 2

Sat, 02 Apr 2022 10:04:13 +0000

I wrote an article a few months back explaining my approach to error handling in MVVM architecture. since that, I had a chance to apply this approach to a few projects I was working on. While my approach still holds strong I have noticed a few places where I can improve to make this approach even better. These changes I’m about to make still follow the same flow as I had in my first article.

More control in Handling processing status

In the previous article, I had a boolean mutable live data variable in BaseViewModel which is used by the UI layer to show the loading animation on the screen to notify the user that the application is doing some processing. The problem with having a boolean value is that on some screens you will need to do different things based on the status of “completed”, “processing” and “error”. Obviously, this boolean value can not store 3 values for UI to refer to and do the necessary changes base on status. To handle this I have to introduce the below enum class.

Using Paging 3 library to consume large data set over the network

Fri, 30 Jul 2021 17:50:23 +0000

Jetpack paging library introduces a hassle-free way to implement pagination for a large set of data. Paging 3 is the latest iteration of the library and a few months ago it released the stable version. In this article, we will look into how to use this library to consume large data set over REST API. This project is build using MVVM architecture. For network call integration I’m using Retrofit with Moshi.

In MVVM architecture each layer has different responsibilities. Paging 3 library has different components which align with these architecture layers. Take a look at the below diagram.

Android MVVM architecture with clean error handling – Part 1

Wed, 19 May 2021 14:57:50 +0000

MVVM architecture is a popular architecture among android developers due to it being more suitable for most of the project sizes which provide more flexibility to scale project with code separation. Google JetPack libraries also work with this architecture like bread and butter to make it easier to implement reactive solutions with less boilerplate code. Error handling is a huge part of any project when it’s come to giving a good user experience. In this article, I’m going to show my approach to handling errors which allows you to develop cleaner functional requirements while treating error handling is as a separate stream.

To have a good error handling solution first we need to understand which parts of our application generates errors and what we need to communicate to the user. Let’s start from the bottom layer of our architecture which is the repository layer. Application all network and database related business logic are situated in this layer. When it comes to network call-related errors we need to inform users with descriptive error messages almost all the time. The only exception to this is errors that cause because internal issues (Bad Json phrasing). In those cases providing a generic error with description is enough. When It comes to database-related error handling most of the time we will have to inform the success and fail status of the database operation. The only exception to this is errors that cause when writing optional recodes to the database. An example of this would be caching network calls to use on offline mode. When it comes to the middle layer which is the view model layer, Usually form-related validation is done in this layer. in case of validation fail we need to showcase those errors underneath the edit text or to other elements to guide users.

Coordinator Layout Like Animation on Fragment Using Motion Layout to have Seamless Transition when using Using Navigation Component

Sun, 01 Nov 2020 03:59:23 +0000

Navigation component Introduction made using single activity UI pattern easy. Although it introduces a stranded way to follow a single activity UI design pattern it comes with its own challenges to overcome. One of which is to have a seamless transition between coordinator design fragment and other fragments.

When implementing the navigation component activity act as a navigation fragment holder. Fragments in the navigation component consume the data coming from the view model and display for users to interact with users. Activity holds navigation fragments and toolbar. The app toolbar is placed inside activity because it’s common for most of the fragments. This works fine as long as there is no need to implement a design involving coordinator layout. Coordinator layout does those beautiful collapsing animation by using CollapsingToolbarLayout inside AppBarLayout. The app toolbar also needed to stay inside CollapsingToolbarLayout.

How to Communicate Between Fragments and Activity When Using Navigation Component

Mon, 05 Oct 2020 10:21:48 +0000

The android team introduced Navigation Component 2 years ago to encourage developers to use the single activity UI pattern. With the introduction of the navigation graph view in android studio, it provided a visually represented graph to work with fragments. Although it introduces a standard way to follow the single activity UI design pattern sometimes it can introduce new challenges to overcome. one of which is the way of communicating between navigation host activity and its fragments. The full project is added to Github.

About me

Mon, 01 Jan 0001 00:00:00 +0000

Contact