dagger-android is the worst (open-api refactor)

This is part of a course "Powerful Android Apps with Jetpack Architecture": codingwithmitc...
In this video I remove dagger-android from the open-api android app. This is the app from the "Powerful Android Apps with Jetpack Architecture" course. I also create Fragment Factories for providing all the fragments and create custom NavHostFragment's for each feature. These changes will allow us to do constructor injection with the fragments and easily manage separate navigation graphs with separate backstacks.
Instagram: / codingwithmitch
Twitter: / mitch_tabian
.
.
#codingwithmitch

[@atifmbhutta]

Mitch makes the best videos. I am a huge fan of him. I will watch this video completely for sure. I guess I should join your membership as well.

[@codingwithmitch]

You're not a member? What are you waiting for? 😮 codingwithmitch.com/enroll/

[@teyyihanaksu]

Google: Will you use Hilt? Me waiting for Mitch to drop video: No, i don't think i will

[@armandoavila4615]

I read somewhere that Google Developers aren't happy either with dagger-android and they are working in a new implementation of Dagger for Android

[@jaromor8808]

oh boy

[@MrLeeKnees]

Hilt?

[@farazahmed7]

This comment aged well

[@Zhuinden]

I actually kinda disagree with the initial glance of "Dagger-Android is bad" (I'm at 0:00), Dagger-Android is amazing, you just shouldn't use it to inject any core Android components (Activity, Fragment, View, ViewModel, etc.), though to be honest that means Dagger-Android is pretty bad for what they intended it for :D so yeah, best to remove it

[@Zhuinden]

The new variant is better (man, Dagger-Android really does leave in a lot of cruft, huh - it only makes sense in incorrectly modularized applications anyway), although I'm not sure why you aren't using the same multi-binding trick for your Fragments that you do for ViewModels, merge the 4 ViewModelProvider.Factories into 1 because they're stateless therefore require no scoping, and use 1 FragmentFactory via multi-binding as `Provider` can technically be unscoped, and that way you can use 1 NavHostFragment instead of 4. Also consider merging `__Module, __ViewModelModule, __FragmentModule` into 1 module, and create a module per screen, which you collect together into 1 module via `includes=[]` per feature.

[@jakhongirmadaminov5849]

Hi, I love your channel and it helps me a lot, thanx a lot for your work. I've tried bottomNav with navigation components but the only problem with it is that the fragments are always recreated as navController.navigate() uses fragmenTransaction.replace() under the hood, so I was wondering have you found any workaround for this, to hiding and showing fragments rather than replacing with a new instance?

[@reviewsbysfh3102]

Nice video. I want to ask one question is every section has the different nav graph so if bottom nav menu's has only 1 fragment like About so what is the good approach either create separate nav graph for each menu or only one graph?

[@tyresswhitejr]

Hey Mitch. I know that by using the navigation library it allows for fragments to be destroyed every time a new fragment is loaded into the navhost. Simply saving a little memory space. But what's the point if you could simply use ViewPager2 and unsubscribe from listeners when switching between fragments?

[@MCaimer]

Hey Mitch, It was great video. I wondered is it possible to override the navigation? For example: I check is the next fragment needs any permission. If not given then it navigates to a fragment which explains why it's needed.

[@riyupapa39]

Peoples saying that in large project, use Dagger. In small project, use Koin. I studied both. And found Koin is very easy than Dagger. But google said use Dagger. So it is defcult to choose between dagger and koin .....

[@anshuchauhan9596]

I have already refactored my code with Dagger only not Android one

[@tashi7160]

Should avoid Builder if possible and instead use Factory. Component Factory has compile-time safety since all the bind instances will be part of the creation. And great tutorial Mitch as always :)

[@whilson03]

Could you add a method to support explicit deeplinks

[@muzamilabdallah6768]

MITCH I'm very happy with you as tutor can you plz make tutorial or vedio about how you well architect your app (ui layer domin layer an service layer ...) and thanks in advance

