DEV Community: Paul Franco

How to Track Composable Visibility in Jetpack Compose — with a custom .trackVisibility Modifier

Paul Franco — Sat, 03 May 2025 05:29:25 +0000

In Compose apps, it’s often necessary to know if a Composable is visible on screen and by how much. Whether you’re logging ad impressions, auto-playing videos, lazy-loading data, or triggering animations, visibility tracking is critical.

Jetpack Compose doesn’t expose a built-in way to detect visibility like legacy Views (ViewTreeObserver, RecyclerView.OnScrollListener). But with the power of Modifier.Node, we can create our own.

Today we’ll build and explain a trackVisibility modifier from scratch — with:

Full working code
Line-by-line explanations
Best practices and optimization tips

What the `trackVisibility` Modifier Does

This custom modifier:

Calculates how visible a Composable is (from 0.0 to 1.0)
Compares it against a threshold (default 50%)
Triggers a callback when the visibility changes significantly

Full Source Code with Explanations

Step 1: Define the visibility info structure

data class VisibilityInfo(
    val isVisible: Boolean,
    val visiblePercentage: Float,
    val bounds: Rect,
    val isAboveThreshold: Boolean
)

This class encapsulates visibility state:

isVisible: Whether any portion is visible
visiblePercentage: How much of the view is visible
bounds: The view's window bounds
isAboveThreshold: Whether it meets your visibility target

Step 2: The Modifier.Node Implementation

private class VisibilityTrackerNode(
    var thresholdPercentage: Float,
    var onVisibilityChanged: (VisibilityInfo) -> Unit,
) : Modifier.Node(), GlobalPositionAwareModifierNode {

    private var previousVisibilityPercentage: Float? = null
    private val minimumVisibilityDelta = 0.01f

    override fun onGloballyPositioned(coordinates: LayoutCoordinates) {
        val boundsInWindow = coordinates.boundsInWindow()
        val parentBounds = coordinates.parentLayoutCoordinates?.boundsInWindow()

        if (parentBounds == null || !coordinates.isAttached) {
            previousVisibilityPercentage = 0f
            return
        }

        val visibleLeft = max(boundsInWindow.left, parentBounds.left)
        val visibleRight = min(boundsInWindow.right, parentBounds.right)
        val visibleTop = max(boundsInWindow.top, parentBounds.top)
        val visibleBottom = min(boundsInWindow.bottom, parentBounds.bottom)

        val visibleWidth = max(0f, visibleRight - visibleLeft)
        val visibleHeight = max(0f, visibleBottom - visibleTop)

        val visibleArea = visibleWidth * visibleHeight
        val totalArea = (coordinates.size.width * coordinates.size.height).toFloat().takeIf { it > 0 } ?: return

        val visibilityPercentage = (visibleArea / totalArea).coerceIn(0f, 1f)

        val visibilityDifference = previousVisibilityPercentage?.let { previous ->
            abs(visibilityPercentage - previous)
        } ?: Float.MAX_VALUE

        if (visibilityDifference >= minimumVisibilityDelta) {
            onVisibilityChanged(
                VisibilityInfo(
                    isVisible = visibilityPercentage > 0f,
                    visiblePercentage = visibilityPercentage,
                    bounds = boundsInWindow,
                    isAboveThreshold = visibilityPercentage >= thresholdPercentage
                )
            )
            previousVisibilityPercentage = visibilityPercentage
        }
    }
}

Explanation:

GlobalPositionAwareModifierNode gives us access to layout bounds.
We calculate the overlap between the view and its parent to determine how much is visible.
We emit a callback if the visibility changed significantly.

Step 3: The ModifierNodeElement Glue

private class VisibilityTrackerElement(
    private val thresholdPercentage: Float,
    private val onVisibilityChanged: (VisibilityInfo) -> Unit,
) : ModifierNodeElement<VisibilityTrackerNode>() {

    override fun create() = VisibilityTrackerNode(thresholdPercentage, onVisibilityChanged)

    override fun update(node: VisibilityTrackerNode) {
        node.thresholdPercentage = thresholdPercentage
        node.onVisibilityChanged = onVisibilityChanged
    }

    override fun equals(other: Any?) = other is VisibilityTrackerElement &&
        other.thresholdPercentage == thresholdPercentage &&
        other.onVisibilityChanged == onVisibilityChanged

    override fun hashCode(): Int {
        var result = thresholdPercentage.hashCode()
        result = 31 * result + onVisibilityChanged.hashCode()
        return result
    }

    override fun InspectorInfo.inspectableProperties() {
        name = "trackVisibility"
        properties["thresholdPercentage"] = thresholdPercentage
        properties["onVisibilityChanged"] = onVisibilityChanged
    }
}

