# android-jetpack Published articles for android-jetpack. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Simplify ViewBinding in Android with ViewBindingPropertyDelegate 2.0 DevFeed: [Simplify ViewBinding in Android with ViewBindingPropertyDelegate 2.0]() Original publisher: [Read original article]() Author: Kirill Rozov Published: 2025-02-04T13:30:45Z Content type: release Language: en Sources: [Stories by Kirill Rozov on Medium]() Topics: [Android](), [Library](), [Jetpack](), [Refactoring](), [Memory Leaks](), [recyclerview]() Tags: [android](), [android-jetpack](), [fragments](), [jetpack](), [library](), [memory-leaks](), [open-source](), [performance](), [recyclerview](), [refactoring](), [release](), [ui](), [view-binding]() ### AI overview This article announces ViewBindingPropertyDelegate 2.0, a release that refactors how the Android library manages ViewBinding lifecycles. It replaces Jetpack Lifecycle-based detection with component lifecycle callbacks for Fragments and Activities, improving the timing of reference clearing and addressing issues related to Fragment animations. The release also supports lazy ViewBinding creation and aims to prevent memory leaks. ### Source excerpt I'm excited to announce the release of ViewBindingPropertyDelegate 2.0, which introduces significant under-the-hood refactoring to enhance the library's stability and performance. In this article, I'll highlight the most important changes and explain how they improve the library's functionality. Brief Introduction ViewBindingPropertyDelegate(VBPD) is a lightweight library designed to simplify the use of Android's ViewBinding by: Managing the ViewBinding lifecycle and clearing references to prevent memory leaks. Eliminating the need to maintain nullable references to Views or ViewBindings. Creating ViewBindings lazily. The library supports usage in various components, including Activities, Fragments, ViewGroups, and RecyclerView.ViewHolders. class ProfileFragment : Fragment(R.layout.profile) { private val profileBinding: ProfileBinding by viewBinding(ProfileBinding::bind) override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) // ProfileBinding instance will be created lazily on first access profileBinding.name.text = ... } override fun onDestroyView() { super.onDestroyView() // profileBinding reference will be cleared after onDestroyView() } }Changes in 2.0Transition from Lifecycle to Component Callbacks In previous versions (1.x), VBPD relied on Jetpack's Lifecycle to detect when a View was being destroyed. This approach had a limitation: the Lifecycle callback methods could be invoked before Fragment.onDestroyView(), while the ViewBinding reference was still needed. To address this, VBPD postponed clearing the ViewBinding reference using an Android Handler after onDestroyView(), when the Fragment's View LifecycleOwner transitioned to the DESTROYED state. In version 2.0, VBPD now utilizes FragmentManager.FragmentLifecycleCallbacks to detect when a Fragment's view is destroyed. The key difference lies in the timing of these callbacks, allowing for more precise management of the ViewBinding lifecycle. // Sou ## Android Jetpack ViewModel has KMP Support! - Kevin Schildhorn DevFeed: [Android Jetpack ViewModel has KMP Support! - Kevin Schildhorn]() Original publisher: [Read original article]() Published: 2024-03-22T00:00:00Z Content type: article Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Android](), [Kotlin Multiplatform](), [Jetpack](), [Library](), [version](), [Jetpack Compose](), [Coroutines]() Tags: [android](), [android-jetpack](), [coroutines](), [ios](), [jetpack](), [jetpack-compose](), [kmp](), [kotlin-multiplatform](), [library](), [version](), [viewmodel]() ### AI overview The lifecycle-viewmodel artifact, part of Android Jetpack, adds Kotlin Multiplatform support in version 2.8.0-alpha03. ViewModel and related classes can be used from common code, with guidance on adding the dependency and handling possible duplicate-class conflicts with Jetpack Compose. ### Source excerpt This article discusses the newest version of the lifecycle-viewmodel artifact, part of the official Android Jetpack library, and how it adds support for KMP projects. ## Kotlin Multiplatform conversions in Android Jetpack libraries DevFeed: [Kotlin Multiplatform conversions in Android Jetpack libraries]() Original publisher: [Read original article]() Author: Matthew Dolan Published: 2023-05-22T22:41:11Z Content type: article Language: en Sources: [Stories by Matthew Dolan on Medium]() Topics: [Kotlin Multiplatform](), [Jetpack](), [Android](), [Testing](), [Open Source]() Tags: [android](), [android-app-development](), [android-jetpack](), [kotlin](), [kotlin-multiplatform](), [open-source](), [testing]() ### AI overview This article discusses a KotlinConf'23 talk about adding Kotlin Multiplatform support to Android Jetpack libraries. It covers compatibility challenges, annotation issues, testing choices, and the unofficial port of Google Truth called Kruth. ### Source excerpt KotlinConf'23 -- Kotlin Multiplatform Conversions at Android Jetpack Scale by Dustin Lam and James Wardhttps://medium.com/media/bd8000e7fe715e2cd79b4ed752779a84/href While Google have been busy updating Jetpack libraries with Kotlin Multiplatform support this talk by Dustin Lam and James Ward covers some of the technical challenges in delivering those while keeping compatibility. This is no easy task especially when you consider compatibility isn't just about the version of Android you are running against but also the language you are coding with. The talk highlighted some interesting issues Google faced with the JvmName annotation. One of the other parts of the talk I found particularly interesting was focussed on testing. Choosing an assertion framework is an important choice for the new Kotlin Multiplatform code. There are now a handful of multiplatform libraries to choose from, for example, Atrium, Kotest Assertions and Assert4K, however, as Googles stats show a lot of the tests within Jetpack libraries use Google Truth. 50,000+ usages of Google Truth Instead of switching to one of the other libraries they made the decision to port Truth to Kotlin Multiplatform as (unofficially) "Kruth". At the moment the code for Kruth is internal, although given Android and Jetpack is open source you can find the source code at testutils-kmp. I look forward to seeing Kruth released as an independent library, otherwise there is always the unofficial Truthish. Of course one question that often comes up is what the future holds, and as expected Google likes to remain quiet. However, it was nice to hear about the possibility of Cashapp multiplatform-paging perhaps being merged upstream back into Jetpack. It's important to note that even as an individual we can contribute to Jetpack given its open source nature. You can find my thoughts on more KotlinConf'23 talks at KotlinConf'23. Please let me know your thoughts. Join medium to read all of my articles or subscribe for e-mail updat ## AutoSize TextField in Android Jetpack Compose DevFeed: [AutoSize TextField in Android Jetpack Compose]() Original publisher: [Read original article]() Author: Ban Markovic Published: 2022-08-08T08:55:06Z Content type: tutorial Language: en Sources: [Stories by Ban Markovic on Medium]() Topics: [Jetpack Compose](), [Android](), [ui](), [XML]() Tags: [android](), [android-app-development](), [android-jetpack](), [compose-ui](), [jetpack-compose](), [kotlin](), [ui]() ### AI overview This tutorial explains how to implement an autosizing TextField in Android Jetpack Compose. It calculates the input field's available width, measures text using ParagraphIntrinsics, and decreases the font size until the text fits within the field while accounting for default horizontal padding. ### Source excerpt By introducing Jetpack Compose UI framework, Android has made huge improvement towards speeding up the process of developing Android apps. The only drawback at the moment is that the framework is still young, therefore quite a few features are lacking when compared to the previous View system (XML). One of the latest struggles I had with Jetpack Compose was the implementation of the input field that resizes its font when the text is wider than the input field. Autosizing input field In this post, I'm going to cover steps necessary for the implementation of mentioned TextField in JetpackCompose. In case you are impatient and you want to check Github repo immediately, here is the link with working example. What are we trying to accomplish here Every time our text exceeds the width of our TextField box, we must calculate the new font size to make our content fit within the boundaries of the TextField box. Solution For this specific purpose, we will leverage a few of the features that Jetpack Compose has made available. But first, let's break this work down into three smaller ones so that we can tackle them one at a time: calculate the max width of the input field, calculate the width of the text with given font size, decrease the font size until the width of the given text fits the max width of the input field. 1. Max width of the input field Since working solely with TextField won't give us the information about its width, we are going to use one of the Jetpack Compose composables called BoxWithConstraints, as a parent of our TextField. It can help us get the maxWidth info. BoxWithConstraints(modifier = modifier.fillMaxWidth()) { val textFieldDefaultHorPad = 16.dp val maxInputWidth = maxWidth - 2 * textFieldDefaultHorPad TextField(...) } Here, it's important to note that TextField contains default horizontal padding that is 16 dp on each side, that's why we are calculating our maxInputWidth by subtracting two paddings from BoxWithConstraints maxWidth. If we didn't sub ## Improving shared architecture for a Kotlin Multiplatform, Jetpack Compose and SwiftUI app DevFeed: [Improving shared architecture for a Kotlin Multiplatform, Jetpack Compose and SwiftUI app]() Original publisher: [Read original article]() Author: Marco Gomiero Published: 2022-06-26T00:00:00Z Content type: tutorial Language: en Sources: [Posts on Marco Gomiero]() Topics: [Kotlin Multiplatform](), [Jetpack Compose](), [SwiftUI](), [Kotlin](), [Mobile]() Tags: [android](), [android-jetpack](), [app](), [app-architecture](), [architecture](), [article](), [compose](), [coroutines](), [flow](), [ios](), [jetpack](), [jetpack-compose](), [kotlin](), [kotlin-coroutines](), [kotlin-multiplatform](), [mobile](), [multiplatform](), [mvvm](), [swiftui](), [viewmodel]() ### AI overview This tutorial explains how to improve a shared application architecture for Kotlin Multiplatform, Jetpack Compose, and SwiftUI. It replaces duplicated suspendable and non-suspendable methods plus platform-specific callbacks with Kotlin and Swift wrapper code that allows Swift to consume Kotlin Flow, enabling a single UseCase method that returns a Flow. ### Source excerpt A couple of years ago I started working on a pet project to manage personal finances, named MoneyFlow. This project soon became a personal playground for a Kotlin Multiplatform mobile app and in a previous article, I journaled all the steps that lead me to a satisfying (at least for that time) shared app architecture. Choosing the right architecture for a [new] Kotlin Multiplatform, Jetpack Compose and SwiftUI app ## How to reliably update widgets on Android DevFeed: [How to reliably update widgets on Android]() Original publisher: [Read original article]() Published: 2022-02-12T00:00:00Z Content type: tutorial Language: en Sources: [Arkadiusz Chmura]() Topics: [Android](), [Jetpack](), [App]() Tags: [android](), [android-jetpack](), [background](), [battery](), [implementation](), [setup](), [widget](), [workmanager]() ### AI overview This tutorial explains why Android widgets may not update reliably using android:updatePeriodMillis alone, particularly on devices whose vendors restrict background processing. It presents Android Jetpack WorkManager as a way to schedule periodic work that updates widget instances through AppWidgetManager. ### Source excerpt The default solution with android:updatePeriodMillis doesn't always work. ## Converting your Android App to Jetpack DevFeed: [Converting your Android App to Jetpack]() Original publisher: [Read original article]() Author: Mike Wolfson Published: 2021-09-08T15:44:14Z Content type: article Language: en Sources: [My Big Appetite - Mike Wolfson]() Topics: [Android](), [Jetpack](), [Library](), [architecture-components](), [Developer experience]() Tags: [android](), [android-framework](), [android-jetpack](), [androiddev](), [architecture-components](), [better](), [developer-experience](), [jetpack](), [library](), [version](), [versioning]() ### AI overview This article explains Google's transition from the Android Support Libraries to Jetpack, also known as AndroidX. It describes Jetpack's purpose, the reasons for the namespace and versioning changes, the libraries included, and the need to migrate Android projects. ### Source excerpt This Post was originally published to Medium on Nov 27, 2018 - 7 min read Converting your Android App to Jetpack Google has rebranded their support libraries to be named Jetpack (aka AndroidX). Developers will need to make changes to account for this. This article will explain what this means, and how to get started converting your project to use the new components. Jetpack to the future What is Jetpack? Android Jetpack is a set of libraries, tools and architectural guidance that is designed to make it easy to build Android apps. It is intended to provide common infrastructure code so the developer can focus on writing things that make an app unique. It is a large scope effort to improve developer experience and collect useful tools and frameworks into a cohesive unit. This quote from Alan Viverette (Android Framework team) is a good summary: "Jetpack is a larger-scoped effort to improve developer experience, but AndroidX forms the technical foundation. From a technical perspective, it's still the same libraries you'd have seen under Support Library and Architecture Components." Why? Why is Google going through all this trouble (and creating all this trouble for developers)? Create a consistent namespace (androidx.*) for the support libraries Support better semantic versioning for the artifacts (starting with 1.0.0). This enables them to be updated independently. Create a common umbrella to develop all support components under. It is important to mention -- this current version of AppCompat(v28.x) is the final release. The next versions of this code will use Jetpack exclusively. It is imperative that developers are aware, and make the switch early. This quote from Alan Viverette sums this up nicely: "There won't be a 29.0.0, so Android Q APIs will only be in AndroidX" What is in Jetpack? The answer: everything. Jetpack is a collection of many of the existing libraries we have been using forever (like AppCompat, Permissions, Notifications or Transitions) and the newer ## Navigate without crashes using Android Jetpack Navigation DevFeed: [Navigate without crashes using Android Jetpack Navigation]() Original publisher: [Read original article]() Author: Vadzimv Dev Blog Published: 2021-07-26T16:00:00Z Content type: tutorial Language: en Sources: [vadzimv Dev Blog]() Topics: [Android](), [Jetpack](), [Error Handling](), [Exception](), [App](), [Development]() Tags: [android](), [android-jetpack](), [app](), [crash](), [error-handling](), [exception](), [jetpack](), [jetpack-navigation](), [testing]() ### AI overview This tutorial explains how to use Android Jetpack Navigation safely in production. It recommends wrapper functions that handle navigation exceptions, log failures without treating them as crash reports, and use navigation actions to prevent duplicate navigation from simultaneous clicks. ### Source excerpt Do not crash an app during navigation. Navigate safely. ## Android library development - Modularization DevFeed: [Android library development - Modularization]() Original publisher: [Read original article]() Author: info@jeroenmols.com (Jeroen Mols) Published: 2020-11-04T00:00:00Z Content type: tutorial Language: en Sources: [Jeroen Mols]() Topics: [Android Library](), [Library](), [SDK](), [Development](), [Android Gradle Plugin](), [Gradle](), [Jetpack]() Tags: [android](), [android-gradle-plugin](), [android-jetpack](), [android-library](), [blogs](), [development](), [gradle](), [kotlin](), [library](), [maven](), [modularization](), [sdk]() ### AI overview This article explains modularization challenges in Android libraries and SDKs, including missing submodule dependencies and unintended exposure of submodule APIs. It presents three approaches: publishing submodules to Maven, bundling them into a fat AAR, or creating a single-module SDK. ### Source excerpt With modularization being all the hype, should you also modularize an SDK? Are fat aar files really needed? And how do you prevent internal APIs from being exposed on your public interface? ## Introduction to Jetpack DataStore and Migration from SharedPreferences DevFeed: [Introduction to Jetpack DataStore and Migration from SharedPreferences]() Original publisher: [Read original article]() Author: Shreyas Patil Published: 2020-09-03T15:40:25Z Content type: tutorial Language: en Sources: [Shreyas Patil's Blog]() Topics: [Android](), [Jetpack](), [data](), [Kotlin](), [kotlin-coroutines](), [Coroutines](), [Android Studio](), [Dark Mode](), [ui]() Tags: [android](), [android-jetpack](), [app](), [dark-mode](), [gradle](), [how-to](), [jetpack](), [kotlin](), [kotlin-coroutines](), [learn](), [others](), [storage](), [ui]() ### AI overview This introductory Android tutorial presents Jetpack DataStore as a replacement for SharedPreferences, covering its asynchronous, consistent storage model, migration support, Preference DataStore and Proto DataStore, and a dark-mode preference example. ### Source excerpt Introduction to Jetpack DataStore Part 1: Learn how to migrate from SharedPreferences to Preference DataStore for better data storage in Android. ## Migrating to Material Components for Android DevFeed: [Migrating to Material Components for Android]() Original publisher: [Read original article]() Author: Nick Rout Published: 2020-04-16T14:59:37Z Content type: tutorial Language: en Sources: [Stories by Nick Rout on Medium]() Topics: [material-components](), [migration](), [Android](), [Jetpack](), [Android Studio](), [Material Design]() Tags: [android](), [android-jetpack](), [android-studio](), [design](), [jetpack](), [material-components](), [material-design](), [material-theming](), [migration]() ### AI overview A migration guide for Android developers moving from the Design Support Library to Material Components for Android. It explains the required AndroidX and Jetpack migration, dependency and package updates, and theme changes needed to adopt Material Components features. ### Source excerpt Illustration by Molly HensleyFrom Design Support Library 👉 MDC 1.0.0 👉 MDC 1.1.0 and beyond This article is also posted on the Material Design blog. We recently announced Material Design Components (MDC) 1.1.0 -- a library update that brings Material Theming, new widgets, dark theme support and other exciting features to your Android app. MDC replaces the Design Support Library. This guide will show you how to migrate your codebase so you can make use of the new attributes, styles, and widgets. If you're on MDC 1.0.0 this also provides the necessary migration steps to 1.1.0. Be sure to check out our corresponding video guide as well! https://medium.com/media/dc50384c37815c26247f879e8c76d769/hrefA simplified theming example This guide uses a simplified app to demonstrate the migration process. It uses an AppCompat theme, widgets from the Design Support Library (including a button with a custom background), and various other elements that require migration. We'll start with an app theme which uses the traditional AppCompat template: https://medium.com/media/23a6299512d5244e61f40df7ee9513a9/hrefExample app using AppCompat and the Design Support LibraryMigrating from the Support Library to Jetpack Before you can use MDC, you need to migrate from the Support Library to Android Jetpack. Jetpack uses the new androidx.* namespace and splits the previous Support Library packages into separately maintained, semantically versioned libraries, providing feature parity as well as new libraries. MDC is built with AndroidX libraries so migration is mandatory. To migrate to AndroidX, we recommend following the official developer documentation or watching the "Migrating to AndroidX: The time is right" talk from Android Dev Summit '19. The 'Refactor > Migrate to AndroidX' tool in Android Studio will refactor your Design Support Library dependency to MDC. Note: Jetpack and MDC artifacts with version 1.0.0 are binary compatible with the Support Library 28.0.0 artifacts. If you're not on ## Let's Review: Pokedex DevFeed: [Let's Review: Pokedex]() Original publisher: [Read original article]() Author: Márton Braun Published: 2020-01-07T14:00:00Z Content type: article Language: en Sources: [zsmb.co]() Topics: [Code review](), [Android](), [Development](), [Jetpack](), [Framework](), [implementation](), [ui]() Tags: [android](), [android-development](), [android-jetpack](), [code-review](), [fragment](), [implementation](), [kotlin](), [marton-braun](), [project](), [pull-request](), [repository](), [review](), [viewmodel](), [zsmb](), [zsmb-co](), [zsmb13](), [zsmbco]() ### AI overview A code review of the Pokedex Android side project examines its project structure, code organization, formatting, imports, and use of Android Jetpack components and lifecycles. The review is presented as a learning resource for developers. ### Source excerpt In what may be the start of a new series, I code review a project that was posted on reddit recently and got very popular very quickly. Let's see what we can learn from it? ## SwiftUI's iOS 13 requirement creates adoption and fragmentation challenges DevFeed: [SwiftUI's iOS 13 requirement creates adoption and fragmentation challenges]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2019-06-13T07:00:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [iOS development](), [SwiftUI](), [iOS](), [Android](), [ui](), [Jetpack]() Tags: [android](), [android-jetpack](), [fragmentation](), [ios](), [ios-development](), [jetpack](), [swiftui](), [ui]() ### AI overview The article argues that SwiftUI's requirement for iOS 13 creates a lengthy adoption lag and limits support for older iPhones, producing short-term challenges for iOS developers. It compares this with Android's historical fragmentation and discusses Jetpack's backward-compatibility approach. ### Source excerpt I've been dipping my toes into some iOS development recently. Nothing too crazy, just pairing with some colleagues and trying to see how we can jointly improve the technical design on both platforms .1 It so happens that Apple just finished it's annual conference WWDC, so I've been following the announcements closer this timer around. In that process, I ran across a tweet (from Jeff Nadeau who's a developer working at Apple): Sort of blown away by the take that a min OS target is harmful to a new framework. It's absurdly small-minded; one or two years of adoption lag is nothing when the arc of such a system is measured in decades. To set a little more context: the system Jeff talks about here is SwiftUi, a new framework library that will truly change the way iOS developers write their UI code. The niggle here is that SwiftUI is limited to just adopters of iOS 13. This basically means: Since the adoption rate for new OS updates is about 2 years for iOS, iOS 13 (newest version) will take 2 years to roll out to most iPhones iPhones 6 and below will never be able to run apps built with SwiftUi (as iOS 13 will run on iPhone 6S and later only) I found this bizarrely familiar since this was the exact same problem Google had with Android2 for the longest time. It was frustrating for Android developers because we would come back all excited from Google I/O, only to have the winds promptly taken out of our sails after we reviewed the horrendous state of OS adoption. It would be pretty irresponsible to start using SwiftUi right now for app developers building apps today. I do want to make it clear: this is not what Jeff is saying. He's not suggesting everyone start using SwiftUi right now. The latter part of the tweet clarifies this: ... when the arc of such a system is measured in decades 2 years might just be the cost to pay for iOS developers to have an amazing framework like SwiftUi that will eventually make development cycles 4x better. Especially since a sea of change is m