What is MVVM?

MVVM is an architectural pattern that separates an application into three main components:

1. Model

2. View

3. ViewModel

The purpose is to separate the user interface logic from the business logic, making the code more modular and easier to maintain.

Components of MVVM

Model

• Represents the data structure and business logic of the application.

• Responsible for managing data, performing calculations, and enforcing business rules.

• Can include data classes, repositories, and data sources.

• Should be independent of the UI and can be reused across different parts of the application.

View

• Represents the UI elements that the user interacts with.

• This typically includes Activities, Fragments, and XML layout files.

• Observes and reacts to data changes in the ViewModel.

• Should be focusing only on displaying data and capturing user inputs.

• Doesn't contain any business logic or data manipulation.

ViewModel

• Acts as an intermediary between the Model and View.

• Holds and processes all the data needed for the View.

• Exposes data to the View through observable properties (often using LiveData or StateFlow).

• Handles user interactions passed from the View.

• Contains the presentation logic but no direct reference to View components.

• It is lifecycle aware, and survives configuration changes (like screen rotations or switching between light/dark themes).

• Helps in separating UI logic from UI controllers, making the code more testable and maintainable.

Data Flow in MVVM

a) View to ViewModel:

• User interacts with the View (e.g., button click)

• View calls a method in the ViewModel

• ViewModel processes the request and updates its data if necessary

b) ViewModel to Model:

• ViewModel requests data from the Model

• Model fetches or updates data (e.g., from a database or network)

• Model returns data to the ViewModel

c) ViewModel to View:

• ViewModel updates its observable properties

• View observes these changes and updates the UI accordingly

Example:

1. Model Layer

User.kt

data class User(val name: String, val email: String)

UserApi.kt

object UserApi {
    fun getUser(): User {
        // Here you can write the code to fetch data from internet
        // For now, I am returning sample data
        return User("Yashraj", "yash@mail.com")
    }
}

2. ViewModel Layer

UserViewModel.kt

class UserViewModel : ViewModel() {
    private val _user = MutableLiveData<User>()
    val user: LiveData<User> = _user

    fun loadUser() {
        _user.value = UserApi.getUser()
    }
}

3. View Layer

activity_main.xml

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:id="@+id/main"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <TextView
        android:id="@+id/tv_data"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Sample"
        android:textSize="34sp"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

    <Button
        android:id="@+id/btn_load"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginTop="16dp"
        android:text="Load Data"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toBottomOf="@+id/tv_data" />

</androidx.constraintlayout.widget.ConstraintLayout>

MainActivity.kt

class MainActivity : AppCompatActivity() {
    private lateinit var viewModel: UserViewModel
    private lateinit var tvData: TextView
    private lateinit var btnLoadData: Button

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        tvData = findViewById(R.id.tv_data)

        // ViewModelProvider(this) initializes the provider
        // [UserViewModel::class.java] gets the UserViewModel instance from the provider.
        viewModel = ViewModelProvider(this)[UserViewModel::class.java]

        viewModel.user.observe(this) { user ->
            tvData.text = "${user.name} \n ${user.email}"
        }

        btnLoadData.setOnClickListener {
            viewModel.loadUser()
        }
    }
}

However, MVVM is generally used with the Repository pattern in Android because this combination provides a robust, scalable, and maintainable architecture.

The Repository Pattern is a design pattern that provides an abstraction of data sources, such as databases, network services, or caches. It centralizes data access logic and provides a clean API for the rest of the application.

The combination is very effective because of:

• Separation of Concerns: MVVM handles UI logic, while Repository manages data access.

• Abstraction of Data Sources: Repository hides complexity of multiple data sources.

• Improved Testability: Easier to test ViewModels and data access logic independently.

• Offline-First Approach: Repository can implement caching for offline use.

• Scalability: Easier to add new features or data sources without changing ViewModels.

• Lifecycle Management: ViewModel handles UI-related data, Repository manages long-running operations.

Example:

1. Model Layer

User.kt

data class User(val name: String, val email: String)

UserApi.kt

object UserApi {
    fun getUser(): User {
        // Here you can write the code to fetch data from internet
        // For now, I am returning sample data
        return User("Yashraj", "yash@mail.com")
    }
}

UserRepository.kt

class UserRepository(private val api: UserApi) {
    fun getUser(): User {
        // The data you fetch from api can be cache here in local database
        // For now, I am directly calling it
        return api.getUser()
    }
}

2. ViewModel Layer

UserViewModel.kt

class UserViewModel(private val repository: UserRepository) : ViewModel() {
    private val _user = MutableLiveData<User>()
    val user: LiveData<User> = _user

     fun loadUser() {
        val userData = repository.getUser()
        _user.postValue(userData)
    }
}

ViewModelFactory.kt

// Custom factory to create UserViewModel instances with UserRepository.
class UserViewModelFactory(private val userRepository: UserRepository) : ViewModelProvider.Factory {
    override fun <T : ViewModel> create(modelClass: Class<T>): T {

        // Checks if the requested ViewModel class is UserViewModel.
        // If true, creates UserViewModel with UserRepository.
        if (modelClass.isAssignableFrom(UserViewModel::class.java)) {
            @Suppress("UNCHECKED_CAST")
            return UserViewModel(userRepository) as T
        }
        // else throws an exception.
        throw IllegalArgumentException("Unknown ViewModel class")
    }
}

3. View Layer

(The activity_main.xml layout code will remain same as of the above given example.)

MainActivity.kt

class MainActivity : AppCompatActivity() {

    private lateinit var viewModelFactory: UserViewModelFactory
    private lateinit var tvData: TextView
    private lateinit var btnLoadData: Button
    private lateinit var viewModel: UserViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        tvData = findViewById(R.id.tv_data)
        btnLoadData = findViewById(R.id.btn_load)

        // UserRepository(UserApi) creates the repository with the API.
        val repository = UserRepository(UserApi)

        // UserViewModelFactory(UserRepository(UserApi)) creates the factory with the repository.
        viewModelFactory = UserViewModelFactory(repository)

        // ViewModelProvider(this, viewModelFactory) initializes the provider with the factory.
        // [UserViewModel::class.java] gets the UserViewModel instance from the provider.
        viewModel = ViewModelProvider(this,viewModelFactory)[UserViewModel::class.java]

        // Observe the LiveData from the ViewModel to update the UI when data changes
        viewModel.user.observe(this) { user ->
            tvData.text = "${user.name} \n ${user.email}"
        }

        btnLoadData.setOnClickListener {
            viewModel.loadUser()
        }
    }
}

The output will be the same for both of the above examples in here.

Pros and Cons of MVVM in Android

While MVVM offers many benefits, it's important to consider both its advantages and disadvantages when deciding whether to use it in your Android project.

Pros

1. Separation of Concerns: MVVM clearly separates the user interface (View) from the business logic (ViewModel) and data (Model). This separation makes the code more organized and easier to maintain.

2. Testability: The clear separation of components makes unit testing much easier, especially for the ViewModel and Model. You can test business logic without dealing with Android framework dependencies.

3. Reusability: ViewModels can be shared across multiple Views (Activities or Fragments), promoting code reuse and consistency.

4. Lifecycle Management: ViewModels are lifecycle-aware and survive configuration changes like screen rotations, helping to preserve data and state.

5. Data Binding Support: MVVM works seamlessly with Android's data binding library, which can significantly reduce boilerplate code in the View layer.

6. Scalability: As your app grows, MVVM's structure makes it easier to add new features or modify existing ones without affecting other parts of the app.

Cons

1. Overengineering for Simple Apps: For very small or simple applications, implementing MVVM might be overkill and could unnecessarily complicate the codebase.

2. Boilerplate Code: While MVVM can reduce boilerplate in some areas (especially with data binding), it can increase it in others, particularly when setting up the initial architecture.

3. Risk of bulky ViewModels: Without careful design, ViewModels can become bulky with too much logic, defeating the purpose of separation of concerns.

4. Overuse of Data Binding: While data binding can simplify View code, overuse can lead to complex XML layouts that are hard to understand and maintain.

Conclusion

MVVM architecture, especially when paired with the Repository pattern, offers a robust solution for Android app development. It effectively separates concerns by dividing the app into View (UI), ViewModel (UI logic and state management), and Model (data and business logic) components, with the Repository acting as a centralized data management layer. This separation enhances testability, maintainability, and scalability of the app.

Architectural patterns are essential for building maintainable Android applications. This post examines two popular approaches: Model-View-Controller (MVC) and Model-View-Presenter (MVP). We'll explore their components, advantages, and disadvantages to help you choose the right pattern for your Android projects.

MVC (Model-View-Controller) in Android

Separates an app into data and business logic (Model), user interface (View), and input handling (Controller). Simple to implement but can lead to overly large Controllers in complex apps.

MVC Components:

a) Model:

• Represents the data and business logic of the application.

• Responsible for managing the data, performing calculations, and enforcing business rules.

• Independent of the user interface.

• Can notify observers (usually the Controller) when its state changes.

Example:

data class UserModel(
    var name: String = "",
    var email: String = ""
) {

    fun validate(): Boolean {
        return name.isNotEmpty() && email.contains("@")
    }

    fun save() {
        // Save user to database or server      
    }
}