This element binds the logic to the Compose modifier chain and handles recomposition safety.

Step 4: Public Modifier Extension

fun Modifier.trackVisibility(
    thresholdPercentage: Float = 0.5f,
    onVisibilityChanged: (VisibilityInfo) -> Unit,
): Modifier = this then VisibilityTrackerElement(thresholdPercentage, onVisibilityChanged)

This is the clean, declarative API you use in Composables.

Practical Usage Example with ViewModel

Here's how you would call a ViewModel function from inside trackVisibility safely:

import androidx.compose.runtime.getValue
import androidx.compose.runtime.setValue
import androidx.compose.runtime.*

@Composable
fun ShopCardWithTracking(shopId: String, viewModel: ShopListViewModel) {
    var hasLogged by remember(shopId) { mutableStateOf(false) }

    Box(
        modifier = Modifier
            .fillMaxWidth()
            .height(250.dp)
            .trackVisibility(thresholdPercentage = 0.6f) { info ->
                if (info.isAboveThreshold && !hasLogged) {
                    hasLogged = true
                    viewModel.trackImpression(shopId)
                }
            }
    ) {
        Text("Shop ID: $shopId")
    }
}

Ensure you import:

import androidx.compose.runtime.getValue
import androidx.compose.runtime.setValue

To avoid the "property delegate must have a getValue/setValue" compiler error.

Full LazyColumn Example

@Composable
fun ShopListScreen(viewModel: ShopListViewModel = viewModel()) {
    val shops = listOf("A1", "B2", "C3", "D4")

    LazyColumn {
        items(properties) { propertyId ->
            ShopCardWithTracking(shopId, viewModel)
        }
    }
}

And a simple ViewModel:

class ShopListViewModel : ViewModel() {
    private val _loggedImpressions = mutableSetOf<String>()

    fun trackImpression(shopId: String) {
        if (_loggedImpressions.add(shopId)) {
            Log.d("Impression", "Logged impression for $shopId")
        }
    }
}

Best Practices & Optimizations

Use minimumVisibilityDelta to avoid over-triggering callbacks.
Avoid expensive logic inside onVisibilityChanged.
Guard with hasLogged to prevent duplicate triggers.
Keep ViewModel interactions lightweight.

Keep It Tight: Using Locally Scoped Helper Functions in Kotlin Use Cases

Paul Franco — Fri, 25 Apr 2025 02:57:07 +0000

In modern Android and Kotlin development, especially when following clean architecture, we aim for focused, testable, and readable use cases. One subtle yet powerful technique to help us achieve that is placing small, tightly-bound helper functions inside a function like invoke() — rather than elevating them to the class level.

Here’s how and why that matters.

A Real Example
Let’s say you have a feature that displays business hours for some sort of business like a dental clinic. You’ve got a BusinessSchedule proto model or API response and you want to display:

"Open Today: 9:00 AM - 5:00 PM" if today’s hours are valid
"Open Tomorrow: ..." if today is closed but tomorrow is open
Or the next available day like "Open Thursday:..."
Or a fallback like "Contact us for available business hours"

You might implement a use case like this:

class GetBusinessAvailabilityScheduleUseCase {

    operator fun invoke(businessSchedule: List<BusinessSchedule>): String {
        val dayNames = listOf("Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday")
        val today = LocalDate.now().dayOfWeek.value % 7
        val tomorrow = (today + 1) % 7

        fun hasValidHours(index: Int): Boolean {
            val schedule = businessSchedule.getOrNull(index)
            val open = schedule?.open?.value.orEmpty()
            val close = schedule?.close?.value.orEmpty()
            return open.isNotBlank() && close.isNotBlank()
        }

        fun formatSchedule(prefix: String, index: Int): String {
            val schedule = businessSchedule[index]
            val open = schedule.open?.value.orEmpty()
            val close = schedule.close?.value.orEmpty()
            return "$prefix: $open - $close"
        }

        return when {
            hasValidHours(today) -> formatSchedule("Open Today", today)
            hasValidHours(tomorrow) -> formatSchedule("Open Tomorrow", tomorrow)
            else -> {
                for (i in 0..6) {
                    val index = (today + i + 1) % 7
                    if (hasValidHours(index)) {
                        val dayName = dayNames[index]
                        return formatSchedule("Open $dayName", index)
                    }
                }
                "Contact us for available business hours"
            }
        }
    }
}