[@codingwithmitch]

I have lots of courses containing that information. This one for example: codingwithmitch.com/courses/model-view-intent-mvi-architecture/

[@christianfranciscallelero2110]

how about implementing lifecyclescopes instead of jobs? Also, can't we use Dagger scopes to manage the dependencies instance instead of managing them in the application class?

[@codingwithmitch]

lifecycleScopes is OK. The problem is that if you cancel the scope that scope is unusable after. So if you share a viewmodel between many fragments and cancel a job after a destination change, the scope is not usable anymore. You still have to create the component. Scoping only works if you have something that owns the scope.

[@christianfranciscallelero2110]

I see, you're right when you need to cancel some request. Still I would prefer to use lifecycleScope and viewmodelScope for ease of use. Anyway I'm still grateful for this tutorial, and would love to watch more of your videos. I followed your previous implementation using dagger android and can't decide if we'll be reverting it also or just use koin.

[@codingwithmitch]

@@christianfranciscallelero2110 Koin is fine also. Nothing wrong with that.

[@christianfranciscallelero2110]

thank you for the suggestion. ease in implementation is really tempting if we were to use koin. currently im implementing koin in a small project and so far im not having any issues yet.

[@j2shoes288]

nice hair cut, by the way! it really suits you.

[@lexandro]

I also tried to add to my app after your videos, but finally I decided to replace with (Service/Repository/etc)Locators...

[@codingwithmitch]

koin?

[@KhoaNguyen-ou8xg]

I just blindly follow this so that I can follow the Hilt migration :)

[@ekkawutemeelugsana7068]

@ CodingWithMitch I'm your fan. but i have to disagree with you on this. edit: the way i gonna show you is you don't need to unnecessary subComponent or scope because each part take care their own scope AppCompoent will be the only one Component All Activity will be subCompoent and have their own scope and ViewModel All Fragment will have their own scope and ViewModel that can attach to to all the activity so if you need to use fragment for different activity or fragment is no problem at all -> HomeFragment() -> UserFragment() all 3 will be in the scope of -> MainActivity() -> App() -> SettingFragment() -> UserFragment() -> SettingFragment() all 3 will be in the scope of -> AuthActivity() -> App() -> someFragment() so if you lunch AuthActivity you are inside Appcompont that's @Singleton scope all 3 fragment stay inside AuthActivity Scope automatically UserFragment has ViewModel and it stay in the Scope of this UserFragment itself so no need to make unnecessary @Scope I'm not gonna say what you do is right or wrong because you can get it done for final result. But It's not the best way to do it. And nothing wrong with dagger-android but actually it's Super great!!! It's shorter, cleaner, more easy to read and understand. I will show you step by step === AppComponent === @Singleton @Component( modules = [ AndroidSupportInjectionModule::class, ActivityInjectorsModule::class, FragmentInjectorsModule::class, AppModule::class] ) interface AppComponent { @Component.Builder interface Builder { @BindsInstance fun application(application: App): Builder fun build(): AppComponent } fun inject(app: App) } AppComponent take care for these - AndroidSupportInjectionModule -ActivityInjectorsModule -FragmentInjectorsModule -AppModule So live at @Singleton Scope to be continued...

[@ekkawutemeelugsana7068]

I will skip AndroidSupportInjectionModule for now first. We will start with ActivityInjectorsModule ActivityInjectorsModule will provides all the Activities @Module abstract class ActivityInjectorsModule { @ContributesAndroidInjector(modules = [MainModule::class]) abstract fun mainActivityInjector(): MainActivity } so the basic thing is just get you the activity howto get the MainActivity and if MainActivity has ViewModel? sure it's from MainModule Let see what inside MainModule @Module class MainModule { @Provides @ViewModelInjection fun provideMainVM( activity: MainActivity, viewModelProvider: InjectionViewModelProvider ): MainVM = viewModelProvider.get(activity) } So the step will be App -> MainActivity -> MainViewModel do you see the scope? Because Inside MainModule Provide it own MainViewModel That's the Responsibility for MainActivity to create MainViewModel nothing else To be continue...

