nowinandroid VS architecture-components-samples

I remember it. This is a more up to date version from Google: https://github.com/android/nowinandroid There's also lots of sample apps and codelabs on https://developer.android.com/?gclid=CjwKCAjw-IWkBhBTEiwA2exyO7rWOvWd5yxCtFE5tmogy5LvA7HbxqQGpEQZz7_2ke579DPIHN06rhoCa-sQAvD_BwE&gclsrc=aw.ds

Build your own views/screens. Abandon (pre-made) fragments as soon as you can and you will be a happier developer. Follow the Compose+ViewModel+DataStore+Repository pattern like https://github.com/android/nowinandroid/tree/main/feature/settings/src/main/java/com/google/samples/apps/nowinandroid/feature/settings

If you are comfortable around di, mvvm take a look at 'Now in android' project. repo. Uses compose and best practices.

For people curious, the NowInAndroid repo does do this "build-logic" Gradle structure. I used that as a reference to apply this in our repo and it's been an amazing experience. Never have I had such a simple way to introduce new modules to the codebase. Effortless.

Link: https://github.com/android/nowinandroid/tree/main/core

Look at good repos like nowinandroid

Perfect time to show the potential wins of updating the Java version. Some companies have already moved to newer Java versions, but most of the Android projects are still building with Java 11. This article shows the results of measuring the impact of building with different JDK versions in the project nowinandroid. We'll focus on incremental changes applied to the project, simulating the local builds.

https://github.com/android/architecture-components-samples/ was historically better

uh, maybe https://github.com/android/architecture-components-samples/tree/a87535608564103423415baddb1e586f0337be44/LiveDataSample/app/src/main/java/com/android/example/livedatabuilder

That's still an issue .

This covers the only Loading, only Success, only Error, Loading and Success, and Loading and Error possibilities. It harkens back to the old Android architecture components samples' Resource class.

I generally just advise not having an in-memory cache like this, as if you are using ViewModel, that's meant to be the cache, and repository is stateless. For some reason, people (including Google Dev Advocate Team) seem to not check the originator of the Jetpack Repository pattern which is https://github.com/android/architecture-components-samples/blob/2c19434f89e925b8bea56366faa0a197c5b90b96/GithubBrowserSample/app/src/main/java/com/android/example/github/repository/UserRepository.kt#L40-L41

I see you already have a multiple backstack handling ( judging by the gif ).If you've used approach from google advanced navigation sample, then it won't be an issue to just pop appropriate backstack upon tab reselection (if it's not the root node of the graph). That will give both recreation prevention + behaviour that you seek.

We'll implement the Tap Response Time measurement inside the Advanced Navigation Sample and focus on the navigation from the Title screen to the About screen.

Google's sample is enough good for starting. https://github.com/android/architecture-components-samples