Why Use Local Helper Functions?

1. Encapsulation
Helpers like hasValidHours() and formatSchedule() are implementation details. They don’t belong to the class's public API and aren’t useful anywhere else. Keeping them inside the invoke() keeps the rest of your class clean and focused.

2. Readability
Keeping helper logic near the place it’s used creates a narrative flow in your code. You don’t have to scroll around to find where something like hasValidHours() is defined — it’s right there, scoped to the logic it supports.

3. Refactor Safety
When helpers are class-level, other developers might start reusing them in unintended ways. If they’re scoped locally, the compiler ensures they only exist where they're needed, which makes future refactors less risky.

4. Access to Local Variables
These functions can "close over" values like today, dayNames, or businessSchedule, without requiring additional parameters. This reduces parameter clutter and makes your logic more concise.

When to Extract Them

There’s a tipping point. If a helper:

Is reused across multiple functions
Becomes complex enough to deserve testing
Or starts to feel like a domain concept on its own

... then it’s time to extract it to a private method or even a standalone utility.

For example, hasValidHours() could be extracted to a shared ScheduleUtils if it's reused elsewhere.

Final Thoughts

This pattern — defining small, single-use helpers inside invoke() — is a clean, idiomatic way to write Kotlin use cases. It encourages encapsulation, local reasoning, and less API pollution, making your code more maintainable and testable over time.

It’s a small trick — but when applied consistently, it has a big payoff.

TL;DR

Define helper functions inside invoke() if they’re only used there.
It improves readability, encapsulation, and refactorability.
Extract them only if they become reusable or complex.

Securing and Injecting Google Maps API Key in an Android App

Paul Franco — Mon, 03 Mar 2025 21:36:20 +0000

When developing an Android application, securely managing sensitive API keys such as the Google Maps API Key is crucial. Hardcoding API keys in strings.xml or source code poses a security risk, as they can be easily extracted from decompiled APKs. Instead, we use Gradle properties and resValue to inject the API key dynamically into the app while keeping it out of the source code repository.

In this blog post, we'll walk through how to securely manage and inject the Google Maps API key in an Android project, ensuring that it remains safe while still being accessible where needed.

Step 1: Store the API Key in secrets.properties

First, we store the API key in a local properties file that is not included in version control (Git) to prevent it from being leaked.

Create a file named secrets.properties in the root directory of your project.

Add the following line (replace with your actual key):

GOOGLE_MAP_API_KEY=your_actual_google_maps_api_key

Add secrets.properties to .gitignore to ensure it is not committed to the repository:

secrets.properties

Now, the API key is stored securely and will not be pushed to GitHub or shared in version control.

Step 2: Load the API Key in `build.gradle.kts`

Since we need to use this API key within Gradle, we need to load it from secrets.properties.

Modify the build.gradle.kts file and add the following snippet before the android block:

val localProperties = Properties()
val localPropertiesFile = File(rootDir, "secrets.properties")
if (localPropertiesFile.exists() && localPropertiesFile.isFile) {
    localPropertiesFile.inputStream().use {
        localProperties.load(it)
    }
}

This snippet:

Loads the secrets.properties file at runtime.

Extracts the GOOGLE_MAP_API_KEY value.

Ensures the file exists before trying to read it, preventing crashes.

This must be placed at the top of build.gradle.kts so that the properties are available before any build configurations.

Step 3: Inject the API Key into `res/values/strings.xml` Using `resValue`

Instead of manually adding the API key to strings.xml, we use resValue in Gradle to inject it dynamically.

Modify your build.gradle.kts inside the android block:

android {
    buildTypes {
        getByName("debug") {
            val googleMapsApiKey = localProperties.getProperty("GOOGLE_MAP_API_KEY") ?: ""
            resValue("string", "google_maps_key", googleMapsApiKey)
        }

        getByName("release") {
            val googleMapsApiKey = localProperties.getProperty("GOOGLE_MAP_API_KEY") ?: ""
            resValue("string", "google_maps_key", googleMapsApiKey)
        }
    }
}