[@ekkawutemeelugsana7068]

How we gonna Provide Generic ViewModel and have their scope connection to their activity or fragment we start with create Anotation for ViewModelInjection @Qualifier @MustBeDocumented @Retention(AnnotationRetention.RUNTIME) @Target(AnnotationTarget.FIELD, AnnotationTarget.FUNCTION) annotation class ViewModelInjection and this is the generic Viewmodel class InjectionViewModelProvider @Inject constructor( private val lazyViewModel: dagger.Lazy ) { @Suppress("UNCHECKED_CAST") val viewModelFactory = object : ViewModelProvider.Factory { override fun create(modelClass: Class) = lazyViewModel.get() as T } inline fun get(activity: ACTIVITY): VM { return ViewModelProvider(activity, viewModelFactory).get(VM::class.java) } inline fun get(fragment: FRAGMENT): VM { return ViewModelProvider(fragment, viewModelFactory).get(VM::class.java) } } that's it so each activity or fragment module classes just add this code and you get your ViewModel easy Huh? @Provides @ViewModelInjection fun provideMainVM( activity: MainActivity, viewModelProvider: InjectionViewModelProvider ): MainVM = viewModelProvider.get(activity) }

[@ekkawutemeelugsana7068]

How we gonna Inject ViewModel to the MainActivity? abstract class BaseActivity : DaggerAppCompatActivity() { @LayoutRes abstract fun layoutRes(): Int override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(layoutRes()) } override fun onDestroy() { super.onDestroy() } } class MainActivity : BaseActivity() { @Inject @ViewModelInjection lateinit var viewModel: MainVM override fun layoutRes() = R.layout.activity_main override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) } } that's it your MainViewModel is in the scope of your MainActivity only

[@ekkawutemeelugsana7068]

abstract class BaseViewModel() : ViewModel() { val compositeDisposable = CompositeDisposable() } class MainVM @Inject constructor() : BaseViewModel() { // MainViewModel Class }

[@ekkawutemeelugsana7068]

so AppComponent only know how to Inject and provide android inject and provide activities Module create and inject fragments Module to provide App (name of Activity or fragment)Module only know how to provide their own Activity/Fragment and inject their own ViewModel

[@gouravkundu8105]

can we have different scope for different fragmentfactory in MainFragmentsModule.

[@codingwithmitch]

You can't use different scopes in a single module

[@hazem-allaham_6752]

you is a great teacher .. Need Some New library Animation

[@gouravkundu8105]

Can you please elaborate the CustomNavHostFragment section in details.

[@codingwithmitch]

It's a custom NavHostFragment where I set the factory for producing the fragments

[@gregfrllo]

Wait, i was just about to get started at dagger video in open-api course, should i start here instead?

[@codingwithmitch]

No just go through it. It will be to disruptive to change mid course. You can refactor to dagger at the end.

[@MrClaudioAgostini]

Most mobile apps are relatively simple and don't need any DI framework at all (manual DI is the best option). Dagger is not even an option in my opinion.

[@mehranj73]

I'm a newbie to Dagger. Do you know a GitHub android source code that just uses dagger not the android dagger?

[@codingwithmitch]

Yes, the project I'm working on in this video. github.com/mitchtabian/Open-API-Android-App codingwithmitch.com/courses/powerful-android-apps-with-jetpack-architecture/

[@jakhongirmadaminov5849]

51:40 HILARIOUS BUUURP))

[@ivanalejandro5814]

classic mitch

[@faizaaslam100]

I hate dagger too. It keeps changing and refactoring. Fed up with this library.

[@maheral2422]

Please, Mr. Mitch, I would like you to guide me on the right path that I must take as a beginner Android developer. Please advise me on the path that I have to take on your channel.

