15:00 For those who want to use the alternative of startActivityForResult, it should have been mentioned that you need to update to these: implementation "androidx.fragment:fragment:1.3.0-alpha06" implementation "androidx.fragment:fragment-ktx:1.3.0-alpha06"
Everything Yigit says is gold. I wasn't a fan of Navigation initially, but Navigation 2.2.0 is already amazing: NavGraph-scoped ViewModels with SavedStateHandle support are a game changer. Tbh it'd actually already solve the result passing that 2.3.0 adds, but I guess it's a nice solution when people really are looking for "the simplest thing".
Thank you for Hilt. I hate Dagger because of the steep learning curve I only use it if I'm forced to. Now with Hilt hopefully DI will become part of all my projects.
Hi. Why did you design Paging3 with extension of PagingSource? Extension is always hard to Unit-test. You could create interface with all methods to implement and expect it in ctor. That all reminds old story with Thread-class. Does one should extent it or inject with Runnable?!
Does it make sense to have Bill of Materials (BoM) for jet pack? There are too many libraries now and it will make it easy to be on top of the latest releases.
I am still confuse why does Navigation alway use replace fragment which cause fragment is re-created when I popBack. In many cases, I would like to keep the fragment alive. I tried to use dialog instead of fragment but they consume too much memory.
What if you want to pass multiple values back from navigation? SavedStateHandle observers only works for one value, so you have to spam observers for each value you want to return which will happen in an unpredictable order.
@@crjacinro Google always pushed dagger as main DI for android, they are now investing resources to make it easier for beginners by introducing hilt, Koin is never in the picture
Umm.. just why hilt.. Koin is way better and readable.. Lesser compilation times (dryRun as a unit test when you actually change your dependencies) Can remove dependencies at run time (unload modules, simpler than scopes) Some 11 ms delay in startup for 400 dependencies which is totally acceptable for the benefits you get (lesser compilation times)..
How about better game development support when we can develop native mobile games with nice visual editor in Android Studio just using Kotlin and get rid of all this third parties like c# with Unity?
I thought with next version of Paging you will provide some easier way to update/delete item in RecyclerView and I'm disappointed we are still forced to use Room or do extra work to have such a common scenario
Just went through hilt by making a sample application. Must say that zero amount of boilerplate code is needed to add hilt in your apps. A great wrapper library indeed. Thank you android team.
I wish some in house lifecycle support for bound events, because the existent way to use observable live variables to it, is a damn antipattern. Actions aren't data.
@@TekEffekt I was a Dagger user since the very beginning, and it was OK. Dagger was framework-independent, and with proper architecture, one could really easy in-build it into Android application. And then... Google appears with this crazy idea to make Android dev live easier, and the learning curve of Dagger became almost vertical. Eventually, we end up with this monster: github.com/android/architecture-components-samples/blob/master/GithubBrowserSample/app/src/main/java/com/android/example/github/viewmodel/GithubViewModelFactory.kt You could tell, then this is one man's opinion - agree. Actually, the only argument I need is in this video itself (quote): "... we were able to delete 75% of the dependency injection code".