How resValue Works

It injects the API key into the compiled res/values/strings.xml at build time.

The key never appears in source code or XML files, reducing security risks.

The generated key can be accessed using @string/google_maps_key

Step 4: Use the API Key in `AndroidManifest.xml`

Since resValue makes google_maps_key available as a string resource, you can now reference it in AndroidManifest.xml:

<meta-data
    android:name="com.google.android.geo.API_KEY"
    android:value="@string/google_maps_key" />

This ensures that Google Maps SDK can access the API key without hardcoding it anywhere in your project.

Step 5: Access the API Key in Kotlin Code (If Needed)

If you need to use the API key in Kotlin (for example, to initialize Google Maps dynamically), you can retrieve it as follows:

val apiKey = context.getString(R.string.google_maps_key)

This allows you to access the API key programmatically while keeping it securely stored.

Android: Determine how many users are using DarkMode

Paul Franco — Wed, 17 Jul 2024 08:58:35 +0000

On Android, determining how many users are using dark mode can be achieved through a few methods, but it generally involves collecting analytics data from your app. Here's how you can approach it:

Using Firebase Analytics
Firebase Analytics is a powerful tool for collecting user data and behavior analytics. You can log a custom event to track the theme mode preference of your users.

Add Firebase to your Android project: Follow the Firebase setup instructions to add Firebase to your project.
Log the dark mode preference: Create a function to log an event whenever the user changes the theme or when the app starts. Here's an example of how you can do it:

import com.google.firebase.analytics.FirebaseAnalytics
import com.google.firebase.analytics.ktx.analytics
import com.google.firebase.ktx.Firebase

fun logThemeMode(isDarkMode: Boolean) {
    val firebaseAnalytics = Firebase.analytics
    val themeMode = if (isDarkMode) "dark" else "light"
    val bundle = Bundle().apply {
        putString("theme_mode", themeMode)
    }
    firebaseAnalytics.logEvent("user_theme_mode", bundle)
}

Detect the current theme mode: You can detect whether the user is in dark mode using the following code:

val isDarkMode = when (resources.configuration.uiMode and Configuration.UI_MODE_NIGHT_MASK) {
    Configuration.UI_MODE_NIGHT_YES -> true
    Configuration.UI_MODE_NIGHT_NO -> false
    else -> false
}
logThemeMode(isDarkMode)

View analytics in Firebase: After integrating the above code, you can view the analytics data in the Firebase console under the Events section. Look for the user_theme_mode event to see the theme mode distribution among your users.

Using Custom Analytics
If you are using a custom analytics solution, you can follow a similar approach by sending a custom event or property to your analytics server whenever the theme changes or the app starts.

Detect the current theme mode: Use the same method as above to detect whether the user is using dark mode.
Send the theme mode data: Send this information to your analytics server. The implementation will depend on your custom analytics setup.

Checking System Default
You can also check the default system settings for dark mode, though this will only give you an idea of the preferred mode and not actual usage:

val nightModeFlags = context.resources.configuration.uiMode and Configuration.UI_MODE_NIGHT_MASK
val isDarkMode = when (nightModeFlags) {
    Configuration.UI_MODE_NIGHT_YES -> true
    Configuration.UI_MODE_NIGHT_NO -> false
    else -> false
}

Combining these methods with your analytics setup will provide you with insights into how many users are using dark mode on their Android devices.

Android Jetpack: Navigation Architecture Component

Paul Franco — Sun, 27 Sep 2020 22:03:11 +0000

If you have been developing Android applications for some time you know that providing proper navigation between Activities and Fragments can be a time extensive and complex task. The recently released Android Jetpack Navigation Architecture Component makes this task much easier by providing many building tools needed to handle in-app navigation while also helping us visualize our app’s navigation flow.

The Navigation Component consists of three key building blocks:

Navigation Graph which is an XML resource that contains all navigation-related information like all off our app’s destinations or fragments and all of the possible paths our users could navigate through our app.
NavHostFragment which is special widget we can add to our app layout that will Host all of the destinations or fragments from our navigation graph.
NavController is a Kotlin object that keeps track of the user’s current position within the navigation graph and orchestrates the exchange of destination content in the NavHostFragment as our users move through the destinations in our navigation graph.