b) View:

• Responsible for presenting data to the user and receiving user input.

• In Android, this typically consists of XML layout files and custom View classes.

• It should contain little to no business logic.

Example:

<!-- activity_user.xml -->
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <EditText
        android:id="@+id/nameEditText"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:hint="Name" />

    <EditText
        android:id="@+id/emailEditText"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:hint="Email" />

    <Button
        android:id="@+id/saveButton"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Save" />

</LinearLayout>

c) Controller:

• Acts as an intermediary between the Model and View.

• Handles user input from the View, updates the Model, and refreshes the View with updated data.

• In Android, this role is typically filled by Activities or Fragments.

Example:

class UserActivity : AppCompatActivity() {

    private lateinit var userModel: UserModel
    private lateinit var nameEditText: EditText
    private lateinit var emailEditText: EditText
    private lateinit var saveButton: Button

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_user)

        userModel = UserModel()
        nameEditText = findViewById(R.id.nameEditText)
        emailEditText = findViewById(R.id.emailEditText)
        saveButton = findViewById(R.id.saveButton)

        saveButton.setOnClickListener {
            updateModel()
            if (userModel.validate()) {
                userModel.save()
                showSuccessMessage()
            } else {
                showErrorMessage()
            }
        }
    }

    private fun updateModel() {
        userModel.name = nameEditText.text.toString()
        userModel.email = emailEditText.text.toString()
    }

    private fun showSuccessMessage() {
        Toast.makeText(this, "User saved successfully", Toast.LENGTH_SHORT).show()
    }

    private fun showErrorMessage() {
        Toast.makeText(this, "Invalid user data", Toast.LENGTH_SHORT).show()
    }
}

Interactions:

1. User interacts with the View (e.g., enters data in EditTexts).

2. View notifies the Controller of user actions (e.g., button click).

3. Controller updates the Model based on user input.

4. Controller may update the View if necessary (e.g., show error messages).

5. Model may notify the Controller of data changes (in more complex implementations).

6. Controller updates the View to reflect Model changes.

Advantages:

1. Simplicity: Easier to understand and implement, especially for smaller projects.

2. Faster development: Less boilerplate code required.

3. Good for small to medium-sized applications.

4. Direct communication between View and Model can be efficient.

Disadvantages:

1. Tight coupling: Controller often becomes tightly coupled with View.

2. Testability issues: Difficult to unit test due to Android dependencies.

3. Scalability problems: Can become unwieldy in larger, complex applications.

4. Controllers often become too complex, handling many different tasks.

MVP (Model-View-Presenter) in Android

Enhances separation with a Presenter handling presentation logic and View-Model interactions. Improves testability and modularity but requires more initial setup and code.

MVP Components:

a) Model:

• Similar to MVC, represents data and business logic.

• Independent of the user interface.

Example:

data class UserModel(
    var name: String = "",
    var email: String = ""
) {

    fun validate(): Boolean {
        return name.isNotEmpty() && email.contains("@")
    }

    fun save() {
        // Save user to database or server
    }
}

b) View:

• Responsible for displaying data and sending user actions to the Presenter.

• In Android, this is typically an Activity or Fragment implementing a View interface.

• Displays data and forwards user actions to the Presenter.

Example:

interface UserView {
    fun showError(message: String)
    fun showSuccess()
}

class UserActivity : AppCompatActivity(), UserView {

    private lateinit var presenter: UserPresenter
    private lateinit var nameEditText: EditText
    private lateinit var emailEditText: EditText
    private lateinit var saveButton: Button

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_user)

        nameEditText = findViewById(R.id.nameEditText)
        emailEditText = findViewById(R.id.emailEditText)
        saveButton = findViewById(R.id.saveButton)

        presenter = UserPresenter(this, UserModel())

        saveButton.setOnClickListener {
            presenter.onSaveClicked(
                nameEditText.text.toString(),
                emailEditText.text.toString()
            )
        }
    }

    override fun showError(message: String) {
        Toast.makeText(this, message, Toast.LENGTH_SHORT).show()
    }

    override fun showSuccess() {
        Toast.makeText(this, "User saved successfully", Toast.LENGTH_SHORT).show()
    }
}

c) Presenter:

• Acts as an intermediary between Model and View.

• Contains the presentation logic.

• Updates the Model and instructs the View to update itself.

Example:

class UserPresenter(private val view: UserView, private val model: UserModel) {
    fun onSaveClicked(name: String, email: String) {
        model.name = name
        model.email = email

        if (model.validate()) {
            model.save()
            view.showSuccess()
        } else {
            view.showError("Invalid user data")
        }
    }
}

Interactions:

1. User interacts with the View.

2. View calls appropriate method on the Presenter.

3. Presenter updates the Model if necessary.

4. If Model is updated, it performs necessary business logic and data operations.

5. Presenter receives results from the Model and prepares data for display.

6. Presenter updates the View using the view interface.

Advantages:

1. Better separation of concerns: Clear division of responsibilities.

2. Improved testability: Presenter can be easily unit tested.

3. More modular and flexible: Easier to modify or replace individual components.

4. Reduces complexity in Views: Views become very passive.

Disadvantages:

1. More boilerplate code: Requires additional interfaces and classes.

2. More complex architecture to understand and implement.

3. Potential over-engineering for simple apps.

4. Risk of tight coupling between Presenter and View if not carefully designed.

The output will be same in the above given examples for MVC and MVP.

Key Differences

1. Separation of Logic:

   • MVC: Controller handles user input and some business logic.

   • MVP: Presenter contains all presentation logic.

2. View-Model Interaction:

   • MVC: View can directly observe Model changes.

   • MVP: View never interacts directly with Model, all goes through Presenter.

3. Testability:

   • MVC: Generally harder to unit test due to Android dependencies.

   • MVP: Easier to unit test, especially the Presenter.

4. Complexity:

   • MVC: Simpler for small applications.

   • MVP: Better suited for larger, more complex applications.

5. Code Distribution:

   • MVC: Logic often concentrated in Controller.

   • MVP: Logic more evenly distributed between Model and Presenter.

Conclusion

MVC and MVP offer different advantages for Android development. MVC is simpler and faster for small projects, while MVP provides better separation of concerns for complex applications. Your choice depends on project needs and team expertise.

A task in Android is a collection of activities that users interact with when trying to do something in your app, representing an application’s workflow where each activity is a focused action that a user can do. A task usually starts when a user launches an application and can include multiple activities across different applications. When you tap the app's launcher icon, the system searches for an existing task that matches the Intent and Activity. If it finds one, it resumes that task, bringing you back to where you left off. If no matching task is found, a new task is created with the newly launched activity as the base activity on the task’s back stack.

Here is an example showing how the app closes on Activity 3 and, after the app is launched again, it resumes from the same activity:

Understanding the Backstack

The backstack in Android is a Last In, First Out (LIFO) stack that maintains the order of activities the user interacts with. When a new activity starts, it is pushed onto the backstack. Pressing the back button pops the topmost activity off the stack, resuming the previous activity.

Here’s an example showing how activities are added to the backstack:

class Activity1 : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_1)

        val btnLaunch = findViewById<Button>(R.id.btn_launch_activity_2)
        btnLaunch.setOnClickListener {
            startActivity(Intent(this, Activity2::class.java))
        }
    }
}

class Activity2 : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_2)

        val btnLaunch = findViewById<Button>(R.id.btn_launch_activity_3)
        btnLaunch.setOnClickListener {
            startActivity(Intent(this, Activity3::class.java))
        }
    }
}

class Activity3 : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_3)
    }
}

1. When the app is first launched, Activity1 is added to the backstack.

2. Upon clicking "Launch Activity 2" button in Activity1, Activity2 is launched and added to the backstack.

3. Similarly, clicking "Launch Activity 3" button in Activity2 launches Activity3, adding it to the backstack.

In this example, starting from Activity1, launching Activity2 adds it to the backstack. Similarly, launching Activity3 from Activity2 pushes it onto the backstack. If you press the back button in Activity3 will pop it off the stack, resuming Activity2.

Launch Modes

Launch modes determine how activities are launched and associated with tasks. To specify launch modes in an Android application, you define them in the AndroidManifest.xml file within the <activity> element using the android:launchMode attribute. Example:

<manifest>
    <application ...>
        ...
        <activity
            android:name=".DemoActivity"
            android:launchMode="standard">
        </activity>
    </application>
</manifest>

There are four launch modes in Android:

1. Standard (default)

2. SingleTop

3. SingleTask

4. SingleInstance

Standard

This default launch mode creates a new instance of the activity each time it’s launched, even if an instance already exists. For example, if activities A, B, and C are in a task, and B is launched again, the task becomes A → B → C → B, with a new instance of B. You do not need to set anything for the standard launch mode since it is the default. However, for clarity, you can explicitly set it as follows:

<manifest>
    <application ...>
        ...
        <activity
            android:name=".Activity_B"
            android:launchMode="standard">
        </activity>
    </application>
</manifest>

SingleTop