[@codingwithmitch]

Do you want to do kotlin or java?

[@maheral2422]

@@codingwithmitch java

[@maheral2422]

​@@codingwithmitch After everything is finished, I will move to Kotlin. Is this the correct way?

[@codingwithmitch]

@@maheral2422 After what is finished?

[@codingwithmitch]

@@maheral2422 I have a free beginners course here: codingwithmitch.com/courses/sqlite-room-persistence-android/

[@HienNguyen-xn7tr]

what about the sword android abb?

[@evansshango2503]

Hey Mitch, could you please handle a tutorial using kodein

[@codingwithmitch]

I'll make one with koin prob

[@hnim2292]

Wow, what a video! Even if you don't go through open-api course this video is really helpful. I'm wondering if fun create() do the same thing as build() can we exchange this? Like in AppComponent @Component.Factory interface Builder { @BindsInstance fun application(application: Application): Builder fun create(): AppComponent }

[@codingwithmitch]

no. If you want to use build() then use the Builder

[@hnim2292]

@@codingwithmitch I have another question. If I don't use fragmentFactory, can I inject things into fragments? (not through constructor). Because I remembered the dagger-android provide DaggerFragment() for some reason.

[@codingwithmitch]

@@hnim2292 Yes you can do field injection

[@hnim2292]

@@codingwithmitch Thanks, I just did some research. I think I need to add fun inject(fragment: FragmentClass) to the component right? So in the fragment class I will call that function and be able to do filed injection

[@codingwithmitch]

@@hnim2292 yes. You need to add it to the dagger graph. Otherwise you can mark the constructor with @inject but then you must provide the fragment in a module or through a factory

[@taar1]

Finally someone who says that dagger sucks, I don't see the advantage of using it vs. the pain that comes with it. I wanna get rid of it altogether, too.

[@codingwithmitch]

I like dagger. Just not dagger-android

[@Zhuinden]

Eh. I joined this project, using Dagger (and also Dagger-Android but that's not relevant for the discussion). You had to add 3 modules for a screen, modify 3 files, and then modify 1 more file. If you screwed up any of the configuration, it would be runtime error. I shifted around the structure of modules, now you add 1 module, you modify 1 more file, and forgetting is a compilation time error. People just have NO idea WTF they're doing with Dagger.

[@codingwithmitch]

@@Zhuinden I don't understand your comment. You are saying what I did in this video was dumb?

[@Zhuinden]

@@codingwithmitch No, I haven't seen this video yet. I'm talking about this project I joined that mirrored GithubBrowserSample to the T, and had a ViewModelModule, a ScreenModule, and a FragmentModule, FOR EACH SCREEN. Like, just why? And then the developers blamed Dagger, even though what they were doing made no sense.

[@codingwithmitch]

@@Zhuinden Oh I gotcha. I read it like: "I joined THIS project..." as in my app. The github browser sample has a lot of flaws. There's some good stuff don't get me wrong, I learned a lot from that sample back in the day. But some things I just shake my head.

[@nymexe]

I think you're just duplicating a lot of code to maintain.

[@MuhammadFarhan-pq2wc]

I don't know why you just started saying that android-dagger is SHIT. Please make a video of an explanation why should we use JUST Dagger2, not Android-Dagger which is created by Google for Android-specific DI purpose. Thanks.

[@codingwithmitch]

It puts you in a box. Regular dagger is complete freedom. If dagger-android works for you then use it.

[@MuhammadFarhan-pq2wc]

@@codingwithmitch Yeah, I think If you are working on TDD then you should definitely use Dagger2 but if you don't do the testing then it's your choice.

[@etino]

Koin?

[@adoniasalcantara522]

@HOUSSEM ZAIER are you saying that use nothing is better than koin?

[@MuhammadFarhan-pq2wc]

@HOUSSEM ZAIER Can you please provide the Blog or video of Jake Wharton ?

[@codingwithmitch]

I'll do a video on koin