In order to illustrate how easy it is to use the Navigation Architecture Component, lets go ahead and create a new project in Android Studio.

I will name this project NavDemo.

Next we need to declare the Navigation Component’s dependencies to our app level build.gradle file. The current dependencies can be found at https://developer.android.com/jetpack/androidx/releases/navigation

If we want to be able to pass data between fragments or destinations in our app we need to use Safe Args. In order to use Safe Args in our project we need to declare some dependencies to our project level build.gladle file.

We also need to add a plugin to our app level build.gradle file.

For this project we are also going to use the Android Jetpack Data Binding Library. We don’t need to use Data Binding in this project and the Navigation Component does not rely on it but is recommended as we begin to work on larger real-world projects. In order to enable data binding we just need to set dataBinding to true in the buildFeatures block of the app level build.gradle file.

In order to properly use data binding in our project we need to set layout tags to be the outermost tags in our layout xml files.

Now let create a Data Binding object in the MainActivity.

Now that we have set up our project to use Data Binding and Navigation we can move forward and begin building our Navigation Graph.

First, we will create a file that will contain our navigation graph. To create this file you can right click on your app folder which will prompt a menu to pop up. Select New. Then select Android Resource File.

A new window will pop up. Choose Navigation as the Resource Type. I will name this file nav_graph.

Now that the file has been created you can see that android created a new folder named navigation in within the res folder. Inside the navigation folder we will find our nav_graph file.

To host the navigation graph we need a NavHostFragment. The navigation graph connects to the other parts of the app through the NaVHostFragment. If we switch to the Design View we will see a notification that says “No NavHostFragments found”.

In order to add a NavHostFragment we nee to open our activity_main.xml file and remove the TextView.

We then want to switch to Design Mode and seach for NavHostFragment.

We can select the NavHostFragment and drag it into the layout prompting a pop-up to appear.

In this pop-up we can see that we can select the nav_graph we created earlier. Select the nav_graph option and press the OK button. Then press of the Infer Constraints button. Now we have set the activity_main as NavHostFragment.

If we go back to our navigation graph we can see that the activity_main is set as the NavHostFragment.

Next we have to create our Navigation Destinations. I will create a destination by clicking on the green plus button.

A pop-up will appear with different types of fragments available. I will choose Fragment (Blank).

I will name this fragment HomeFragment. After clicking the Finish button, the fragment will appear in my navigation graph.

Our layout folder now has an additional file for the homeFragment. Let’s open this file and make some small changes to the design.

I will simply remove the TextView, add an EditText and a Button. Since we are using data binding we also need to add layout tags as the outer most tags in the xml and set up our binding object in our HomeFragment Class.

Now that we have set up our Home Fragment we need to add additional destinations to our Navigation Graph by repeating the process. I will name this additional destination SecondFragment. However, this fragment will only contain a single TextView.

If you look at our Navigation Graph you will see that we now have two desinations, the homeFragment and the secondFragment.

If you run this app you will see the homeFragment is displayed, but it you click on the Submit button nothing will happen. This is because we have not set any Navigation Actions.

To add a Navigation action from the homeFragment to the secondFragment all we have to do is click on the circular icon on the right side of the homeFragment and drag the line that appears into the secondFragment. If successful an arrow will appear that points from the homeFragment to the secondFragment.

The same can be done if you want to create a Navigation Action from the secondFragment to the homeFragment. Android Studio automatically gives the navigation actions an id but you can change the id if you want. The id can be found in the attributes inspector.

If you switch to the Text Mode in the navigation graph you will see that our navigation graph contains two fragments, the homeFragment and the secondFragment. The startDestination in our navigation is set to homeFragment. The homeFragment contains an action with a destination of secondFragment.

Now we can open our HomeFragment file and set an onClickListener on our submitButton. Within this block we need to find the Navigation Controller and Navigate to our destination using the Navigation action id : action_homeFragment_toSecondFragment.

If we run out app and press the submit button you will see that our users can now move from the homeFragment to the secondFragment. However, if you type something in the EditText and then press the submit button, you will still move from one screen to the next but the information you typed in the EditText does not get transferred to the second screen. To accomplish this we need to get the user input as a bundle and set this bundle as the second argument of the navigate function.