If an instance of the activity is already at the top of the backstack, it is not recreated; instead, the existing instance receives the intent via the onNewIntent() method. If a new instance is not present at the top then a new instance will be created. For example, we have activities A, B, and C, launching B will create a new instance of activity B as it is not at the top then we will get A → B → C → B, launching B again results in A → B → C → B (same instance), where onNewIntent() is called. To specify the SingleTop launch mode:

<manifest>
    <application ...>
        ...
        <activity
            android:name=".Activity_B"
            android:launchMode="singleTop">
        </activity>
    </application>
</manifest>

SingleTask

An activity with the singleTask launch mode can have only one instance in the system at a time. If no instance exists, a new one is created. If an instance is already present, instead of creating a new one, the existing instance handles the intent through the onNewIntent() method. For example, with activities A, B, and C, launching D (singleTask) results in A → B → C → D, a new instance of D is created. If B is also singleTask and is launched, the task becomes A → B, removing C and D. This means that the existing instance of B is reused, and the intent data is routed through the onNewIntent() method. To specify the SingleTask launch mode:

<manifest>
    <application ...>
        ...
        <activity
            android:name=".Activity_B"
            android:launchMode="singleTask">
        </activity>
    </application>
</manifest>

SingleInstance

Similar to SingleTask but stricter, this mode allows the activity to be the only one in its task, making it completely isolated. For example, launching D (singleInstance) from a task with A, B, and C results in two separate tasks: Task 1 (A → B → C) and Task 2 (D). If D is launched again, the existing instance handles the intent with onNewIntent(). To specify the SingleInstance launch mode:

<manifest>
    <application ...>
        ...
        <activity
            android:name=".Activity_D"
            android:launchMode="singleInstance">
        </activity>
    </application>
</manifest>

In Android, a fragment is a reusable portion of your app's user interface. You can think of a fragment as a mini-activity within an activity. Like activities, fragments have their own lifecycle, meaning they go through stages such as creation, starting, pausing, stopping, and destroying. A fragment receives its own input events, and you can add or remove it while the activity is running.

Why Use Fragments?

Here are some key reasons why fragments are useful:

1. Modularity: Fragments allow you to divide your UI into smaller, manageable pieces. This makes your code easier to manage and maintain.

2. Reusability: You can reuse fragments in multiple activities, reducing redundancy and saving time.

3. Adaptability: Fragments help you create flexible UIs that work on different screen sizes and orientations.

   For example, a tablet can display multiple fragments side by side, while a phone might show them one at a time.

Image Source: https://developer.android.com/guide/fragments

How to Create a Fragment?

Creating a fragment is similar to creating an activity. Here’s a basic example:

1. Create a new class DemoFragment that extends Fragment and override its methods to insert your app logic.

class DemoFragment : Fragment() {

    private val TAG = "DemoFragment"

    override fun onAttach(context: Context) {
        super.onAttach(context)
        Log.d(TAG, "onAttach: Fragment attached to activity")
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        Log.d(TAG, "onCreate: Fragment create")
    }

    override fun onCreateView(
        inflater: LayoutInflater, container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {

        Log.d(TAG, "onCreateView: Fragment create view")
       // Inflate the layout for this fragment
        return inflater.inflate(R.layout.fragment_demo, container, false)
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        Log.d(TAG, "onViewCreated: Fragment view created")
    }

    override fun onStart() {
        super.onStart()
        Log.d(TAG, "onStart: Fragment started")
    }

    override fun onResume() {
        super.onResume()
        Log.d(TAG, "onResume: Fragment resumed")
    }-

    override fun onPause() {
        super.onPause()
        Log.d(TAG, "onPause: Fragment paused")
    }

    override fun onStop() {
        super.onStop()
        Log.d(TAG, "onStop: Fragment stopped")
    }

    override fun onDestroyView() {
        super.onDestroyView()
        Log.d(TAG, "onDestroyView: Fragment view destroyed")
    }

    override fun onDestroy() {
        super.onDestroy()
        Log.d(TAG, "onDestroy: Fragment destroyed")
    }

    override fun onDetach() {
        super.onDetach()
        Log.d(TAG, "onDetach: Fragment detached from activity")
    }

}

2. In your activity, instantiate and add the fragment using FragmentManager.

class FragmentHolderActivity : AppCompatActivity() {

    private val TAG = "FragmentHolderActivity"

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_fragment_holder)

        if (savedInstanceState == null) {
        // Get the FragmentManager to interact with fragments associated with this activity
            val fragmentManager: FragmentManager = supportFragmentManager
        // Begin a new fragment transaction
            val fragmentTransaction: FragmentTransaction = fragmentManager.beginTransaction()
        // Create a new instance of DemoFragment
            val fragment = DemoFragment()
        // Add the fragment to the container specified by its ID (R.id.fragment_container)
            fragmentTransaction.add(R.id.fragment_container, fragment)
        // Commit the transaction to apply the changes
            fragmentTransaction.commit()
        }
        Log.d(TAG, "onCreate: Activity created")
    }

    override fun onStart() {
        super.onStart()
        Log.d(TAG, "onStart: Activity started")
    }

    override fun onResume() {
        super.onResume()
        Log.d(TAG, "onResume: Activity resumed")
    }

    override fun onPause() {
        super.onPause()
        Log.d(TAG, "onPause: Activity paused")
    }

    override fun onStop() {
        super.onStop()
        Log.d(TAG, "onStop: Activity stopped")
    }

    override fun onRestart() {
        super.onRestart()
        Log.d(TAG, "onRestart: Activity restarted")
    }

    override fun onDestroy() {
        super.onDestroy()
        Log.d(TAG, "onDestroy: Activity destroyed")
    }
}

Note: The fragment transaction is created only when savedInstanceState is null. This ensures the fragment is added just once when the activity starts initially. When a configuration change happens and the activity is recreated, savedInstanceState isn't null anymore. In this case, the fragment isn't added again; it's automatically restored from savedInstanceState.

3. Include a FragmentContainerView in your activity's layout file where the fragment will be placed.

<?xml version="1.0" encoding="utf-8"?>
<androidx.fragment.app.FragmentContainerView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:id="@+id/fragment_container" />

FragmentManager: The main class to manage fragment operations like adding, removing, replacing fragments, and handling the fragment back stack.

FragmentTransaction: Used to perform a set of fragment operations (like adding, replacing, or removing fragments) in a single atomic action.

• Adding Fragments: Attach fragments to an activity.

• Removing Fragments: Detach fragments from an activity.

• Replacing Fragments: Replace existing fragments with new ones.

• Finding Fragments: Find fragments by their ID or tag.

Fragment Lifecycle

The lifecycle of fragment goes through the following stages:

1. 

   onAttach(): Called when the fragment is first attached to its host activity.

2. onCreate(): The fragment is created. The saved instance state can be used to restore the fragment's previous state.

3. onCreateView(): Called to create the view hierarchy associated with the fragment.

4. onViewCreated(): Called immediately after onCreateView(). You can perform any additional setup of the fragment's view here.

5. onStart(): Called when the fragment is visible to the user.

6. onResume(): Called when the fragment is visible and actively running.

7. onPause(): Called when the fragment is not actively running.

8. onStop(): Called when the fragment is no longer visible to the user.

9. onDestroyView(): Called to clean up resources associated with the view.

10. onDestroy(): Called when the fragment is destroyed.

11. onDetach(): Called when the fragment has been detached from the activity.

• Lifecycle methods execution when the app is launched (refer to the code above on how to create a fragment):

This demonstrates the sequence of fragment and activity lifecycle methods executed when the app is launched.

• Lifecycle methods execution when the app is closed and removed from the background (refer to the code above on how to create a fragment).

This demonstrates the order of fragment and activity lifecycle methods executed when the app is closed and removed from the background.

Conclusion

Fragments serve as modular components that allow you to build dynamic and flexible UIs in Android. They make it easier to manage complex interfaces and ensure your app works well on various devices. By using fragments, you can create better and more adaptable Android applications.

An Intent is a message object that represents a request for an action to be performed. It can be used to start activities, services, or broadcast receivers. In simple terms, Intents act as a bridge to pass information and instructions between different components of your application or between different applications.

How Intents Work

When an Intent is created and sent, the Android system uses it to figure out which component should respond to the request. Depending on the type of Intent and how it's used, the system may:

• Start an Activity: Move the user to a different screen.

• Start a Service: Perform background tasks without user interaction.

• Deliver a Broadcast: Send messages to multiple components interested in system-wide or app-wide events.

Types of Intents

1. Explicit Intents

2. Implicit Intents

Explicit Intent

An Explicit Intent specifies the exact component to start by name. This is commonly used within an application when you know which activity or service you want to start.

Example 1: Here’s how to launch another activity within the same app using explicit intent.

class IntentSenderActivity: AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_intent_sender)

        val btnLaunch = findViewById<Button>(R.id.btn_launch)

        btnLaunch.setOnClickListener {
            // Create an explicit Intent to start IntentReceiverActivity
           val intent = Intent(this, IntentReceiverActivity::class.java)
            // Start the activity specified by the Intent
           startActivity(intent)
        }
    }
}

Example 2: Launching a Calculator App Using Explicit Intent

Here we will launch the calculator app installed on your phone. To do so, you need the name of the package and the name of the class that implements the component.

