# fragments Published articles for fragments. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Apollo Client 4.1 Adds @stream Support and GraphQL Incremental Delivery Improvements DevFeed: [Apollo Client 4.1 Adds @stream Support and GraphQL Incremental Delivery Improvements]() Original publisher: [Read original article]() Author: Jerel Miller Published: 2026-01-21T12:36:16Z Content type: release Language: en Sources: [Apollo Blog]() Topics: [apollo-client](), [GraphQL](), [client]() Tags: [announcement](), [apollo-client](), [cache](), [compatibility](), [fragments](), [graphql](), [incremental](), [performance](), [release]() ### AI overview Apollo Client 4.1 adds full @stream directive support, compatibility with the latest GraphQL incremental delivery specification, and APIs for watching multiple fragments. The release also includes cache fixes, deduplication improvements, and other updates. ### Source excerpt Apollo Client 4.1 introduces full @stream directive support, compatibility with the latest GraphQL incremental delivery spec, and powerful new APIs for working with fragments. ## Send RecyclerView's scroll events to a compose parent DevFeed: [Send RecyclerView's scroll events to a compose parent]() Original publisher: [Read original article]() Author: Leonidas Partsas Published: 2025-08-10T06:58:04Z Content type: tutorial Language: en Sources: [le0nidas]() Topics: [Compose](), [recyclerview](), [screen](), [App]() Tags: [android](), [app](), [compose](), [enter-always-behavior](), [featured](), [fragment](), [fragments](), [jetpack-compose](), [kotlin](), [nested-scroll](), [recyclerview](), [screen](), [top-app-bar]() ### AI overview This tutorial explains how to send RecyclerView scroll events to a Jetpack Compose parent during a gradual migration from fragment-based Android screens. It describes connecting Compose nested-scroll behavior to a RecyclerView using a NestedScrollDispatcher so a Compose top bar can respond to scrolling. ### Source excerpt We have an app that relies heavily on fragments. Every screen is an activity that hosts a fragment that hosts a recycler view: We want to start migrating the screens to compose by keeping the screen's content and placing it in a compose environment. This means that our activities will call setContent { } instead ... Continue reading Send RecyclerView's scroll events to a compose parent -> ## Juniper MX Jumbo Frames Can Cause Fragmentation on the PFE-RE Ethernet Link DevFeed: [Juniper MX Jumbo Frames Can Cause Fragmentation on the PFE-RE Ethernet Link]() Original publisher: [Read original article]() Published: 2025-06-10T05:41:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Ethernet](), [networking](), [Routing (disambiguation)]() Tags: [blog](), [blog-post](), [ethernet](), [fragmentation](), [fragments](), [queue](), [routing](), [worth-reading]() ### AI overview The article explains that the Ethernet link between the Packet Forwarding Engine and Routing Engine in Juniper MX has a fixed 1500-byte MTU. Jumbo frames can therefore be fragmented, and dropped fragments may remain in the reassembly queue when control-plane policing intervenes. ### Source excerpt Did you know that there's an Ethernet link between the Packet Forwarding Engine (PFE - data plane) and Routing Engine (RE - control plane) in every Juniper MX? That's why you have to run two VMs to emulate it (sometimes conveniently packed into one larger VM, proving RFC 1925 rule 6a). That Ethernet link happens to have the MTU fixed at 1500 bytes. Guess what happens in the world where everyone uses jumbo frames? Did you say fragmentation? Bingo! And what do you think happens when one of those fragments gets dropped due to control-plane policing, and the rest of them are stuck in the reassembly queue? You'll find the gory details in a lengthy blog post by Nitzan Tzelniker. ## 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 ## How a transitive dependency caused unexpected Android behavior DevFeed: [How a transitive dependency caused unexpected Android behavior]() Original publisher: [Read original article]() Author: Marco Gomiero Published: 2025-01-14T00:00:00Z Content type: opinion Language: en Sources: [Posts on Marco Gomiero]() Topics: [Android](), [Library](), [issue tracker](), [navigation]() Tags: [android](), [bugs](), [debugging](), [dependencies](), [fragments](), [issue-tracker](), [libraries]() ### AI overview The author recounts debugging a crash affecting some Android users and tracing unexpected behavior to a change introduced by an external library. The article advises checking library changes and transitive dependencies during updates. ### Source excerpt This article is just a short "rant" and a "therapy session" to remind and warn my future self. I was recently debugging a weird crash affecting some users. The issue was related to navigation, fragments, and backstacks. After weeks spent trying to reproduce it, reading online reports, and cross-referencing previous libraries and SDK updates, I finally had an illuminating moment after reading about a similar behavior in the Google Issue Tracker. It made me wonder: Could something have changed in the Android Manifest? ## More resilient code with data masking in Apollo Client 3.12 DevFeed: [More resilient code with data masking in Apollo Client 3.12]() Original publisher: [Read original article]() Author: Jerel Miller Published: 2024-12-10T09:47:59Z Content type: release Language: en Sources: [Apollo Blog]() Topics: [apollo-client](), [GraphQL](), [React](), [data]() Tags: [apollo-client](), [fragments](), [graphql](), [react](), [release]() ### AI overview Apollo Client 3.12 introduces data masking, using GraphQL fragments to expose only the fields requested by each component. The article explains how this reduces implicit dependencies between components and describes colocated fragments, the useFragment hook, and enabling data masking. ### Source excerpt We are excited to announce the release of Apollo Client 3.12, which primarily focuses on data masking. When building complex applications today, Apollo Client users are leveraging GraphQL fragments to make their applications more maintainable. Data masking leverages fragments to help you write more resilient and performant code. What is data masking? Data masking enforces that only the fields requested by a component in a query or fragment are available to it. ## Optimizing Data Fetching with Apollo Client: Leveraging useFragment and Colocated Fragments DevFeed: [Optimizing Data Fetching with Apollo Client: Leveraging useFragment and Colocated Fragments]() Original publisher: [Read original article]() Author: Tyler Goelz Published: 2024-05-10T10:50:08Z Content type: tutorial Language: en Sources: [Apollo Blog]() Topics: [apollo-client](), [client](), [React](), [Caching]() Tags: [apollo-client](), [best-practices](), [cache](), [decoupling](), [fragments](), [maintainability](), [performance](), [react]() ### AI overview This article explains how Apollo Client's useFragment hook and colocated fragments can reduce over-fetching while keeping data requirements close to the components that use them. It discusses separating responsibility for declaring data needs from accountability for fetching data, and notes that useFragment accesses fragment data from Apollo Client's normalized cache. ### Source excerpt When building complex applications today, Apollo Client users typically reach for to get data to their components. This is no surprise as this is considered a best practice by the Apollo Client documentation. However, this can cause challenges while trying to minimize over-fetching while maintaining a clear separation of concern. ## Jetpack Compose: A use case for view interop migration strategy - Jigar Brahmbhatt DevFeed: [Jetpack Compose: A use case for view interop migration strategy - Jigar Brahmbhatt]() Original publisher: [Read original article]() Published: 2023-02-08T12:00:26Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Jetpack Compose](), [migration](), [SDK](), [Android]() Tags: [android](), [compose](), [fragment](), [fragments](), [interop](), [jetpack-compose](), [layout](), [migration](), [navigation](), [redesign](), [sample](), [sdk](), [testing]() ### AI overview This article describes using Jetpack Compose with existing Android views and fragments during a sample app redesign for an SDK. It explains a Fragments-in-Compose approach, Compose navigation, SharedPreferences reuse, and adjustments needed for UI testing. ### Source excerpt We had an opportunity to redesign the sample app for an SDK we're developing, using Jetpack Compose as part of our interop migration strategy. ## ViewLifecycleLazy and other ways to avoid View memory leaks in Android Fragments DevFeed: [ViewLifecycleLazy and other ways to avoid View memory leaks in Android Fragments]() Original publisher: [Read original article]() Author: Christophe Beyls Published: 2022-09-28T06:12:25Z Content type: tutorial Language: en Sources: [Stories by Christophe Beyls on Medium]() Topics: [Android](), [Memory Leaks](), [Kotlin]() Tags: [android](), [android-app-development](), [androiddev](), [architecture](), [architecture-components](), [fragments](), [kotlin](), [lifecycle](), [memory](), [memory-leak](), [memory-leaks](), [view-binding]() ### AI overview This article presents ViewLifecycleLazy, a Kotlin delegated property for Android Fragments that lazily initializes values tied to the current Fragment view lifecycle and clears them when the view hierarchy reaches the DESTROYED state. It explains how this approach helps prevent view-related memory leaks and compares it with AutoClearedValue and manual clearing in onDestroyView(). ### Source excerpt Yet another take on AutoClearedValueAre your Fragments leaking? Handling the lifecycle of Android Fragments is difficult. I already covered this topic in an article I wrote in 2017, before Google added a View-specific Lifecycle to Fragments in an attempt to solve some issues. Until now, the number one cause of memory leaks when using Fragments remains the same: not properly clearing all direct and indirect View references in onDestroyView(). Tools like Leak Canary can help detecting some of these cases. And of course, Jetpack Compose represents a big paradigm change which completely removes the need to keep View references but hey, we still have our legacy codebases to maintain! I recently came across a Medium blog post from Gabor Varadi describing an issue he encountered with a custom Kotlin delegated property he created to simplify managing view bindings in Fragments. His solution is based on a class named AutoClearedValue from the architecture components samples. The purpose of AutoClearedValue is to provide a delegate that will automatically clear a value tied to one or more Views when the Fragment View hierarchy gets destroyed, in order to avoid the aforementioned memory leaks. This is an elegant alternative to declaring a Fragment property as nullable and manually setting it to null in onDestroyView(), which can be easily forgotten. It turns out I had already come up with my own solution to do the exact same thing. And since my version is simpler and generates more optimized bytecode compared to AutoClearedValue and what Mr Varadi published, I decided to share it with you. I named this delegate ViewLifecycleLazy. Like the name implies, the delegated property value is computed lazily and the Fragment's current view lifecycle is observed in order to automatically clear the value when it moves to the DESTROYED state. https://medium.com/media/17c61e41a0f2d3e17c63e3bcf8f6376c/href This is how it's used in Fragments, for example with View Binding: class MyFragment : ## Introducing Navigation-Material DevFeed: [Introducing Navigation-Material ]() Original publisher: [Read original article]() Author: Jossi Wolf Published: 2021-08-04T19:01:30Z Content type: release Language: en Sources: [Stories by Jossi Wolf on Medium]() Topics: [Jetpack Compose](), [Compose](), [Library](), [releases]() Tags: [android](), [bottomsheet](), [compose](), [experimental](), [extension](), [fragments](), [getting-started](), [jetpack](), [jetpack-compose](), [libraries](), [library](), [material-design](), [navigation-component](), [new-feature](), [releases]() ### AI overview This article introduces Navigation Material, an Accompanist library that adds modal bottom sheet destinations to Navigation Compose. It explains the library's experimental status and provides setup steps using BottomSheetNavigator, NavController, ModalBottomSheetLayout, and the bottomSheet function. ### Source excerpt Illustration by Ana Teresa Silva from the lovely We Are Systematic. Thank youuuuuu❤✨ Navigation-Compose (well, kinda) has an exciting new feature: Support for bottom sheet destinations! Over the past (almost) 6 months, I worked on a library in collaboration with the Navigation team that offers support for Modal Bottom Sheets in Navigation Compose. Navigation with Fragments has long supported DialogFragments, and with today's release of the Navigation Material library, we are providing the same feature for composable bottom sheets with Navigation Compose. Since modal bottom sheets are still an experimental Compose-Material API, the library will be released as part of Accompanist, a collection of extension libraries for Jetpack Compose. All AndroidX libraries, Navigation and Compose included, follow strict semantic versioning as explained on the AndroidX releases page. This means that any API that isn't experimental is set in stone once a library goes to its Release Candidate (RC) phase. It would take a major version bump (i.e., a '2.0') to make breaking API changes to these stable APIs. - Ian Lake about the versioning system of AndroidX libraries Because of the versioning requirements for AndroidX libraries, Navigation Material will be offered as part of Accompanist, just like navigation-animation. Think of it as an incubator until the bottom sheet APIs are fully grown up! Enough of the talking -- let's look at how you can use it! Getting started! Navigation Material is fresh out of the oven, built off today's release of Navigation 2.4.0-alpha06! There are a few easy steps to get started: Create a BottomSheetNavigator using the rememberBottomSheetNavigator() function Add the BottomSheetNavigator to your NavController Wrap your existing NavHost in the ModalBottomSheetLayout composable provided by Navigation Material. If you don't have a NavHost yet, we'll create one! Now you're ready to define bottom sheet destinations using the new bottomSheet function! Let's go thro ## Using Kotlin Delegated Properties to Nullify Android References and Reduce Memory Leaks DevFeed: [Using Kotlin Delegated Properties to Nullify Android References and Reduce Memory Leaks]() Original publisher: [Read original article]() Author: Shreyas Patil Published: 2021-03-12T13:39:24Z Content type: tutorial Language: en Sources: [Shreyas Patil's Blog]() Topics: [Memory Leaks](), [Android](), [Kotlin](), [Jetpack]() Tags: [android](), [android-app-development](), [delegates](), [fragments](), [kotlin](), [kotlin-beginner](), [lifecycle](), [memory-leaks](), [mobile-development](), [properties]() ### AI overview This tutorial explains how Kotlin property delegates can automatically nullify references in Android components. It focuses on clearing Fragment and RecyclerView.Adapter references according to lifecycle events to reduce memory leaks and boilerplate. ### Source excerpt Learn how to use Kotlin property delegates to automatically nullify references in Android, preventing memory leaks in Fragments and Activities. ## Creating a BottomNavigation Multi-Stack using child Fragments with Simple-Stack DevFeed: [Creating a BottomNavigation Multi-Stack using child Fragments with Simple-Stack]() Original publisher: [Read original article]() Author: Gabor Varadi Published: 2021-01-25T17:03:22Z Content type: tutorial Language: en Sources: [Stories by Gabor Varadi on Medium]() Topics: [navigation](), [Jetpack](), [configuration]() Tags: [android-app-development](), [bottom-navigation](), [bottomnavigationview](), [configuration](), [fragments](), [jetpack](), [jetpack-navigation](), [navigation](), [simple-stack]() ### AI overview A tutorial on implementing bottom navigation with a separate navigation history stack for each tab using child fragments and Simple-Stack. It explains fragment attachment and detachment, lifecycle management, and keeping back stacks alive across configuration changes. ### Source excerpt It's been a recurring question, regardless of navigation framework of choice: how is it possible to create a screen with a bottom navigation view, that would host a navigation history stack per each tab? Each framework has its own unique ways. For example, Jetpack Navigation provides NavigationExtensions as a sample, there's FragNav, but how would you do it with Simple-Stack? How bottom navigation with child fragments normally works If you intend to create a BottomNavigationView that is hosted by a Fragment (and that Fragment hosts each tab as a child fragment), there's a bit of work needed to be done. To keep the fragments alive while switching between them, they must all be added. However, to make sure that the fragments are in the correct lifecycle (stopped while not showing), it makes sense to detach them (and attach the one that is meant to be showing). https://medium.com/media/1667d9733c198c3ae611fd45504f6bd0/href This example is also available here. Please note that there is nothing specific to Simple-Stack in this snippet, this is how a fragment can manage its child fragments and keep only one of them attached, while the rest are detached. In fact, the NavigationAdvancedSample works the same way. We will use this knowledge later in the article. What Simple-Stack normally does When you use Simple-Stack, you typically install a Navigator using Navigator.install(). This allows a single global Backstack instance to be accessible through the Activity's context (and thus making it available to all views within the Activity), and provides automatic lifecycle management to ensure that navigation is handled correctly. https://medium.com/media/03bde713eca4e7ef47d7dae31f6e095d/href This is important to know, because if we want to create a Backstack for each Fragment within our BottomNavigationView, we must manage the lifecycle (and keep the Backstack instance alive across configuration changes) ourselves. Thankfully, this is actually quite simple to do! After all, frag ## An update to the FragmentViewBindingDelegate: the bug we've inherited from AutoClearedValue DevFeed: [An update to the FragmentViewBindingDelegate: the bug we've inherited from AutoClearedValue]() Original publisher: [Read original article]() Author: Gabor Varadi Published: 2021-01-24T00:40:53Z Content type: article Language: en Sources: [Stories by Gabor Varadi on Medium]() Topics: [Jetpack](), [bug](), [navigation]() Tags: [android-app-development](), [android-view-binding](), [bottom-navigation](), [bug](), [fragments](), [jetpack](), [jetpack-lifecycle](), [kotlin](), [navigation]() ### AI overview The article identifies a bug in an AutoClearedValue-based FragmentViewBindingDelegate. A fragment can move directly from view creation to view destruction without becoming active, so the observer never runs and the binding is not cleared. The proposed fix is to observe the view lifecycle without using the fragment as the lifecycle owner. ### Source excerpt Jetpack Lifecycle is quite powerful. We can extract logic, and make it lifecycle-aware. In fact, this allowed us in a previous article to simplify viewbinding and make it a single line. However, I need to provide a quick heads-up: all is not as it seems. The provided gists and code snippets assumed that the code in AutoClearedValue is always correct. In this article, I'll show you how to break it. The original sourcehttps://medium.com/media/74ef2eaf8bac6a656cece1f95796034a/href The general idea behind AutoClearedValue is that a value hidden by this delegate would only be created when it is set (in our case, when it is accessed), and when viewLifecycleOwner becomes DESTROYED, it would null out the value. Makes sense, right? In order to access the view lifecycle, the code waits until Fragment.onCreate(), and registers the lifecycle observer there. Then, using the fragment as the lifecycle owner (!), it attempts to register a lifecycle observer on the view lifecycle owner. The bug hiding in plain sight The problem is that it is possible for the view lifecycle to be initialized in such a way that fragment.onStart() and therefore viewLifecycleOwner.lifecycle.addObserver never actually happens. The fragment goes directly from onViewCreated to onDestroyView. Meaning, fragment.onStart() and fragment.onStop() never happen. This means that fragment.viewLifecycleOwner.observe(fragment) will NEVER be ACTIVE, and therefore the observe block will never be called. The viewLifecycle reaches DESTROYED without it being observed. When does this happen? If a fragment is added with commitNow(), but then is detach()ed. This would mean that this could happen with FragmentPagerAdapter, as that also uses attach/detach under the hood. In my case, the bug surfaced when using the binding along with the following construct: https://medium.com/media/942d1d2a1b2b4bbdc77e4d11ef112b97/href In case of a bottom navigation view, where fragments were added but attached/detached, the view in the binding ## Simplified Android Development Using Simple-Stack DevFeed: [Simplified Android Development Using Simple-Stack]() Original publisher: [Read original article]() Author: Gabor Varadi Published: 2020-11-14T03:32:51Z Content type: tutorial Language: en Sources: [Stories by Gabor Varadi on Medium]() Topics: [navigation](), [android-development](), [Android](), [Framework](), [android-apps]() Tags: [android](), [android-app-development](), [android-apps](), [android-development](), [androiddev](), [dagger-hilt](), [fragments](), [jetpack](), [navigation](), [simple-stack]() ### AI overview An Android development article explains Simple-Stack, a navigation framework for tracking navigation state with immutable Parcelable screen identifiers. It describes the framework's origins in Flow and Mortar and its use for type-safe Fragment navigation. ### Source excerpt It's been a long time since I've wanted to write this article. Time to go at it, shall we? :) People always seem to be surprised and say, "wait, you DON'T use Jetpack ViewModel, Jetpack Navigation, and Dagger-Hilt? Then what DO you use?" This article intends to answer that. We use Simple-Stack. (If you prefer watching talks, then a talk on the same subject is available at https://www.youtube.com/watch?v=5ACcin1Z2HQ) What is Simple-Stack? Simple-Stack is a navigation framework that I've been working on since the beginning of 2017, although its roots go back to 2015 -- when we were still experimenting with multiple versions of Mortar & Flow. (The 90s kids might still remember). Following up on the original proposition by Square, "Advocating Against Android Fragments" and "Simpler Android Apps with Flow and Mortar", we've been using Single-Activity approach in our apps since 2015. Now, the history of Flow and Mortar isn't all roses. I've heard people say "we tried it and it didn't work for us". I can attest to that: we had to manage our own fork, but even with that, we hit some of its limitations over time. We needed something reliable and versioned, so we rewrote Flow's original behavior, and intended to improve upon its limitations. This rewrite is what resulted in the creation of Simple-Stack. Why Simple-Stack? Simple-Stack is based on the idea that you intend to track your navigation state as a list of immutable and Parcelable classes -- screen identifiers (which the library calls "keys"). As long as the underlying navigation implementation allows for "navigation from any state to any state", it is possible to wrap that implementation using Simple-Stack. For example, something I hear often is that "navigation with Fragments is hard". I always point out that in our code, it's been like this since 2016: backstack.goTo(new SecondScreen(detailId)); // java No explicit fragment transaction, no Bundle, no newInstance(), just calling a method. How is this possible? Isn't Fr ## Fragment Lifecycles in the Age of Jetpack DevFeed: [Fragment Lifecycles in the Age of Jetpack]() Original publisher: [Read original article]() Author: Márton Braun Published: 2020-06-18T16:00:00Z Content type: tutorial Language: en Sources: [zsmb.co]() Topics: [Jetpack](), [android-development](), [Android](), [ui](), [configuration](), [Coroutines](), [App](), [Dark Mode]() Tags: [android](), [android-development](), [code](), [configuration](), [coroutines](), [dark-mode](), [fragment](), [fragments](), [jetpack](), [kotlin](), [lifecycle](), [livedata](), [marton-braun](), [scope](), [ui](), [zsmb](), [zsmb-co](), [zsmb13](), [zsmbco]() ### AI overview This article explains Android Fragment lifecycles in the Jetpack ecosystem, covering the Fragment instance lifecycle and the nested view lifecycle. It describes recreation during state restoration, configuration changes, and process death, along with lifecycle methods, state handling, and resource management. ### Source excerpt Fragments have... Complicated lifecycles, to say the least. Let's take a look at these, and how they all fit into the world of Jetpack today, with LifecycleOwners, LiveData, and coroutines. ## Easy Android Scopes DevFeed: [Easy Android Scopes]() Original publisher: [Read original article]() Published: 2020-03-13T16:09:47Z Content type: tutorial Language: en Sources: [Blogs on Ryan Harter]() Topics: [Android](), [configuration](), [Dagger](), [multiplatform]() Tags: [android](), [android-framework](), [cache](), [configuration](), [dagger](), [deprecated](), [fragments](), [lifecycle](), [multiplatform]() ### AI overview This tutorial examines how to scope Android objects across lifecycle changes, especially when Activities and Fragments are recreated during configuration changes. It discusses retaining presenters and extending lifecycle-bound retention to objects such as Dagger Components, while noting the limitations of the deprecated onRetainNonConfigurationInstance approach. ### Source excerpt A common challenge when writing Android apps is properly scoping objects: if they outlive the lifecycle in which they're needed then we are wasting memory and they can be leaked, but if we recreate objects too soon then we could be duplicating work when we don't need to. The most common place that this manifests in is Activities and Fragments, since they're destroyed and replaced by a new instance during events like configuration changes, which can be unintuitive, at first. ## Announcing Shark: Smart Heap Analysis Reports for Kotlin DevFeed: [Announcing Shark: Smart Heap Analysis Reports for Kotlin]() Original publisher: [Read original article]() Author: P-Y Ricau Published: 2019-08-06T19:00:00Z Content type: release Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Kotlin](), [Android](), [Library](), [Graphs](), [Caching](), [Command-line interface]() Tags: [android](), [cache](), [cli](), [engineering](), [fragments](), [gc](), [graph](), [io](), [kotlin](), [library](), [memory](), [performance](), [performance-tuning]() ### AI overview The article announces Shark, a standalone Kotlin heap-analysis library that powers LeakCanary 2. It describes an indexed, on-demand approach to reading hprof heap dumps, using low and constant memory, an LRU cache, and layered components for heap analysis and Android-specific reporting. The reported benchmark parsed heap dumps and found shortest paths from GC roots to leaking objects six times faster than perflib while using ten times less memory. ### Source excerpt The heap analyzer that powers LeakCanary 2 ## Showing A Fragment For A Result DevFeed: [Showing A Fragment For A Result]() Original publisher: [Read original article]() Author: Adam McNeilly Published: 2019-01-04T00:00:00Z Content type: tutorial Language: en Sources: [Android Essence]() Topics: [Android](), [Code](), [App]() Tags: [android](), [architecture](), [callback](), [code](), [fragments](), [request]() ### AI overview This tutorial explains how to return a result between Android fragments using a target fragment. It demonstrates a small two-fragment application in which a name is entered in one fragment and displayed in the previous fragment. ### Source excerpt A number of developers preach a single activity architecture on Android, which is something I've been trying to move forward to as well. In the process, though, I ran into one tricky problem. I don't have something like startActivityResult for fragments. If you're unfamiliar, startActivityForResult is a method that allows you to launch an activity with a specific request code, and when that activity finishes, your first activity will get a callback in onActivityResult and can do stuff with it. This post is going to walk through how we can achieve that same affect using fragments. ## Back to basics: Navigation DevFeed: [Back to basics: Navigation]() Original publisher: [Read original article]() Author: Niek Haarman Published: 2018-10-25T09:12:40Z Content type: tutorial Language: en Sources: [Stories by Niek Haarman on Medium]() Topics: [navigation](), [Android](), [Mobile](), [Development]() Tags: [android](), [android-app-development](), [android-development](), [androiddev](), [development](), [flow](), [fragments](), [login](), [mobile](), [navigation](), [onboarding](), [payment](), [screen](), [shopping](), [state]() ### AI overview A fundamentals-focused guide to in-app navigation in Android applications. It explains the back stack, reusable navigation flows, conditional paths based on user state, and how navigation responsibilities are handled by Activities and Fragments. ### Source excerpt Previously I talked about the unfortunate design of the Activity class, and I went back to basics regarding screens in an application. This time, we're going back to basics regarding in-app navigation. What is meant by 'navigation'? In a typical mobile application, a user can navigate from one screen to another. Traveling through an application builds up a navigational state; in Android this is traditionally done with a back stack. Activities can start new Activities which get pushed upon a stack. When the user presses back, the top Activity gets popped off the stack, to reveal the previous Activity. You can modify how Activities are created and pushed upon the stack with several flags and attributes, which are described at length on the Understand Tasks and Back Stack page. The back stackFlows In a non-trivial application, there are often multiple 'flows' that can be defined: there might be a login flow, an onboarding flow, or a flow that takes you through a payment process. In the latter case, you might have a series of screens that start with a description of the user's shopping cart, followed by forms to enter shipping and payment information. Such flows are usually completely self contained, and can be reused when necessary. It may be possible to start a specific flow from anywhere in the app, allowing for dozens of paths through your application to exist. An example payment flow for a shopping application.Conditional navigation In your typical application, there is no strict sequence of screens that will appear in a fixed order. Depending on user input, the user can travel through different paths through your application. A dashboard screen for example can have multiple buttons that all lead the user to a different screen. Another thing to consider is that the next state of the navigation state is dependent on the some conditional state. If the user already has entered shipping and payment info a previous time, we may want to skip these forms and go straight t ## Understanding Fragment Transactions and Back Navigation DevFeed: [Understanding Fragment Transactions and Back Navigation]() Original publisher: [Read original article]() Author: info@jeroenmols.com (Jeroen Mols) Published: 2017-12-18T00:00:00Z Content type: tutorial Language: en Sources: [Jeroen Mols]() Topics: [Transactions](), [navigation](), [App](), [implementation]() Tags: [android](), [app](), [blogs](), [events](), [fragment](), [fragments](), [implementation](), [login](), [navigation](), [rewrite](), [screen](), [transactions]() ### AI overview This tutorial investigates unexpected Android Fragment behavior when login-related Fragment transactions interact with back navigation. It explains that the transaction manager saves executed transactions rather than the Fragments themselves, which can leave multiple Fragments visible after navigating back. ### Source excerpt Do Fragment transactions and back navigation have no more secrets for you? Well then you should try to solve the mystery in this post, where a Fragment (literally) came to haunt us... ## Avoiding LiveData observer leaks in the Android Fragment lifecycle DevFeed: [Avoiding LiveData observer leaks in the Android Fragment lifecycle]() Original publisher: [Read original article]() Author: Christophe Beyls Published: 2017-10-24T19:31:14Z Content type: tutorial Language: en Sources: [Stories by Christophe Beyls on Medium]() Topics: [Android](), [configuration]() Tags: [android](), [android-app-development](), [androiddev](), [architecture](), [architecture-components](), [asynchronous](), [deprecated](), [fragments](), [kotlin](), [lifecycle](), [livedata](), [memory](), [memory-leak](), [performance](), [viewmodel]() ### AI overview This article explains a pitfall when subscribing to LiveData from an Android Fragment. Detaching and re-attaching a Fragment can create a new observer while the previous observer remains active, causing duplicate execution, a memory leak, and a performance problem until the Fragment is destroyed. ### Source excerpt LiveData and the Fragment lifecycle The new Android Architecure Components are soon to be announced as stable after a few months of public testing. A lot has already been written about the basics (starting with the very good documentation) so I won't cover them here. Instead I would like to focus on important pitfalls that are mostly undocumented and rarely discussed and may cause issues in your applications if you miss them. In this first article, I'll talk about our beloved Fragments. Edit (14 may 2018): Google has finally fixed the issue in support library 28.0.0 and AndroidX 1.0.0. See solution 4 below.Edit (13 march 2020): onActivityCreated() has been officially deprecated and onViewCreated() should be used instead. The code samples in this article have been updated accordingly. The Architecture Components provide default ViewModelProvider implementations for activities and fragments. They allow you to store LiveData instances inside a ViewModel to be reused across configuration changes. The usage with activities is quite straightforward because the activity lifecyle maps well to the Lifecycle interface of the Architecture Components, but the fragment lifecycle is more complex and may cause subtle side effects if you're not being careful. The Fragment lifecycle (simplified version) Fragments can be detached and re-attached. When they are detached, their view hierarchy is destroyed and they become invisible and inactive, but their instance is not destroyed. When they are later re-attached, a new view hierarchy is created and onCreateView() and onViewCreated() are called again. For this reason, the usually recommended place to initialize Loaders and other asynchronous loading operations that will eventually interact with the view hierarchy is in onViewCreated(). We can assume this is also the best place to initialize LiveData instances by subscribing a new Observer. Most of the official Architecture Components samples also do it there. You would expect typical co ## Android Architecture: Introducing Pilot DevFeed: [Android Architecture: Introducing Pilot]() Original publisher: [Read original article]() Author: SystemDotRun Published: 2015-10-01T00:00:00Z Content type: article Language: en Sources: [SystemDotRun]() Topics: [Android](), [mvc](), [Dagger]() Tags: [android](), [android-architecture](), [architecture](), [architectures](), [controllers](), [dagger](), [fragments](), [lifecycle](), [mvc](), [mvvm](), [project](), [repo](), [view]() ### AI overview This article introduces Pilot, a work-in-progress abstract application stack for Android. It discusses managing presenter lifecycles, application flow, data scoping, and architectures based on views or a mix of fragments and views, while relating the approach to MVC, MVP, MVVM, and Dagger custom scopes. ### Source excerpt An abstract application stack for Android Motivation There are some common questions that keep popping up on the interwebs around the current collective thought on Android Architecture. Some of these questions are: What approach can I use to handle my Presenters Lifecycle? How can Presenters control the flow of an application? How can I scope data within my application? What architecture could I use to support a View only based architecture (or a mix of Fragments / Views) ? The above questions are not easy ones to address and by no means am I suggesting the below is the only solution to these common issues. I have started using a simple abstract application stack which for the kind of applications I have been developing allows a clean & structured base for them to sit on top of. This post and supporting repo is definitely a work-in-progress but Im hoping it will spark some discussion which can be fed back into the project so it's something that is useful to others also. I have been tempted to not write anything about this until I have answered all the pending questions I have myself but I feel more may be gained by publishing early and often. It is probably worth mentioning that if you are not currently using some kind of Presenter / Controller / distinct view logic abstraction in your application at present you probably will not have come across (or asked yourself) some of these questions. The same goes for Dagger (& Dagger Custom Scopes) and View only view implementations. If you have been playing with some of this stuff you may find the below more applicable. In this post I will briefly expand on the above questions and introduce the project. Preliminaries A Note on terminology Presenters are all the rage in the Android world at present. Some call them Presenters, Controllers, ViewModels, PassiveView etc and they are used as part of MVC, MVP, MVVM (with DataBinding), MVA etc and all these terms overlap and have differnt meanings and implementations depending on w ## Advocating Against Android Fragments DevFeed: [Advocating Against Android Fragments]() Original publisher: [Read original article]() Author: P-Y Ricau Published: 2014-10-08T16:07:00Z Content type: opinion Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Android](), [coding]() Tags: [alternatives](), [analysis](), [android](), [debug](), [engineering](), [fragments](), [unit-tests]() ### AI overview This opinion article explains why Square moved away from Android fragments. It argues that their complex lifecycle, difficult debugging, and close coupling of view-related code with business logic made fragments harder to maintain and test, and discusses alternatives. ### Source excerpt Alternatives for dealing with (painful) Android fragments. ## ParcelablePlease: Generating Android Parcelable Code with Annotation Processing DevFeed: [ParcelablePlease: Generating Android Parcelable Code with Annotation Processing]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2014-09-24T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Android](), [Boilerplate](), [Code](), [Java]() Tags: [android](), [annotation-processor](), [blog-post](), [code](), [fragments](), [java](), [parcelable]() ### AI overview This tutorial introduces ParcelablePlease, an Android annotation processor intended to reduce boilerplate code when implementing Parcelable. It compares the approach with Parceler and AutoParcel, explaining their generated wrapper or subclass designs and compatibility trade-offs. ### Source excerpt In my last blog post I have introduced FragmentArgs an Annotation Processor for Fragments that reduces writing boilerplate code. In this post I want to talk about a similar problem android developer face: Writing boilerplate code for Parcelable This post is part of a series of posts about useful annotation processors like FragmentArgs or AnnotatedAdapter [Next page]()