It is important to note that the best practice of passing data between destination is using a ViewModels but for this tutorial we will use a bundle as it is the Android Navigation Component allows us to use bundles to pass data.

In our secondFragment we need to receive the data from the arguments. Then we can display the data in our TextView.

If we run out app you will see that if you type something in the EditText and press the submit button the app will navigate to the secondFragment and display the information in the TextView.

This was a simple example on how to use the Android Jetpack Navigation Component. There is much more you can do with it like set animations as you move from one destination to another and so much more. If you want to learn more about the Navigation Component I invite you to visit Android’s official documentation here: https://developer.android.com/guide/navigation/navigation-getting-started

Kotlin - "Lazy" initialization

Paul Franco — Fri, 18 Sep 2020 12:05:59 +0000

One of the most interesting features of the Kotlin syntax is Lazy initialization but it is also a concept that can be a little tricky to understand. The concept of Lazy initialization was designed to prevent the unnecessary initialization of objects. Lets imagine that you have a are running a program and you want to print out a string. That’s pretty easy to do right?

But what if getting this string was from an expensive operation? Well this is where we can use Lazy initialization.

If we run this it looks very similar but as we dig further something very interesting begins to happen. In order to illustrate this we will print the name multiple times and also add another print statement withing the lazy block.

Once we run this code we can see that “processing” was printed once while the name was printed multiple times. Why is this? Well, the reason is that when the first println(name) function was called, Kotlin evaluated, executed the code in the Lazy block and saved the computed value. This computed value was then returned each subsequent time without having to evaluate and execute the code in the lazy block again.

Now, let imagine that we are performing some sort of network call or long running operation. To simulate this we will add a sleep function in our code.

As you can see, “processing…” was printed to the console and a few seconds later “Paul” was printed out three times almost simultaneously. This is because when the first println(name) function was called, the lazy block was evaluated and executed, the computed value was then saved by Kotlin and when the second and third println(name) function was called the computed value of the name variable only needed to be returned. With Lazy initialization, the value gets computed ONLY upon first access.

Kotlin - Understanding the "open" keyword

Paul Franco — Wed, 16 Sep 2020 01:37:23 +0000

Inheritance is the cornerstone of Object-Oriented Programming . OOP is the process of acquiring or using the properties and characteristics of one class by another.

In Kotlin, the classes, functions, and variables are final by default meaning that they cannot be inherited from by any other class. In order to make a class inheritable to the other classes, you must mark it with the open keyword otherwise you will get an error saying “type is final so can’t be inherited”.

As seen in the image above. RaceCar inherits from Vehicle but no other class can inherit from RaceCar because the RaceCar class is not marked with the open keyword. In the RaceCar class we are able to override the driveFast() function because it is marked with the open keyword inside the parent class Vehicle.

Android Jetpack: DataBinding Library

Paul Franco — Fri, 04 Sep 2020 15:57:21 +0000

Android Jetpack was introduced in 2018 by Google in order to help developers accelerate android development. Jetpack is a set of components, tools, libraries, and architectural guidance that makes it quick and easy to build great Android applications. One of these libraries is Data Binding.

The Data Binding Library is a support library that allows developers to bind UI elements in the layout to data sources in the application using a declarative format rather than doing so programmatically. Layouts are often defined in activities with code that calls UI framework methods. For example, the code below calls the findViewById() function to find a TextView and bind it to the messageView variable and the EditText to the nameText variable.

Every time we use the findViewById() function to obtain references to views, the Android system has to go through the View hierarchy and find it at runtime. In a large application, this could be many layouts and hundreds of views. Currently, most of the Android phones in the market have a refresh frequency of at least 60 hertz meaning that the screen refreshes at least 60 times per second or approximately every 16 milliseconds. Some phones in the market have higher refresh frequencies giving the Android system even less time to recreate the views. Therefore, having to go through the view hierarchy, again and again, is not a great idea because it reduces the performance of large Android applications.

Data Binding creates a binding object that contains a reference to each view of a layout sparing the Android system from having to go through the view hierarchy, again and again, to find a reference to a view at runtime. Data Binding not only improves the performance of the app but eliminates the use of the findViewById() function making code easier to read and maintain.