Steps to Retrieve Package Name and Main Activity:

1. Open a terminal and connect to your Android device:

adb shell

2. List all installed packages:

pm list packages

3. Filter the list to find the calculator package:

pm list packages | grep calculator

Here you will get the package name of the calculator app, i.e., com.oneplus.calculator.

4. Get the main activity of the calculator app:

//dumpsys package <package_name> | grep -A 1 "MAIN"
dumpsys package com.oneplus.calculator | grep -A 1 "MAIN"

Here we get the package name com.oneplus.calculator and the name of the main component which is the launcher activity com.android.calculator2.activity.MiniActivity .

class IntentSenderActivity: AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_intent_sender)

        val btnLaunch = findViewById<Button>(R.id.btn_launch)
        btnLaunch.setOnClickListener {
            // Create an implicit Intent with the ACTION_MAIN action
            val intent = Intent(Intent.ACTION_MAIN)
            // Set the component to target the calculator app
            intent.setComponent(ComponentName("com.oneplus.calculator", "com.android.calculator2.Calculator"))
            try {
                // Attempt to start the calculator activity
                startActivity(intent)
            } catch (e: Exception) {
                // Show a Toast message if the calculator app is not found
                Toast.makeText(this, "Calculator app not found", Toast.LENGTH_SHORT).show()
            }
        }
    }
}

Implicit Intent

Used when you declare an action to be performed. The system determines the appropriate component(s) to handle the intent based on the intent filter declarations in the manifest of other apps.

Example: Here’s how to launch the dialer app using an implicit intent.

class IntentReceiverActivity: AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_intent_receiver)

        val btnLaunch = findViewById<Button>(R.id.btn_launch)

        btnLaunch.setOnClickListener {
            // Create an implicit Intent with the ACTION_DIAL action
            val intent = Intent(Intent.ACTION_DIAL)
            // Set the data to a phone number URI
            intent.data = Uri.parse("tel:1234567890")
            // Create a chooser dialog for the Intent
            val chooser = Intent.createChooser(intent, "Choose Dialer")
            // Start the activity specified by the chooser
            startActivity(chooser)
        }
    }
}

In this example, a chooser is created to display a chooser dialog, allowing you to select the desired dialer app. If you do not create a chooser as shown in the code below,

val intent = Intent(Intent.ACTION_DIAL)
intent.data = Uri.parse("tel:1234567890")
startActivity(intent)

and directly launch the intent, the system will automatically use the default app set for that functionality (in this case, the dialer app). As a result, the chooser dialog will not appear, and the default app will be launched instead.

However, if no default app is set and if multiple matches are found, the system presents a chooser dialog to the user, allowing them to select the preferred app.

Intent Filters

An Intent Filter is an expression in an app's manifest file that specifies the types of Intents the component can respond to. It allows the system to determine which components can handle a given Intent.

Key Elements of Intent Filters

1. action: Specifies the general action to be performed, such as ACTION_VIEW, ACTION_EDIT, or ACTION_SEND.

2. category: Provides additional information about the action to be performed, like CATEGORY_DEFAULT or CATEGORY_BROWSABLE.

3. data: Specifies the type of data the intent is expecting, using schemes, host names, MIME types, etc.

When an app sends an Implicit Intent, the Android system matches it against the Intent Filters of all installed apps. If a match is found, the system launches the corresponding component. If multiple matches are found, the system presents a chooser dialog to the user, allowing them to select the preferred app.

Example: Here's how you can receive data from another app using intent filter.

1. Create an activity where we will be receiving an image which will be shared from a browser app.

class IntentReceiverActivity : AppCompatActivity() {

    private lateinit var imageView: ImageView

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_intent_receiver)

        imageView = findViewById(R.id.imageView)

        // Handle the initial Intent that started the activity
        handleIntent(intent)
    }

    override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)

        // Handle any new Intents received while the activity is already running
        handleIntent(intent)
    }

    // Function to handle the Intent and extract the URI of the image
    private fun handleIntent(intent: Intent) {

        // Get the URI from the Intent extras
        val uri = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
            intent.getParcelableExtra(Intent.EXTRA_STREAM, Uri::class.java)
        } else {
            intent.getParcelableExtra(Intent.EXTRA_STREAM)
        }

        // If the URI is not null, set it as the image source for the ImageView
        uri?.let {
            imageView.setImageURI(it)
        }
    }
}

When sharing an image from the browser app, if the activity is not already running, the onCreate() method is called. Inside onCreate(), the handleIntent() method processes the data (image URI). If the activity is already running, onCreate() is not called; instead, onNewIntent() is triggered, where we again call the handleIntent() method to handle the new data.

2. Inside the manifest file, declare the IntentReceiverActivity and the intent filters.

<manifest>
    <application ...>
        ...
        <activity
            android:name="._05intent.IntentReceiverActivity"
            android:exported="true"
            android:label="Intents Receiver"
            android:launchMode="singleTop" >
            <intent-filter>

                <!-- Filter for SEND action -->
                <action android:name="android.intent.action.SEND" />

                <!-- Category default is required for most implicit intents -->
                <category android:name="android.intent.category.DEFAULT" />

                <!-- Specify the MIME type for the data the activity can handle -->
                <data android:mimeType="image/*" />
            </intent-filter>
        </activity>
    </application>
</manifest>

1. <activity>:

   • Declares an activity that is part of the application.

   • android:name: Specifies the class name of the activity.

   • android:exported: Indicates whether the activity can be launched by components of other applications.

   • android:label: Specifies the user-readable name for the activity, displayed in the UI.

   • android:launchMode: Determines how the activity is launched, with "singleTop" preventing multiple instances if one already exists at the top of the stack.v

2. <intent-filter>:

   • Describes the types of intents the activity can respond to.

   • <action android:name="android.intent.action.SEND" />:

     • Specifies that the activity can handle the SEND action, which is used when an app sends data to another app.

   • <category android:name="android.intent.category.DEFAULT" />:

     • Indicates that the activity can handle the default category of intents. This is required for most implicit intents.

   • <data android:mimeType="image/*" />:

     • Specifies the type of data the activity can handle. In this case, the activity is set up to handle image files.

