# Stories by Christophe Beyls on Medium

Stories by Christophe Beyls on Medium

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Strategies for automatically refreshing data on Android using Kotlin Flow

DevFeed: [Strategies for automatically refreshing data on Android using Kotlin Flow](<https://devfeed.tech/articles/strategies-for-automatically-refreshing-data-on-android-using-kotlin-flow-25884.md>)

Original publisher: [Read original article](<https://bladecoder.medium.com/strategies-for-automatically-refreshing-data-on-android-using-kotlin-flow-cd23ba7cfbe0?source=rss-54910f05af37------2>)

Author: Christophe Beyls

Published: 2023-10-06T17:27:03Z

Content type: tutorial

Language: en

Sources: [Stories by Christophe Beyls on Medium](<https://devfeed.tech/sources/stories-by-christophe-beyls-on-medium.md>)

Topics: [kotlin-flow](<https://devfeed.tech/topics/kotlin-flow.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Android](<https://devfeed.tech/topics/android.md>), [RxJava](<https://devfeed.tech/topics/rxjava.md>), [ui](<https://devfeed.tech/topics/ui.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [api](<https://devfeed.tech/tags/api.md>), [coroutine](<https://devfeed.tech/tags/coroutine.md>), [flow](<https://devfeed.tech/tags/flow.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-flow](<https://devfeed.tech/tags/kotlin-flow.md>), [rxjava](<https://devfeed.tech/tags/rxjava.md>), [sharedflow](<https://devfeed.tech/tags/sharedflow.md>), [ui](<https://devfeed.tech/tags/ui.md>)

### AI overview

This tutorial explains how to periodically refresh data in Android user interfaces with Kotlin Flow. It compares sequential map() processing with concurrent, cancellation-aware mapLatest() processing and discusses lifecycle-aware refreshing and caching considerations.

### Source excerpt

Making timers lifecycle-aware This is the third part of a series of articles discussing the usage of Kotlin Flow to efficiently load data in Android applications. It's a direct follow-up to part 2: "Smarter Shared Kotlin Flows", as it reuses the same concepts to cover another use case: automatic periodic refresh of the user interface. Simple periodic refresh When it's not possible to determine precisely when a data set displayed by the UI has changed, or when it changes too frequently, a common strategy is to reload the data periodically at a fixed interval while the screen is visible. One of the simplest ways to achieve this is to create a Flow from an infinite loop calling delay() between emissions: fun tickerFlow(period: Duration): Flow<Unit> = flow { while (true) { emit(Unit) // Tick delay(period) } } This is equivalent to the Observable.interval() operator in RxJava with a fixed emitted value (Unit) and an initial delay of 0. Then, transform this Flow using the map() or mapLatest() operator to perform the loading action on each "tick" of the timer and return the result: tickerFlow(REFRESH_INTERVAL) .map { repository.loadSomeData() } Note the subtle difference in behavior between the two operators: With map() the entire Flow will be executed in sequence within a single coroutine, meaning delay() will only start running after the loading operation completes. As a result, each loading operation will be delayed by the amount of time it took to perform the previous loading operation, plus the fixed interval. With mapLatest() the main coroutine will collect the upstream values of tickerFlow() while a child coroutine will be created to perform the loading operation concurrently and collect the result without suspending the main coroutine. This means that delay() will start running immediately after the previous tick and each loading operation will start precisely according to schedule. This also means that the interval must be longer than the typical loading time beca

## Kotlin JSON Benchmark on Android (2022): Moshi vs Kotlin Serialization

DevFeed: [Kotlin JSON Benchmark on Android (2022): Moshi vs Kotlin Serialization](<https://devfeed.tech/articles/kotlin-json-benchmark-on-android-2022-moshi-vs-kotlin-serialization-25881.md>)

Original publisher: [Read original article](<https://bladecoder.medium.com/kotlin-json-benchmark-on-android-2022-moshi-vs-kotlin-serialization-18436c0596c3?source=rss-54910f05af37------2>)

Author: Christophe Beyls

Published: 2022-10-14T17:31:03Z

Content type: comparison

Language: en

Sources: [Stories by Christophe Beyls on Medium](<https://devfeed.tech/sources/stories-by-christophe-beyls-on-medium.md>)

Topics: [JSON](<https://devfeed.tech/topics/json.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Benchmark](<https://devfeed.tech/topics/benchmark.md>), [Gson](<https://devfeed.tech/topics/gson.md>), [build times](<https://devfeed.tech/topics/build-times.md>), [Code generation](<https://devfeed.tech/topics/code-generation.md>), [legacy](<https://devfeed.tech/topics/legacy.md>)

Tags: [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [annotation-processor](<https://devfeed.tech/tags/annotation-processor.md>), [benchmark](<https://devfeed.tech/tags/benchmark.md>), [gson](<https://devfeed.tech/tags/gson.md>), [json](<https://devfeed.tech/tags/json.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-serialization](<https://devfeed.tech/tags/kotlin-serialization.md>), [legacy](<https://devfeed.tech/tags/legacy.md>), [moshi](<https://devfeed.tech/tags/moshi.md>), [performance](<https://devfeed.tech/tags/performance.md>), [serialization](<https://devfeed.tech/tags/serialization.md>), [vs](<https://devfeed.tech/tags/vs.md>)

### AI overview

This article sets up a 2022 Android benchmark comparing Moshi and Kotlin Serialization for JSON serialization and deserialization of Kotlin classes. It discusses Kotlin metadata compatibility, generated adapters, reflection, streaming support, Okio integration, runtime dependencies, and build-time tradeoffs. The supplied text does not include the benchmark results or identify which library is fastest.

### Source excerpt

When it comes to automatic serialization and deserialization of Kotlin classes using the JSON format, the two main libraries compatible with Kotlin metadata are currently Moshi and Kotlin Serialization. This compatibility is especially important for non-null types and default values during deserialization, where lack of proper Kotlin support could result in unexpected values occurring at runtime, such as null values in non-null fields. If you're still using legacy libraries like Gson to parse Kotlin classes, it's time to reconsider. Moshi has been supporting Kotlin classes since version 1.5.0, released in 2017. One year later, the next major release 1.6.0 added an annotation processor to generate adapters for Kotlin classes at compile time. I was quite interested in the performance gains allowed by this solution and wrote an article detailing what the generated code does. JetBrains released version 1.0.0 of Kotlin Serialization in 2020 with built-in support for JSON. This library generates adapters at compile time similarly to Moshi's annotation processor while being compatible with more platforms and formats. The lack of initial support for streaming was disappointing, so I didn't even consider using it in production until streaming support was eventually added in version 1.3.0 in 2021. The JSON engine had also been rewritten in the meantime in order to improve performance. Recently, version 1.4.0 added integration with the Okio library, the same library used by Moshi under the hood. Now that Kotlin Serialization looks full-featured and well-optimized, I thought it would be a good time to compare its performance against Moshi on Android devices with some benchmarks. Which one is the fastest? Take your bets. The contendersMoshi-Kotlin Reflection The runtime Kotlin plugin of the Moshi library. The JSON adapters are generated at runtime using reflection. The main downside of this library is that it adds a runtime dependency to the big kotlin-reflect library (currently

## 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](<https://devfeed.tech/articles/viewlifecyclelazy-and-other-ways-to-avoid-view-memory-leaks-in-android-fragments-25885.md>)

Original publisher: [Read original article](<https://bladecoder.medium.com/viewlifecyclelazy-and-other-ways-to-avoid-view-memory-leaks-in-android-fragments-4aa982e6e579?source=rss-54910f05af37------2>)

Author: Christophe Beyls

Published: 2022-09-28T06:12:25Z

Content type: tutorial

Language: en

Sources: [Stories by Christophe Beyls on Medium](<https://devfeed.tech/sources/stories-by-christophe-beyls-on-medium.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Memory Leaks](<https://devfeed.tech/topics/memory-leaks.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [architecture-components](<https://devfeed.tech/tags/architecture-components.md>), [fragments](<https://devfeed.tech/tags/fragments.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [lifecycle](<https://devfeed.tech/tags/lifecycle.md>), [memory](<https://devfeed.tech/tags/memory.md>), [memory-leak](<https://devfeed.tech/tags/memory-leak.md>), [memory-leaks](<https://devfeed.tech/tags/memory-leaks.md>), [view-binding](<https://devfeed.tech/tags/view-binding.md>)

### 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 :

## Smarter Shared Kotlin Flows

DevFeed: [Smarter Shared Kotlin Flows](<https://devfeed.tech/articles/smarter-shared-kotlin-flows-25883.md>)

Original publisher: [Read original article](<https://bladecoder.medium.com/smarter-shared-kotlin-flows-d6b75fc66754?source=rss-54910f05af37------2>)

Author: Christophe Beyls

Published: 2022-06-06T16:44:02Z

Content type: tutorial

Language: en

Sources: [Stories by Christophe Beyls on Medium](<https://devfeed.tech/sources/stories-by-christophe-beyls-on-medium.md>)

Topics: [kotlin-flow](<https://devfeed.tech/topics/kotlin-flow.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Android](<https://devfeed.tech/topics/android.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [database](<https://devfeed.tech/tags/database.md>), [efficiency](<https://devfeed.tech/tags/efficiency.md>), [flow](<https://devfeed.tech/tags/flow.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-flow](<https://devfeed.tech/tags/kotlin-flow.md>), [livedata](<https://devfeed.tech/tags/livedata.md>), [sharedflow](<https://devfeed.tech/tags/sharedflow.md>)

### AI overview

This second article in a Kotlin Flow on Android series explains how SharedFlow and StateFlow using SharingStarted.WhileSubscribed() can restart upstream work when a lifecycle becomes active again. It compares this behavior with lifecycle-aware LiveData and proposes designing a Flow operator that propagates lifecycle state upstream to avoid unnecessary network requests or database queries.

### Source excerpt

Make the lifecycle available to the upstream Flow to skip unnecessary work This is the second part of a series of articles about using Kotlin Flow on Android. In the first part, we described the main limitation of Kotlin Flow when used inside ViewModel classes: When a SharedFlow or StateFlow using the SharingStarted.WhileSubscribed() strategy is collected again after the user navigates back to an Activity or Fragment, its source upstream Flow will always restart from scratch, sometimes resulting in unnecessary work being performed when the previously cached data was still valid. val results: StateFlow<SearchResult> = queryFlow.mapLatest { query -> repository.search(query) }.stateIn( scope = viewModelScope, started = SharingStarted.WhileSubscribed(5000L), initialValue = SearchResult.EMPTY ) In the above example, repository.search() will be executed again even if the latest value of queryFlow didn't change in the meantime. This means a potential unnecessary network request or database query. LiveData doesn't suffer from this issue because its observers don't need to unsubscribe when they become inactive: LiveData is lifecycle-aware and will postpone the delivery of new results until it becomes active, while also ensuring that the same result will never be delivered to the same observer twice (even when it becomes active again). For more details I invite you to read the full article. At the end of this first part, we concluded that there was no simple and correct way to avoid performing this unnecessary work when relying only on the standard shareIn() or stateIn() operators. In this second part, we are going to solve that efficiency problem by designing a new Flow operator that will allow SharedFlows to integrate better with the lifecycle. Synchronizing with the LifecycleLiveData The core reason why LiveData deals with lifecycles better than Flow is because the lifecycle state is automatically propagated upstream through all the LiveData instances so they can all pause

## Kotlin's Flow in ViewModels: it's complicated

DevFeed: [Kotlin's Flow in ViewModels: it's complicated](<https://devfeed.tech/articles/kotlin-s-flow-in-viewmodels-it-s-complicated-25882.md>)

Original publisher: [Read original article](<https://bladecoder.medium.com/kotlins-flow-in-viewmodels-it-s-complicated-556b472e281a?source=rss-54910f05af37------2>)

Author: Christophe Beyls

Published: 2021-08-28T10:42:09Z

Content type: tutorial

Language: en

Sources: [Stories by Christophe Beyls on Medium](<https://devfeed.tech/sources/stories-by-christophe-beyls-on-medium.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [architecture-components](<https://devfeed.tech/tags/architecture-components.md>), [background-work](<https://devfeed.tech/tags/background-work.md>), [caching](<https://devfeed.tech/tags/caching.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [flow](<https://devfeed.tech/tags/flow.md>), [google](<https://devfeed.tech/tags/google.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [livedata](<https://devfeed.tech/tags/livedata.md>), [net-conf](<https://devfeed.tech/tags/net-conf.md>), [state](<https://devfeed.tech/tags/state.md>), [ui](<https://devfeed.tech/tags/ui.md>), [viewmodel](<https://devfeed.tech/tags/viewmodel.md>)

### AI overview

This article explains the challenges of loading UI data in Android applications when screen lifecycles and configuration changes are involved. It outlines goals such as caching valid data, pausing background work when screens are inactive, and avoiding unnecessary interruptions during configuration changes, then discusses ViewModel and LiveData as tools for addressing them.

### Source excerpt

LiveData is still your friend Loading UI data in Android applications can be challenging. The lifecycles of the various screens need to be taken into account, as well as configuration changes leading to the destruction and recreation of Activities. The individual screens of an app constantly toggle between interactive and hidden as the user navigates further and back in an app, switches from one app to another, or the device screen gets locked or unlocked. Each component needs to play fair and only perform active work when given the ball. Configuration changes happen on various occasions: when changing the device orientation, switching the app to multi-window mode or resizing its window size, switching to dark or light mode, changing the default locale or font sizes, and more. Goals of efficiency To achieve efficient data loading in Activities and Fragments leading to the best user experience, the following should be considered: Caching: data that has been loaded successfully and is still valid should be delivered immediately and not loaded a second time. In particular, when an existing Activity or Fragment becomes visible again, or after an Activity gets recreated on configuration change; Avoiding background work: when an Activity or Fragment becomes invisible (moves from the STARTED to the STOPPED state), any ongoing loading work should be paused or canceled in order to save resources. This is especially important for endless streams of data like location updates or periodic refreshes of any kind; No work interruption during configuration changes: this is an exception to the second goal. During configuration changes, an Activity gets replaced by a new instance of it while preserving its state, so canceling ongoing work when the old instance is destroyed to immediately restart it when the new instance is created would be counter-productive. Today: ViewModel and LiveData To help developers reach these goals with code of manageable complexity, Google released the fir

## Fixing RecyclerView nested scrolling in opposite direction

DevFeed: [Fixing RecyclerView nested scrolling in opposite direction](<https://devfeed.tech/articles/fixing-recyclerview-nested-scrolling-in-opposite-direction-25879.md>)

Original publisher: [Read original article](<https://bladecoder.medium.com/fixing-recyclerview-nested-scrolling-in-opposite-direction-f587be5c1a04?source=rss-54910f05af37------2>)

Author: Christophe Beyls

Published: 2020-03-26T15:24:30Z

Content type: tutorial

Language: en

Sources: [Stories by Christophe Beyls on Medium](<https://devfeed.tech/sources/stories-by-christophe-beyls-on-medium.md>)

Topics: [recyclerview](<https://devfeed.tech/topics/recyclerview.md>), [Android](<https://devfeed.tech/topics/android.md>), [User Interfaces](<https://devfeed.tech/topics/user-interfaces.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [layoutmanager](<https://devfeed.tech/tags/layoutmanager.md>), [nested-scroll](<https://devfeed.tech/tags/nested-scroll.md>), [recyclerview](<https://devfeed.tech/tags/recyclerview.md>)

### AI overview

This tutorial explains the nested-scrolling behavior of Android RecyclerView, focusing on layouts where horizontally scrolling lists are nested inside a vertically scrolling list. It describes why touch events can be intercepted by the parent and cause unexpected vertical scrolling, with examples such as Netflix-like video interfaces and Google Play Store layouts.

### Source excerpt

Photo by Tabl-trai under Creative Commons licenceand making ViewPager2 usable RecyclerView is one of the main building blocks of Android user interfaces today. It's more capable and flexible than its ListView predecessor but this also leads to more complexity and new problems. One core feature of RecyclerView is the externalization of its layout engine to components called LayoutManagers, which are no longer limited to vertical scrolling only. Most implementations allow to choose between horizontal and vertical scrolling and a LayoutManager could technically support both at the same time. RecyclerView also supports nested scrolling by implementing the NestedScrollingChild3 interface, which means it can cooperate with a parent view implementing NestedScrollingParent3 when both are configured to scroll in the same direction. In a nutshell, the scrolling child intercepts a scroll event and initiates a nested scroll in cooperation with the scrolling parent. Depending on its internal logic, the parent optionally consumes the scroll before or after the child, until they both reach their available scroll distance. A single scroll event may be consumed by both the parent and child with a seamless transition. For example, this mechanism is used when a RecyclerView is placed inside a CoordinatorLayout next to an app bar which will automatically slide up or collapse when a scroll gesture is initiated. Note that RecyclerView doesn't implement NestedScrollingParent3, so using a scrollable child inside a RecyclerView which scrolls in the same direction is not supported. However, Google currently provides a workaround to implement nested scrolling in a ViewPager2.The problem What about nested scrolling in the opposite direction? This should be supported out-of-the-box, since a vertical scrolling view is not supposed to intercept horizontal gestures and vice versa. In practice this works well with the legacy ViewPager which only scrolls horizontally, ignoring vertical gestures. But

## A study of the Parcelize feature from Kotlin Android Extensions

DevFeed: [A study of the Parcelize feature from Kotlin Android Extensions](<https://devfeed.tech/articles/a-study-of-the-parcelize-feature-from-kotlin-android-extensions-25876.md>)

Original publisher: [Read original article](<https://bladecoder.medium.com/a-study-of-the-parcelize-feature-from-kotlin-android-extensions-59a5adcd5909?source=rss-54910f05af37------2>)

Author: Christophe Beyls

Published: 2019-11-19T07:31:01Z

Content type: tutorial

Language: en

Sources: [Stories by Christophe Beyls on Medium](<https://devfeed.tech/sources/stories-by-christophe-beyls-on-medium.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Android](<https://devfeed.tech/topics/android.md>), [Code generation](<https://devfeed.tech/topics/code-generation.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [Android Studio](<https://devfeed.tech/topics/android-studio.md>), [jetbrains](<https://devfeed.tech/topics/jetbrains.md>), [Google](<https://devfeed.tech/topics/google.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [android-studio](<https://devfeed.tech/tags/android-studio.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [code-generation](<https://devfeed.tech/tags/code-generation.md>), [google](<https://devfeed.tech/tags/google.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [gradle-plugin](<https://devfeed.tech/tags/gradle-plugin.md>), [jetbrains](<https://devfeed.tech/tags/jetbrains.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-android](<https://devfeed.tech/tags/kotlin-android.md>), [kotlin-android-extensions](<https://devfeed.tech/tags/kotlin-android-extensions.md>), [parcelable](<https://devfeed.tech/tags/parcelable.md>), [parcelize](<https://devfeed.tech/tags/parcelize.md>), [plugin](<https://devfeed.tech/tags/plugin.md>), [production](<https://devfeed.tech/tags/production.md>)

### AI overview

This article examines Kotlin's Parcelize feature, formerly part of Kotlin Android Extensions, as a production-ready way to generate Android Parcelable implementations. It discusses the feature's generated-code efficiency, plugin support, handling of unsupported types, and lack of runtime library overhead, then introduces the required Kotlin and Android Studio setup.

### Source excerpt

Life is too short to waste time on writing Parcelable code Two years ago, I wrote about how you can leverage features of the Kotlin programming language to manually write your Android Parcelable implementations in the most concise and readable way. Does it mean that I always prefer writing this code manually rather than letting a library or tool generate it for me? Of course not: like most developers, I believe that the best code is the code you don't have to write. But I expect the tools I use to meet my quality standards. That's why I tend to be conservative about the dependencies I add to my projects and will always favor official libraries from Jetbrains or Google over third-party solutions. Things have changed for the better since I wrote the previous article: with the release of Kotlin 1.3.40, @Parcelize is now a stable feature provided by the Parcelize Gradle plugin (formerly known as Kotlin Android Extensions). And since version 1.3.60, the Android Studio plugin also properly recognizes the feature as non-experimental so it can finally be considered as production-ready. I previously enumerated a list of some of the negative aspects of third-party Parcelable code generation libraries compared to manual implementation. Here's why I believe @Parcelize stands out from the rest in regard to that list: It's an official plugin made by JetBrains with the collaboration of Google and is guaranteed to be well supported in the future The generated code of @Parcelize is very efficient (as we'll discover further in this article) The CREATOR field doesn't have to be declared at all, along with that easy-to-forget @JvmField annotation Thanks to the Parceler interface, it is possible to write simple plugins to handle unsupported types or override the default implementation No extra classes are created by the plugin. All the generated code is embedded in the annotated class so the app will behave exactly as if you wrote the code yourself There is no runtime library overhead a

## Advanced JSON parsing techniques using Moshi and Kotlin

DevFeed: [Advanced JSON parsing techniques using Moshi and Kotlin](<https://devfeed.tech/articles/advanced-json-parsing-techniques-using-moshi-and-kotlin-25877.md>)

Original publisher: [Read original article](<https://bladecoder.medium.com/advanced-json-parsing-techniques-using-moshi-and-kotlin-daf56a7b963d?source=rss-54910f05af37------2>)

Author: Christophe Beyls

Published: 2018-07-30T23:12:56Z

Content type: tutorial

Language: en

Sources: [Stories by Christophe Beyls on Medium](<https://devfeed.tech/sources/stories-by-christophe-beyls-on-medium.md>)

Topics: [JSON](<https://devfeed.tech/topics/json.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Parsing](<https://devfeed.tech/topics/parsing.md>), [Parser](<https://devfeed.tech/topics/parser.md>), [Android](<https://devfeed.tech/topics/android.md>), [Java](<https://devfeed.tech/topics/java.md>), [Library](<https://devfeed.tech/topics/library.md>), [Streaming](<https://devfeed.tech/topics/streaming.md>)

Tags: [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [code](<https://devfeed.tech/tags/code.md>), [gson](<https://devfeed.tech/tags/gson.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [java](<https://devfeed.tech/tags/java.md>), [json](<https://devfeed.tech/tags/json.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [moshi](<https://devfeed.tech/tags/moshi.md>), [parsing](<https://devfeed.tech/tags/parsing.md>), [performance](<https://devfeed.tech/tags/performance.md>), [streaming](<https://devfeed.tech/tags/streaming.md>)

### AI overview

A tutorial on parsing JSON with Moshi and Kotlin. It demonstrates manual streaming parsing, handling required and optional properties, skipping unknown values, and optimizing repeated key comparisons using Moshi and Okio.

### Source excerpt

A match made in parser heaven Moshi is a modern JSON library for Android and Java from Square. It can be considered as the successor to GSON, with a simpler and leaner API and an architecture enabling better performance through the use of the Okio library. It's also the most Kotlin-friendly library you can use to parse JSON files, as it comes with Kotlin-aware extensions. In this article I'm going to demonstrate how to take advantage of features from both the Moshi library and the Kotlin language itself in order to write efficient and robust JSON parsers. The example model and JSON file Consider the following model representing a person: class Person(val id: Long, val name: String, val age: Int = -1) id and name are mandatory properties, while the age is optional with a default value of -1. Our objective is to load a list of Person objects in our application from a JSON file or stream with the following contents: [ { "id": 1, "name": "John", "age": 38 }, { "id": 8, "name": "Lisa", "age": 23 }, { "id": 23, "name": "Karen" } ] In this simple example, the JSON object key names exactly match the Person property names and the "age" key is also optional. 1. Fully manual parsing The most basic way of parsing JSON using Moshi is to use the streaming API, which is similar to the streaming API of GSON and the one provided by the Android Framework. This gives you the most control over the parsing process, which is especially useful when the JSON source is dirty. Typical code would look like this: class ManualParser { fun parse(reader: JsonReader): List<Person> { val result = mutableListOf<Person>() reader.beginArray() while (reader.hasNext()) { var id: Long = -1L var name: String = "" var age: Int = -1 reader.beginObject() while (reader.hasNext()) { when (reader.nextName()) { "id" -> id = reader.nextLong() "name" -> name = reader.nextString() "age" -> age = reader.nextInt() else -> reader.skipValue() } } reader.endObject() if (id == -1L || name == "") { throw JsonDataException

## Flash your Lenovo Ideapad laptop BIOS from Linux using UEFI capsule updates

DevFeed: [Flash your Lenovo Ideapad laptop BIOS from Linux using UEFI capsule updates](<https://devfeed.tech/articles/flash-your-lenovo-ideapad-laptop-bios-from-linux-using-uefi-capsule-updates-25880.md>)

Original publisher: [Read original article](<https://bladecoder.medium.com/flash-your-lenovo-ideapad-laptop-bios-from-linux-using-uefi-capsule-updates-a82e455ea29c?source=rss-54910f05af37------2>)

Author: Christophe Beyls

Published: 2018-07-14T23:20:42Z

Content type: tutorial

Language: en

Sources: [Stories by Christophe Beyls on Medium](<https://devfeed.tech/sources/stories-by-christophe-beyls-on-medium.md>)

Topics: [UEFI](<https://devfeed.tech/topics/uefi.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [Embedded Software Dev](<https://devfeed.tech/topics/embedded-software-dev.md>), [Vulnerabilities](<https://devfeed.tech/topics/vulnerabilities.md>)

Tags: [bootloader](<https://devfeed.tech/tags/bootloader.md>), [firmware](<https://devfeed.tech/tags/firmware.md>), [firmware-update](<https://devfeed.tech/tags/firmware-update.md>), [laptop](<https://devfeed.tech/tags/laptop.md>), [lenovo](<https://devfeed.tech/tags/lenovo.md>), [linux](<https://devfeed.tech/tags/linux.md>), [uefi](<https://devfeed.tech/tags/uefi.md>), [vulnerabilities](<https://devfeed.tech/tags/vulnerabilities.md>)

### AI overview

This tutorial explains how to update the BIOS of a Lenovo Ideapad laptop from an existing Linux installation using UEFI Capsule Updates. It describes how some Lenovo Windows executables may contain a capsule update and outlines the requirements for the standard UEFI update mechanism, including booting Linux in UEFI mode with an EFI system partition.

### Source excerpt

I'm the happy owner of a Lenovo Ideapad laptop (model 710S-13IKB). It's comparable to the Dell XPS 13 and runs beautifully under Linux, but one detail has always been bugging me: Lenovo only provides BIOS updates for its Ideapad laptops in the form of Windows 10 executable files. System firmware updates are important, especially to mitigate newly found vulnerabilities like Meltdown and Spectre. Since I wiped Windows off my machine a long time ago, I was wondering if there was an alternative (and secure) way to flash firmware updates on it. And it turns out there is! After months of investigation, I found an elegant and stable update procedure which doesn't require Windows at all. It doesn't even need the creation of a bootable USB key: everything is done from the existing Linux installation. How is that possible? Let me introduce you to an interesting new feature of the UEFI specification. Different machines, different firmware updates Many latop brands like Dell or Asus provide firmware files that you can put on a USB key and flash from an update application located in the BIOS menu itself. Lenovo does not. Instead, they give you two options: For the higher-end ThinkPad series inherited from IBM, they provide bootable CD images that can be turned into bootable USB keys. That's another good OS-agnostic solution. For the Ideapad and Yoga series, you're stuck with a Windows executable file. The contents of this file and the actual flashing procedure varies depending on the BIOS/Firmware brand. If you have a modern machine with a Phoenix firmware, chances are that the Windows executable contains the update in the form of an UEFI Capsule Update. Capsule what? When a firmware is distributed in that form, the update program won't flash it directly under Windows. Instead, it will delegate the task to the standard UEFI update mechanism called Capsule Update. In practice, it will ask the operating system to copy an update file to the system partition then program the UEFI to

## Avoiding LiveData observer leaks in the Android Fragment lifecycle

DevFeed: [Avoiding LiveData observer leaks in the Android Fragment lifecycle](<https://devfeed.tech/articles/architecture-components-pitfalls-part-1-25878.md>)

Original publisher: [Read original article](<https://bladecoder.medium.com/architecture-components-pitfalls-part-1-9300dd969808?source=rss-54910f05af37------2>)

Author: Christophe Beyls

Published: 2017-10-24T19:31:14Z

Content type: tutorial

Language: en

Sources: [Stories by Christophe Beyls on Medium](<https://devfeed.tech/sources/stories-by-christophe-beyls-on-medium.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [configuration](<https://devfeed.tech/topics/configuration.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [architecture-components](<https://devfeed.tech/tags/architecture-components.md>), [asynchronous](<https://devfeed.tech/tags/asynchronous.md>), [deprecated](<https://devfeed.tech/tags/deprecated.md>), [fragments](<https://devfeed.tech/tags/fragments.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [lifecycle](<https://devfeed.tech/tags/lifecycle.md>), [livedata](<https://devfeed.tech/tags/livedata.md>), [memory](<https://devfeed.tech/tags/memory.md>), [memory-leak](<https://devfeed.tech/tags/memory-leak.md>), [performance](<https://devfeed.tech/tags/performance.md>), [viewmodel](<https://devfeed.tech/tags/viewmodel.md>)

### 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