The first thing we need to do to implement Data Binding in our Android application is to enable dataBinding in the buildFeatures block of the apps build.gradle file.

The next step is to generate a binding class for the XML layout. To do this we have to wrap the XML layout with tags.

We then have to move the xmlns lines from the constraint layout into the opening tag.

The Data Binding library will take the name of the layout, in this case, activity_main, and will create a Data Binding object with a similar name like ActivityMainBinding.

In our MainActivity file, we currently have a Button that uses the findViewById() function. We then set an onClickListener that calls the displayGreeting() function.

In the displayGreeting() function we declare and initialize a variable named messageView of type TextView and we use the findViewById() to find the view reference. We do the same for variable nameText of type EditText. We then change the text of the messageView and append the text that the user enters in the nameText EditText of the application.

To use the Data Binding object and simplify our code we have to declare a reference variable for it in our MainActivity.

Since we are now using Data Binding we no longer need the setContentView() function in our onCreate() method.

We will instead initialize the Data Binding object with DataBindingUti.setContentView().

The Data Binding object contains properties for each of the views in the activity_main layout. It used id names for each of the views and created its own reference by getting rid of the underscore and camel casing the name. For example: The Button id in the XML layout is submit_button and the Data Binding object created its own reference with the name submitButton.

We no longer need the findViewById() functions and we can remove them.

We can now use the Binding object. Instead of button.setOnClickListerner. we will use binding.submitButton.setOnClickListener.

We can now do the same for the other view references in the displayGreeting() function.

As you can see, Data Binding allows us to write readable and maintainable code while improving the applications performance.

Android Jetpack: 2Way DataBinding

Paul Franco — Tue, 01 Sep 2020 15:12:03 +0000

With the introduction of Android Jetpack’s ViewModel and Data Binding we are able to reduce the number of lines of code in out apps significantly. In this article we will walk through a simple application that implements 2-way Data Binding.

With 2-Way Data Binding when the value of the object changes, the User Interface changes and when the UI changes, the value of the object changes.

Lets begin by starting a new Project in Android Studio. Select Empty Activity as the project template.

I’ll be naming the project TwoWayDemo.

The next step is to enable Data Binding in the buildFeatures block, add the dependencies for ViewModel and LiveData in the dependencies block, and apply the kotlin-kapt plugin in the app’s build.gradle file. A list of updated dependencies for Lifecycle-aware components can be found here: https://developer.android.com/jetpack/androidx/releases/lifecycle

Next we will create a ViewModel Class called MainActivityViewModel which for now will only hold a single MutableLiveData of type String. MutableLiveData is Read/Write while LiveData is ReadOnly. We will initialize a variable of fullName with the initial value of “John Doe”.

In order to utilize data binding, we need to add Layout Tags as the outermost tags in our activity_main.xml file.

Now, we need to add Data Tags and define a reference variable for the MainActivityViewModel Class.

We can now bind the value of the fullname MutableLiveData to the TextView.

To complete our initial set up we need to define our data binding object in our MainActivity and replace the setContentView with our binding object.

Now we need to define a reference variable for our ViewModel.

We now need to assign this viewModel Object to the viewModel object we defined in out activity_main layout file.

Finally, since we are using LiveData we have to set MainActivity as the LifeCycle owner.

If we run our app, we should be able to see a TextView with the fullname value we defined earlier in our MainActivityViewModel class.

This is one-way data binding. We bound a view to a ViewModel Object. The bound views are displaying the values of the properties of the ViewModel object. Now that we have implemented one-way data binding, lets make a few changes to illustrate 2-way data binding.

Above the TextView, lets add an EditText so that when we type something on the EditText it will be immediately displayed in the TextView.

Now that we have bound the EditText to viewModel.fullname, we can see that both the EditText and the TextView are displaying “John Doe”.

But if we try to change the EditText to Robert Smith, nothing happens to the EditText.

This is because our app is still only implementing one-way data binding. In order to fully implement 2-way data binding we have to make a small change in our activity_main layout out file. In our EditText we have to add a = sign in between the @ and { of our text property.

We also have to annotate our fullname variable in out MainActivityViewModel with the Bindable annotation.

The last step is to extend Observable and implement its methods.

When you run the app you will see that as you type something in the EditText the TextView will automatically display whatever you wrote. This was a simple example of how to implement 2-way Data Binding with ViewModel and LiveData.