This configuration ensures that the IntentReceiverActivity can be launched when an image is shared using an Intent with the SEND action and the MIME type of image/*.

Conclusion

Understanding intents and intent filters is essential for developing Android apps that communicate effectively with each other and provide a seamless user experience. Intents allow you to start activities, services, and broadcast receivers, enabling different app components to work together. By using explicit intents, you can target specific components, while implicit intents allow the system to choose the best component to handle the action. Intent filters in the manifest help declare what types of intents an activity can handle. With this knowledge, you can create more dynamic and interactive Android applications.

An Activity is an application component that provides a screen for user interaction, allowing users to perform tasks like taking a photo, sending a message, or playing a video. Each activity is given a window to draw its user interface, typically filling the screen but sometimes smaller and floating over other windows.

An application can have multiple activities, loosely bound to each other, with each activity declared in the manifest file. One activity is usually designated as the "main" or "launcher" activity, presented to the user when the application is launched for the first time. Each activity can start other activities to perform different actions.

Activity Lifecycle

Activities are managed by the Android operating system and follow a lifecycle consisting of various states and callbacks. Understanding the activity lifecycle is crucial for managing resources, handling user interactions, and maintaining a smooth user experience.

Here is a diagrammatic representation of activity lifecycle:

Here's a brief overview of the different states and callbacks in the lifecycle:

1. onCreate():

   • This is the first callback called when an activity is created.

   • Initialize essential components, set up the user interface, and perform any one-time setup tasks.

2. onStart():

   • The activity enters the "started" state after onCreate().

   • The activity becomes visible to the user but doesn't have focus yet.

3. onResume():

   • The activity moves to the "resumed" state and comes into the foreground.

   • It is now fully visible and ready to receive user input.

   • Start animations, initialize sensors, or register broadcast receivers here.

4. onPause():

   • Triggered when the activity loses focus and goes into the background.

   • The activity is still partially visible but no longer has user input focus.

   • Release resources, pause animations, or save persistent data for a smooth transition.

5. onStop():

   • The activity enters the "stopped" state when it is no longer visible to the user.

   • This can happen when the user navigates away from the activity.

   • Perform operations that should happen when the activity is not visible, such as saving data or releasing resources that are not needed while the activity is not in the foreground.

6. onRestart():

   • Invoked if an activity was stopped and is now being restarted, before onStart().

   • Perform any necessary setup before the activity becomes visible again.

7. onDestroy():

   • The final callback in the activity lifecycle, called when the system is about to destroy the activity.

   • Clean up all remaining resources, unregister receivers, and ensure all necessary data is saved.

Example:

1. Activity Declaration:

   • Define the activity class in your application. This is where you initialize components and set up the user interface.

class DemoActivity : AppCompatActivity() {

    private val TAG = "Demo_Activity"

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_demo)
        Log.d(TAG, "onCreate: ")
    }

    override fun onStart() {
        super.onStart()
        Log.d(TAG, "onStart: ")
    }

    override fun onResume() {
        super.onResume()
        Log.d(TAG, "onResume: ")
    }

    override fun onPause() {
        super.onPause()
        Log.d(TAG, "onPause: ")
    }

    override fun onStop() {
        super.onStop()
        Log.d(TAG, "onStop: ")
    }

    override fun onRestart() {
        super.onRestart()
        Log.d(TAG, "onRestart: ")
    }

    override fun onDestroy() {
        super.onDestroy()
        Log.d(TAG, "onDestroy: ")
    }

}

2. Manifest File:

   • Ensure your activity is declared in the manifest file. This is crucial for the Android system to recognize and manage your activity.

   • Intent Filter:

     • Add an <intent-filter> to specify the types of intents the activity can handle.

     • For the launcher activity, include:

       • <action android:name="android.intent.action.MAIN" /> to indicate the entry point of the application.

       • <category android:name="android.intent.category.LAUNCHER" /> to specify that this activity should appear in the app launcher.

    <manifest>
        <application ...>
        ...
            <activity
                android:name="._04activities.DemoActivity"
                android:exported="false" >
                <intent-filter>
                    <action android:name="android.intent.action.MAIN" />

                    <category android:name="android.intent.category.LAUNCHER" />
                </intent-filter>
            </activity>
        </application>
    </manifest>

Lifecycle Methods Execution in Different Scenarios

1. When the App is Launched:

   The activity goes through the following lifecycle methods:

   • onCreate()

   • onStart()

   • onResume()

2. When There is a Configuration Change (e.g., Screen Rotation):

   The activity handles the configuration change by going through these lifecycle methods:

   • onPause()

   • onStop()

   • onDestroy()

   • onCreate()

   • onStart()

   • onResume()

3. When the App is Closed and Removed from the Background:

   • When the app is moved to the background, the activity goes through:

     • onPause()

     • onStop()

   • When the app is removed from the background, the activity enters:

     • onDestroy()

Conclusion

In conclusion, Android activities are essential for creating engaging and dynamic user interfaces in apps. From initializing components in onCreate() to managing resources and responding to user interactions throughout its lifecycle, each activity plays a key role in delivering a seamless user experience. By understanding and effectively managing the activity lifecycle, you can optimize the performance, ensure efficient resource utilization, and enhance overall app reliability.

A content provider in Android provides secure access to a central repository of data that can be stored in a variety of formats, such as a SQLite database, a file, or a web service. It provides a standardized interface for other applications to securely access or modify the data as needed. In activities or fragments, we typically use a ContentResolver object within our application context to interact with content providers. The ContentResolver communicates with the provider, which is an instance of a class implementing ContentProvider.

What is a Cursor?

When querying a ContentProvider, the result is typically returned as a Cursor object. A Cursor provides read-write access to the result set of a database query. It allows you to move through the data, retrieve column values, and perform other operations on the result set. When using a ContentResolver to query a ContentProvider, you'll typically receive and work with a Cursor to access the returned data.

What is a Content Provider?

A content provider in Android helps to securely share data between applications by providing an abstraction layer. It exposes a set of CRUD (Create, Read, Update, Delete) operations that can be performed on the data, allowing applications to access data from different sources such as a database, a file, or a web service.

Example Implementation

Here I have created a custom ContentProvider which will be sharing the data with other apps. Also, I have used SharedPreference for storage here, you can use SQLite database or any other means of storage.

Provider App

1. ContentProvider Implementation (PreferencesContentProvider.kt):

// PreferencesContentProvider class to expose SharedPreferences via a ContentProvider
class PreferencesContentProvider : ContentProvider() {

    // SharedPreferences instance
    private lateinit var preferences: SharedPreferences

    // Called when the provider is created
    override fun onCreate(): Boolean {
        preferences = PreferenceManager.getDefaultSharedPreferences(context)
        return true
    }

    // Handle query requests from clients
    override fun query(
        uri: Uri,
        projection: Array<out String>?,
        selection: String?,
        selectionArgs: Array<out String>?,
        sortOrder: String?
    ): Cursor? {
        // Create a cursor to hold the key-value pairs from SharedPreferences
        val matrixCursor = MatrixCursor(arrayOf("key", "value"))
        val allEntries = preferences.all
        for ((key, value) in allEntries) {
            // Add each key-value pair to the cursor
            matrixCursor.addRow(arrayOf(key, value.toString()))
        }
        return matrixCursor
    }

    // Return the MIME type of data in the content provider
    override fun getType(uri: Uri): String? {
        return "vnd.android.cursor.dir/vnd.${PreferencesContract.AUTHORITY}.preferences"
    }

    // Handle requests to insert a new row
    override fun insert(uri: Uri, values: ContentValues?): Uri? {
        val editor = preferences.edit()
        values?.let {
            for (key in it.keySet()) {
                val value = it.getAsString(key)
                Log.d("TAG", "insert: $key $value")
                // Save each key-value pair to SharedPreferences
                editor.putString(key, value)
            }
        }
        editor.apply()
        // Notify any listeners that the data has changed
        context?.contentResolver?.notifyChange(uri, null)
        return uri
    }

    // Handle requests to delete one or more rows
    override fun delete(uri: Uri, selection: String?, selectionArgs: Array<out String>?): Int {
        val editor = preferences.edit()
        selectionArgs?.forEach { key ->
            // Remove each key specified in the selectionArgs
            editor.remove(key)
        }
        editor.apply()
        // Notify any listeners that the data has changed
        context?.contentResolver?.notifyChange(uri, null)
        return selectionArgs?.size ?: 0
    }

    // Handle requests to update one or more rows
    override fun update(uri: Uri, values: ContentValues?, selection: String?, selectionArgs: Array<out String>?): Int {
        // Use the insert method to handle updates as well
        return insert(uri, values)?.let { 1 } ?: 0
    }
}

// Object to define the contract for accessing the content provider
object PreferencesContract {
    const val AUTHORITY = "com.example.blogs._3content_providers"
    val CONTENT_URI: Uri = Uri.parse("content://$AUTHORITY/preferences")
}

MatrixCursor is a mutable cursor implementation backed by an array of objects. Unlike cursors tied to database results, MatrixCursor allows for the dynamic addition of rows directly in memory, making it ideal for creating custom, in-memory datasets. This feature is particularly useful in scenarios where data does not originate from a database, such as data from SharedPreferences. In this ContentProvider implementation, MatrixCursor is used to create a cursor-like interface for SharedPreferences data, enabling seamless integration and manipulation as if it were retrieved from a database. It allows us to:

• Define custom columns ("key" and "value") that match our SharedPreferences structure.

• Dynamically add rows for each key-value pair in SharedPreferences.

• Return a Cursor object that client application can use to read the data, maintaining a consistent interface with other ContentProviders.

• Avoid the need for an actual database, as SharedPreferences is already an efficient key-value store.

2. Declare ContentProvider in AndroidManifest.xml:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="com.example.blogs">

    <application 
        ...>
        ...
        <provider
         android:name="com.example.blogs._3content_providers.PreferencesContentProvider"
         android:authorities="com.example.blogs._3content_providers"
         android:enabled="true"
         android:exported="true"
         android:grantUriPermissions="true" />

    </application>
</manifest>

3. Activity to Save Data (ContentProviderActivity.kt):

class ContentProviderActivity : AppCompatActivity() {

    private lateinit var binding: ActivityContentProviderBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityContentProviderBinding.inflate(layoutInflater)
        setContentView(binding.root)
        binding.apply {
            btnSaveData.setOnClickListener {
                insertPreference("name", etSampleData.text.toString())
                etSampleData.text.clear()
            }
        }
    }

    private fun insertPreference(key: String, value: String) {
        val uri = PreferencesContract.CONTENT_URI
        val values = ContentValues().apply {
            put(key, value)
        }
        contentResolver.insert(uri, values)
    }
}

Some Built-in Content Providers in Android

• ContactsContract:

  This built-in content provider is used to provide access to the device's contact data such as a phone number or an email address.

• MediaStore:

  This built-in content provider is used to provide access to the device's media files such as videos, photos, and also audio recordings.

What is a Content Resolver?

A ContentResolver is an object that acts as an intermediary to communicate with content providers. When we need to access a content provider, we use a ContentResolver object within our application context. The ContentResolver sends data requests to the provider, which performs the requested actions and returns the results back to the ContentResolver. This process allows secure data sharing between different applications.

The ContentResolver is used to perform operations like querying, inserting, updating, and deleting data through the ContentProvider. It uses URIs to specify the content and operations.

Here's how you can use the ContentResolver to query the data exposed by the PreferencesContentProvider. In the code below, I have shown how you can receive the data shared by our provider app:

class ResolverActivity : AppCompatActivity() {

    private lateinit var binding: ActivityResolverBinding
    private lateinit var text: String

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityResolverBinding.inflate(layoutInflater)
        setContentView(binding.root)

        queryPreferences()
        binding.btnGetData.setOnClickListener {
            queryPreferences()
            binding.tvProviderData.text = text
        }
    }

    private fun queryPreferences() {
        // Define the URI for the content to access
        val uri = PreferencesContract.CONTENT_URI

        // Define the columns to retrieve
        val projection = arrayOf("key", "value")

        // Use the content resolver to query the content provider
        val cursor = contentResolver.query(uri, projection, null, null, null)

        cursor?.apply {
            // Iterate through the cursor rows
            while (moveToNext()) {
                // Get the key and value from the current row
                val key = getString(getColumnIndexOrThrow("key"))
                val value = getString(getColumnIndexOrThrow("value"))

            // Assign the value to text variable
                Log.d("TAG", "queryPreferences: Key: $key, Value: $value")
                text = value
            }
            // Close the cursor to release resources
            close()
        }
    }
}

// Define the PreferencesContract object to store constants related to the content provider
object PreferencesContract {
    // The authority of the content provider
    const val AUTHORITY = "com.example.blogs._3content_providers"

    // The URI for the preferences table
    val CONTENT_URI: Uri = Uri.parse("content://$AUTHORITY/preferences")
}

In the manifest file, we will write the package name of our provider app

<manifest>
   <queries>
      <package android:name="com.example.blogs" />
   </queries>
   <application
        ...>
        ....
    </application>
<manifest>

Conclusion

By using a ContentProvider, you can securely share data between applications, providing a standardized interface for CRUD operations. The example shows how to create a custom ContentProvider to expose SharedPreferences data and access it from another application using a ContentResolver. Using proper URI matching and handling ensures secure and organized access to the shared data. Understanding the role of the ContentResolver is critical, as it serves as the bridge between the client application and the ContentProvider, allowing seamless data access and manipulation.

The Snap & Search app is a game-changer in the world of visual search. Its sleek and user-friendly interface allows you to capture screenshots and instantly search with Google Lens, providing accurate and relevant information about anything you see on your screen.

Capturing screenshots is a breeze with Snap & Search. For Android 9 and later versions, you can use the handy floating button provided by the app. This floating button can be customized to your liking - you can change its color, size, and even transparency to suit your preferences. If you're on Android 12 or higher, you have the additional option to simply long-press the home button to capture a screenshot.

One of the standout features of Snap N Search is its commitment to privacy. Unlike many other apps, it doesn't require any storage permissions, ensuring that your data remains secure and private. Additionally, the app itself doesn't require internet access, which means that none of your data is sent anywhere unless you actively choose to use Google Lens, which does require an internet connection.

Using Snap N Search is incredibly simple. Just capture a screenshot of anything you want to explore, whether it's a product label, a piece of text, or even a landmark. The app will then seamlessly integrate with Google Lens, providing you with detailed information, translations, and even the ability to search for similar images or products.

One of the most exciting aspects of Snap N Search is its open-source nature. By making the app's source code available to the community, the developers are promoting transparency and encouraging community-driven development.

Whether you're a curious explorer, a savvy shopper, or simply someone who wants to learn more about the world around them, Snap N Search is the perfect companion app. With its powerful visual search capabilities, privacy-focused design, and user-friendly interface, it's sure to become an essential tool in your digital arsenal.

So why wait? Download Snap & Search today and start exploring the world with just a snap!. And if you need any guidance, be sure to check out the helpful tutorial video that walks you through using all of the app's great features.

Services is an Android app component that is used to perform long-running task in the background that does not have a UI. It can be used for various functionalities which don't need user input such as playing music, downloading data, watching network traffic and much more. Services can also be used for building a continuous connection to a distant server, for various purposes such as sending or receiving messages from a chat server.

Types of Services in Android

• Foreground Services

• Background Services

• Bound Services

Foreground Services

Foreground services are those services that notify the users about ongoing operations by displaying a notification in the notification bar. Users can interact with the service through the notification provided by the task. These services can keep running even if the app is terminated. Example use cases:

1. A music streaming app uses a foreground service for continuous playback and player controls.

2. A video call app employs a foreground service for maintaining an active call session with video and audio.

3. An audio recording app starts a foreground service for capturing high-quality audio recordings.

Here is a simple example code for a Foreground Service:

Service Class (ForegroundService.kt):

class ForegroundService : Service() {
    private val TAG = "ForegroundService"
    companion object {
        var isServiceRunning = false
    }

    override fun onCreate() {
        super.onCreate()
        showToast("Service is being created")
    }

    @RequiresApi(Build.VERSION_CODES.O)
    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        showToast("Service is starting")
        isServiceRunning = true
        val notificationManager =
            this.getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager

        // Create a notification channel
        val channel = NotificationChannel(
            "notification-channel-id",
            "notification-channel-name",
            NotificationManager.IMPORTANCE_DEFAULT
        )
        notificationManager.createNotificationChannel(channel)

        // Build the notification
        val notification =
            NotificationCompat.Builder(this, "notification-channel-id")
                .setSmallIcon(R.mipmap.ic_launcher)
                .setContentText("Foreground Service Running!")
                .setContentTitle("Foreground Service")
                .build()

        // Start the service in the foreground with the notification   
        startForeground(1, notification)

        return super.onStartCommand(intent, flags, startId)
    }

    override fun onDestroy() {
        isServiceRunning = false
        showToast("Service is being destroyed")
        super.onDestroy()
    }

    override fun onBind(intent: Intent?): IBinder? {
        return null
    }

    fun showToast(message: String) {
        Toast.makeText(this, message, Toast.LENGTH_SHORT).show()
    }
}

Activity Class (ServiceActivity.kt):

class ServiceActivity : AppCompatActivity() {

    private lateinit var binding: Activity2serviceBinding
    private lateinit var foregroundIntent: Intent

    @RequiresApi(Build.VERSION_CODES.O)
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = Activity2serviceBinding.inflate(layoutInflater)
        setContentView(binding.root)

        // Create an intent to start ForegroundService
        foregroundIntent= Intent(this, ForegroundService::class.java)

        binding.startService.setOnClickListener {
             // Check if ForegroundService is already running
            if (ForegroundService.isServiceRunning) {
                Toast.makeText(this, "Service is already running", Toast.LENGTH_SHORT).show()
            } else {
                // Start the ForegroundService if not already running
                startService(foregroundIntent)
            }
        }
        binding.stopService.setOnClickListener {
            // Stop the ForegroundService
            stopService(foregroundIntent)
        }  
    }
}

Manifest File (AndroidManifest.kt):

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools" >

<!-- Permission to post notifications. Required for foreground services to show notifications. -->
    <uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

<!-- Permission to run foreground services. Required to start services in the foreground. -->
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />

<application>
        <!-- Other application components like activities and receivers -->
...


<!-- Declaration of the ForegroundService. This tells the system about the service so it can be started and used by the app. -->
<service android:name=".ForegroundService"/>
</application>
</manifest>

Background Services

Background Services are those that perform tasks without directly notifying the users or requiring interaction from users. These services work in the background, i.e., they can continue running even when the app is not actively visible on the screen or when the device is locked. However, it's important to note that if the app is stopped or no longer running, background services associated with that app will also stop running, as they are tied to the lifecycle of the app. Example use cases:

1. A backup app initiates background services for scheduled backups of user data to cloud storage.

2. A news app uses background services to fetch and update news feeds at set intervals.

3. An app that syncs data with a server uses background services for periodic synchronization without user intervention.

Here is a simple example code for a Background Service:

Service Class (BackgroundService.kt):

class BackgroundService : Service() {

    override fun onCreate() {
        super.onCreate()
        showToast("Service is being created")
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        showToast("Service is starting")
        return super.onStartCommand(intent, flags, startId)
    }

    override fun onDestroy() {
        showToast("Service is being destroyed")
        super.onDestroy()
    }

    override fun onBind(intent: Intent?): IBinder? {
        return null
    }

    fun showToast(message: String) {
        Toast.makeText(this, message, Toast.LENGTH_SHORT).show()
    }
}

Activity Class (ServiceActivity.kt):

class ServiceActivity : AppCompatActivity() {

    private lateinit var binding: Activity2serviceBinding
    private lateinit var backgroundIntent: Intent

    @RequiresApi(Build.VERSION_CODES.O)
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = Activity2serviceBinding.inflate(layoutInflater)
        setContentView(binding.root)

        // Create an intent to start BackgroundService
        backgroundIntent = Intent(this, BackgroundService::class.java)

        binding.startService.setOnClickListener {     
            // Start the BackgroundService if not already running
            startService(backgroundIntent)          
        }
        binding.stopService.setOnClickListener {
            // Stop the BackgroundService 
            stopService(backgroundIntent)
        }  
    }

    override fun onDestroy() {
        // Stop the BackgroundService (prevent memory leaks)
        stopService(backgroundIntent)
        super.onDestroy()
    }
}

Manifest File (AndroidManifest.kt):

<manifest>
<application>
...
<service android:name=".BackgroundService"/>
</application>
</manifest>

Bound Services

Bound Services allows app components like activities to bind themselves to the service. These services perform the task as long as the component is bound to it. Multiple components can bind themselves with a service at a time. To bind a service to the component bindService() method is used and components should unbind from the service when they no longer require its functionality to release resources and avoid memory leaks. Example use cases:

1. A messaging app binds to a service for message delivery and synchronization across devices.

2. A fitness tracker app binds to a service for real-time location tracking during workouts.

3. A file transfer app binds to a service for managing file uploads and downloads in the background.

Lifecycle of a Service

In Android, there are two categories of services bound services and started services and each of these has a different lifecycle.

Started Service Lifecycle

This service will start when an app component calls the startService() method. After that, the service can keep on running even if the component that started the service is destroyed. To stop a running service we can use the stopService() method or the service can stop itself using the stopSelf() method.

1. onCreate(): This method gets called when the service is first created using startService() method. It is used to perform one-time setup procedures such as initializing resources that will be used by the service.

2. onStartCommand(): This method gets called every time when the service is started using startService() method. If the service is running already, this method will be called again with a new intent. This is where you define what the service should do in response to the intent passed by startService().

3. onDestroy(): The onDestroy() method is called when the service is no longer used and is destroyed. The service is destroyed using the stopService() method which is called by the app component that was used to start the service or the service can stop itself using the stopSelf() method. This is where we should clean up all the resources that are used in the service like removing listeners, unregistering receivers etc.

You can check the Foreground Service or Background Service for examples.

Bound Service Lifecycle

1. onCreate(): This method gets called when the service is first created using startService() method or bindService() method.

2. onStartCommand(): [same as in started service]. It won't get called if bindService() is used to start the service.

3. onBind(): The onBind() method is called when a component binds to the service using the bindService() method. If the service is not running already then onCreate() will be called first then onBind() else the onBind() will be called directly. It returns an IBinder instance that is used by the component to communicate with the service. The IBinder acts as an interface for the component to call method within the service.

   What binding really means here is that a component (for example, an activity) establishes a connection with the Service class to call its methods for performing some actions or retrieving data.

4. onUnbind(): The onUnbind() method is called when the service is unbound from the component using the unBindServce() method. This is where we can clean up the resources related to binding that are no longer needed. It returns a boolean value that decides if you want to call the onRebind() method, returns true if you want to call onRebind() else return false.

5. onRebind(): The onRebind() method is called only if onUnbind() returns true. This method is used to handle new binding requests after the service has been unbound or to reinitialize the resources that have been cleaned up in the onUnbind() method.

6. onDestroy(): [same as in started service]

Here is a simple example code for a Background Service:

Service Class (BoundService.kt):

class BoundService: Service() {

    private val TAG = "BoundService"
    private val binder = LocalBinder()

    inner class LocalBinder : Binder() {
        // Return this instance of MyBoundService so clients can call public methods
        fun getService(): BoundService = this@BoundService
    }

    // Called when the service is first created.
    override fun onCreate() {
        super.onCreate()
        showToast("Service is being created")
    }

    // Called every time a component explicitly starts the service using startService()
    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        showToast("Service is starting")
        return super.onStartCommand(intent, flags, startId)
    }

    // Called when a component binds to the service using bindService()
    override fun onBind(intent: Intent?): IBinder? {
        showToast("Service is being bound")
        return binder
    }

    // Called when all components have unbound from the service
    override fun onUnbind(intent: Intent?): Boolean {
        showToast("Service is being unbound")
        return super.onUnbind(intent)
    }

    // Called when a client re-binds to the service after it had previously unbound
    override fun onRebind(intent: Intent?) {
        showToast("Service is being re-bound")
        super.onRebind(intent)
    }

    // Called when the service is no longer used and is being destroyed
    override fun onDestroy() {
        showToast("Service is being destroyed")
        super.onDestroy()
    }

    fun showToast(message: String) {
        Toast.makeText(this, message, Toast.LENGTH_SHORT).show()
    }

    fun getData(): String {
        return "Data from Bound Service"
    }
}

Activity Class (ServiceActivity.kt):

class ServiceActivity : AppCompatActivity() {

    private lateinit var binding: Activity2serviceBinding
    private lateinit var boundIntent: Intent
    // Reference to the bound service
    private var boundService: BoundService? = null 
    // Flag to track if the service is bound
    private var isBound: Boolean = false

    // ServiceConnection to manage connection with the BoundService
    private val connection = object : ServiceConnection {
        override fun onServiceConnected(className: ComponentName, service: IBinder) {
            val binder = service as BoundService.LocalBinder
            boundService = binder.getService()
            isBound = true
            Log.d(TAG, "Service Connected")
        }

        override fun onServiceDisconnected(arg0: ComponentName) {
            boundService = null
            isBound = false
            Log.d(TAG, "Service Disconnected")
        }
    }

    @RequiresApi(Build.VERSION_CODES.O)
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = Activity2serviceBinding.inflate(layoutInflater)
        setContentView(binding.root)

        // Create an intent to start BoundService
        boundIntent = Intent(this, BoundService::class.java)

        binding.startService.setOnClickListener {
            // Start the BoundService
            startService(boundIntent)
        }

        binding.stopService.setOnClickListener {
            // Stop the BoundService
            stopService(boundIntent)
        }

        binding.bindService.setOnClickListener {
            // Bind to the BoundService
            bindService(boundIntent, connection, BIND_AUTO_CREATE)
        }

        binding.unBindService.setOnClickListener {
            if (isBound) {
                // Unbind from the BoundService
                unbindService(connection)
                isBound = false
            } else
                Toast.makeText(this, "Service is not bound", Toast.LENGTH_SHORT).show()
        }

        binding.dataFromBoundService.setOnClickListener {
            if (isBound) {
                // Get data from the bound service
                val data = boundService?.getData()
                binding.textView.text = data
            } else
                Toast.makeText(this, "Service is not bound", Toast.LENGTH_SHORT).show()
        }
    }

    override fun onDestroy() {
        // Stop the BoundService (prevent memory leaks)
        stopService(boundIntent)
        super.onDestroy()
    }
}

Manifest File (AndroidManifest.xml):

<manifest>
<application>
...
<service android:name=".BoundService"/>
</application>
</manifest>

Conclusion

Services in Android let apps do tasks in the background, keeping the app responsive. There are different types of services: background services run until stopped, bound services let other parts of the app interact with them, and foreground services show notifications to keep users informed. Managing the lifecycle of services (like creating, starting, and destroying them) is important to use resources wisely and avoid issues such as memory leaks. Using threads for long-running tasks prevents the app from freezing. Understanding these concepts helps build better, smoother-running apps.

Broadcasts in Android are system-wide messages sent by the system or other apps to signal events like battery changes or incoming messages. Broadcast receivers are components that listen for these broadcasts and respond accordingly, enabling apps to react to various events dynamically.

What are Broadcasts?

Broadcasts are messaging components used to communicate between different applications and the Android system when an event of interest occurs. For example, the Android system sends a broadcast event when the system boots, when the phone is connected to a charger, or when headphones are plugged in or unplugged. Broadcasts can be sent either globally or locally, and any app that has registered to receive them can act on these broadcasts. Additionally, Android applications can send broadcasts to notify other apps or components about events, such as when new data is downloaded.

Types of Broadcasts:

• System or Implicit broadcasts that are delivered by the system.

• Custom or Explicit broadcasts that are delivered by your app.

System(Implicit) Broadcasts

System broadcasts in Android are messages sent by the Android system to inform applications about various events. They are wrapped in an Intent object whose action string identifies the event that occurred. Applications can register to receive these broadcasts either statically in the manifest file or dynamically at runtime.

For example, android.intent.action.HEADSET_PLUG, which is sent when a wired headset is connected or disconnected.

Custom(Explicit) Broadcasts

Custom broadcasts are the events that are sent by your app. Use a custom broadcast when you want your app to trigger certain behaviours or notify other apps about specific events without needing to launch an activity.

For example, if your app downloads new data from the internet, you can send a custom broadcast to inform other apps that the data is available.

When a system broadcast is sent, any broadcast receiver registered to listen for that specific event will receive it. This registration can be done either statically in the manifest file or dynamically in the code.

Different Ways to Send a Broadcast:

Normal Broadcast

The sendBroadcast() method sends broadcasts to all the registered receivers at the same time, in an undefined order.

val intent = Intent()
intent.setAction("com.example.blogs.CUSTOM_BROADCAST")
// Set the optional additional information in extra field.
intent.putExtra("message", "This is a custom broadcast")
sendBroadcast(intent)

Ordered Broadcast

The sendOrderedBroadcast() is used to send broadcasts to one receiver at a time. Let's explore it with the help of an example:

Define your Broadcast Receiver classes:

class Receiver1 : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        // Modify the received data
        var message = intent.getStringExtra("message")
        message = "$message -> Sent by Receiver1"

        val resultExtras = getResultExtras(true)
        resultExtras.putString("data", message)

        Log.d("Receiver1", "Received broadcast and modified message")
    }
}

class Receiver2 : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {

        // Read the modified data 
        val resultExtras = getResultExtras(true)
        val data = resultExtras.getString("data")

        Log.d("Receiver2", "Received broadcast with message: $data")
    }
}

Register the Broadcast receivers(will be explained later) in the Manifest file of the receiver app.

<application>
...

    <receiver android:name="com.example.blogs.Receiver1" android:priority="2">
        <intent-filter>
            <action android:name="com.example.blogs.ORDERED_BROADCAST" />
        </intent-filter>
    </receiver>

    <receiver android:name="com.example.blogs.Receiver2" android:priority="1">
        <intent-filter>
            <action android:name="com.example.blogs.ORDERED_BROADCAST" />
        </intent-filter>
    </receiver>

</application>

• The android:priority attribute that's specified in the intent filter determines the order in which the broadcast is sent.

• Receiver1: This receiver has a higher priority (2). It receives the broadcast first, modifies the message, and logs the action.

• Receiver2: This receiver has a lower priority (1). It receives the broadcast after Receiver1 and logs the modified message.

• If more than one receiver with the same priority is present, the sending order is random.

val intent = Intent("com.example.blogs.ORDERED_BROADCAST")
// set the package name of receiver app
intent.setPackage("com.example.blogs")
// Set a unique action string prefixed by your app package name.
intent.putExtra("message", "Broadcast Message.");
// Deliver the Intent.
sendOrderedBroadcast(intent, null)

In the Logcat:

Local Broadcast

The LocalBroadcastManager.sendBroadcast() method is used to send broadcasts to receivers within your app and not outside the scope of your app.

How to send a local broadcast?

• Get an instance of LocalBroadcastManager, by calling getInstance() and pass in the application context.

• Call sendBroadcast() on the instance. Pass in the intent that you want to broadcast.

 val intent = Intent("local-broadcast")
 intent.putExtra("message", "Local Broadcast Received!")
 LocalBroadcastManager.getInstance(this).sendBroadcast(intent );

Although LocalBroadcastManager is deprecated, it is still usable. However, it is recommended to use LiveData, RxJava, or Flows (if working in Kotlin) as alternatives.

What are Broadcast Receivers?

Broadcast receivers are app components that listen for broadcast events from your app, other apps, or the system itself. When an event occurs, the registered broadcast receivers are notified through an Intent.

Use broadcast receivers to respond to messages that broadcast from apps or the Android system.

To create a custom broadcast receiver extend the BroadcastReceiver class and override the onReceive() method:

//Subclass of the BroadcastReceiver class.
class CustomReceiver : BroadcastReceiver() {
    // Override the onReceive method to receive the broadcasts
    override fun onReceive(context: Context, intent: Intent) {
       //Check the Intent action and perform the required operation
       if (intent.action == "com.example.blogs.CUSTOM_BROADCAST") {
      Toast.makeText(context, "Broadcast Received!", Toast.LENGTH_SHORT).show()
     }
   }
}

We can register this broadcast either statically in the manifest file or dynamically in your Java or Kotlin code.

In this example, the CustomReceiver class is a subclass of BroadcastReceiver. If the incoming broadcast intent has the com.example.blogs.CUSTOM_BROADCAST action, the CustomReceiver class shows a toast message.

If you need to perform a long-running operation inside BroadcastReceiver, use WorkManager to schedule a job. When you schedule a task with WorkManager, the task is guaranteed to run. WorkManager chooses the appropriate way to run your task, based on such factors as the device API level and the app state.

Previously, we discussed how to send a LocalBroadcast. Now, let's explore how to register a LocalBroadcast receiver.

Broadcast Receiver registered with LocalBroadcastManager can only receive broadcasts sent with LocalBroacastManager. If the broadcast is sent with an Activity or Service sendBroacast() method, it won't be received by the LocalBroadcast Receiver.

To register a receiver for local broadcasts:

1. Get an instance of LocalBroadcastManager by calling the getInstance() method.

2. Call registerReceiver(), passing in the receiver and an IntentFilter object.

class BlogActivity : AppCompatActivity() {

   // Declare an instance of the custom broadcast receiver
   private val localReceiver = MyLocalBroadcastReceiver()
   private lateinit var binding: ActivityBlogBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        binding = ActivityBlogBinding.inflate(layoutInflater)
        setContentView(binding.root)

        // Register the local receiver with the LocalBroadcastManager to 
        // listen for "local-broadcast" intents
        LocalBroadcastManager.getInstance(this).registerReceiver(
                localReceiver,
                IntentFilter("local-broadcast")
            )

        binding.button.setOnClickListener {
           // Create a new intent with the action "local-broadcast"
            val intent = Intent("local-broadcast")
            intent.putExtra("message", "Local Broadcast Received!")
            // Send the broadcast using the LocalBroadcastManager
            LocalBroadcastManager.getInstance(this).sendBroadcast(intent)
        }
    }

    override fun onDestroy() {
        super.onDestroy()
        // Unregister the local receiver when the activity is destroyed
        // to prevent memory leaks
        unregisterReceiver(localReceiver)
    }
}

Define the receiver class:

class MyLocalBroadcastReceiver : BroadcastReceiver() {
    // Override the onReceive method to receive the broadcasts
    override fun onReceive(context: Context, intent: Intent) {
        //Check the Intent action and perform the required operation
        if (intent.action == "local-broadcast") {
            Toast.makeText(context, intent.getStringExtra("message"),
                 Toast.LENGTH_LONG).show()
        }
    }
}

Types of broadcast receivers:

• Static receivers, which you register in the Android manifest file.

• Dynamic receivers, which you register using a context.

Static Broadcast receivers

Static receivers are also called manifest-declared receivers. They can respond to system-wide events even when the app is not running. To register a static receiver, include the following attributes inside the element in your AndroidManifest.xml file:

The following code snippet shows static registration of a broadcast receiver that listens for a system broadcast Intent with the action "ACTION_POWER_CONNECTED":

<receiver
     android:name=".NotificationReceiver"
     android:exported="false">
     <intent-filter>
         <action android:name="android.intent.action.ACTION_POWER_CONNECTED" />
     </intent-filter>
</receiver>

• The receiver's name is the name of the BroadcastReceiver subclass (.NotificationReceiver).

• The receiver is not exported, meaning that no other apps can deliver broadcasts to this app.

• The intent filter checks whether incoming intents include an action named ACTION_POWER_CONNECTED, which is a system Intent action indicating that the device is connected to power.

In our receiver class, we'll send a notification when our device connects to a power source.

class NotificationReceiver: BroadcastReceiver() {
    // Override the onReceive method to receive the broadcasts
    @RequiresApi(Build.VERSION_CODES.O)
    override fun onReceive(context: Context, intent: Intent) {
        //Check the Intent action and perform the required operation
        if (intent.action == Intent.ACTION_POWER_CONNECTED) {
            val notificationManager =
                context.getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager

            // Create a notification channel
            val channel = NotificationChannel(
                "notification-channel-id",
                "notification-channel-name",
                NotificationManager.IMPORTANCE_DEFAULT
            )
            notificationManager.createNotificationChannel(channel)

            // Build the notification
            val notification =
                NotificationCompat.Builder(context, "notification-channel-id")
                    .setSmallIcon(R.mipmap.ic_launcher)
                    .setContentText("Dynamic Broadcast Received!")
                    .setContentTitle("Notification Broadcast")
                    .build()

            notificationManager.notify(1, notification)
        }
    }
}

Note: Make sure to add the push notifications permission in the manifest file to send notifications.

 <uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

Dynamic Broadcast Receivers

Dynamic receivers enable an application to register for system or app-level events at runtime instead of in the manifest file. They can only respond to events when the app is running. They are also called context-registered receivers and are registered using either an application context or an Activity context. These receivers continue to receive broadcasts as long as the context used for registration remains valid.

1. Create an IntentFilter and add the Intent actions that you want your app to listen for. You can add more than one action to the same IntentFilter object.

val intentFilter = IntentFilter()
intentFilter.addAction(Intent.ACTION_AIRPLANE_MODE_CHANGED)

2. Register the receiver by calling the registerReceiver() method on the context. Pass in the BroadcastReceiver object and the IntentFilter object.

val airplaneModeReceiver = AirplaneModeReceiver()

// Register it in the onCreate() method
this.registerReceiver(airplaneModeReceiver, intentFilter)

Define the receiver class:

class AirplaneModeReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent?) {
        if (intent?.action == Intent.ACTION_AIRPLANE_MODE_CHANGED) {
            val isAirplaneModeEnabled = Settings.Global.getInt(
                context?.contentResolver,
                Settings.Global.AIRPLANE_MODE_ON
            ) != 0
            if(isAirplaneModeEnabled) {
                Toast.makeText(context, "Airplane mode enabled", Toast.LENGTH_LONG).show()
            } else {
                Toast.makeText(context, "Airplane mode disabled", Toast.LENGTH_LONG).show()
            }
        }
    }
}

Note: When working with dynamic broadcast receivers, make sure to unregister the receivers to prevent them from registering multiple times.

// In onDestroy() method
unregisterReceiver(airplaneModeReceiver)

The placement of unregisterReceiver() calls depends on the intended lifecycle of your BroadcastReceiver object:

If the receiver is only required when your activity is visible, such as for disabling a network function when the network isn't available, then register the receiver in onResume() and unregister it in onPause(). Alternatively, you can opt for the onStart()/onStop() or onCreate()/onDestroy() method pairs if they better suit your specific use case.

Conclusion

Broadcasts in Android are like messages that apps can send and receive to know about important events. For example, when your phone's battery is low, or when you start playing music on an app. These messages are received by components called broadcast receivers, which help applications react to these events. By using broadcast receivers, apps can stay updated and respond to changes in the system or user actions, making them more interactive and useful.