YouTooBeAlike
MyGoodDoggoApp
YouTooBeAlike | MyGoodDoggoApp | |
---|---|---|
2 | 2 | |
2 | 2 | |
- | - | |
6.7 | 0.0 | |
about 1 year ago | about 1 year ago | |
Kotlin | Kotlin | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
YouTooBeAlike
-
I’m creating 2 simple practice apps that have a shared code base (mostly). A simple hit an api and crate a list. Would the recyclerview be in the shared folder or one in each app folder? Is there a good example I can look at?
Not sure why you're asking specifically about recycler view. If your application shares most of the code, I highly recommend modularization by feature and layer. You can then create a second application as a second application module in the same project. Check out the official guide, or if you're interested in my codebase with a slightly different approach.
-
How are you supposed to handle one time events with sealed classes?
If your error message is cleared after being displayed, it has a different lifecycle than UiState. This means you should declare another value to describe this one-time operation instead of just clearing the error message in UiState. This Github Gist is a possible UiState declaration that fits your scenario. If you want to reference a sample project, here is the Github repo.
MyGoodDoggoApp
-
Clean Architecture VS. Official documentation!
On the other hand, reducing events by validating uuids is absurd. All you need to do is define a sealed interface implemented by data classes and objects as your event types. Use a single view model function that takes the type as input to reduce events. Examples can be seen here.
-
Sharing my newly created MVVM template. Feedback wanted :)
Regarding state persistence, I'm currently relying on the activity/fragment itself to store and restore. I've used SavedStateHandle before and one problem I've found is that it doesn't persist across fragment attachments. I implemented state restoration in ThumbnailInfoFragment and ThumbnailInfoViewModel of demo project. I'm wondering if this is a good approach or if I should switch to SavedStateHandle. It seems I can directly store the State object in SavedStateHandle instead of reloading it with persistent parameters after process death.
What are some alternatives?
Clother - Clother is an Android client-server app for swapping unused clothes.
Android-Clean-Architecture - 🎞 A demo movie android app showcasing Clean Architecture, written in Kotlin and featuring Jetpack Compose for modern, declarative UIs. (Offline-first App)
Delish - Delish, a Food Recipes App in Jetpack Compose and Hilt based on modern Android tech-stacks and MVI clean architecture.
Foodium - 🍲Foodium is a sample food blog Android application 📱 built to demonstrate the use of Modern Android development tools - (Kotlin, Coroutines, Flow, Dagger 2/Hilt, Architecture Components, MVVM, Room, Retrofit, Moshi, Material Components).
android-template - Android app starter template
AndroidCleanArchitecture - This is a project built with Love ❤️ and also with Clean architecture in Android .
compose-samples - Official Jetpack Compose samples.