Hey Philip - thanks again for your videos. I enjoy your full projects where you demonstrate your own "best-practices". I can see these have changed a bit over time as you refine your techniques and new features appear. I would like to see a project that updates your usages (or non-usage) of MVVM, @Singleton injection, single ViewModel State class vs separate state val/vars, SharedStateFlow (and other topics I am missing here) where your practice has been refined over the past year. I like to use your projects as a template for things that I do on my own.
Great video :). Do you have a recommendation for using Retrofit with multiple base URLs? With Hilt in particular one option could be to provide a new retrofit instance for each API interface that uses a different URL. However, I'm not sure if this is the best approach.
If you know the base URL at compile time, you can just pass the right one into the interface (like localhost + prod). If not, you could replace it using an interceptor
A pity you didn't post this video a few months earlier because otherwise I shouldn't have to explain this by myself, saying we shouldn't abuse Singleton, which people at that time didn't agree with me, but they watch your video and they trust you :)
very awesome man ..... I have a question please ..... I am trying to access my storage by media store .... this needs the context but I think this is a logic and I want to put this fun in my viewModel ....I have tried to inject the instance of this object to the viewModel by hilt but it doesn't work so I have used androidViewModel .....can I Inject it or I am right to use androidViewModel or just let this fun in composable ?
Hello Philippe, many thanks for the video. Could you please do a video explaining how to load json data from resources? Point the direction? Trying Gson library (deprecated). Now Moshi lib, but the examples don't contemplate local resources files. Loading json file for mock data is very common (easy) in ios development.
Why do you scope the dependency at all? It makes no difference in your examples, which are more about scoping the viewModels to the right anchor, but since there is only a single injection point and you are not consuming the Activity or Fragment as a dependency in your SessionTimer, scoping it to the ViewModel is misleading in my mind. The ViewModel is already retained by Android, so by using @ViewModelScoped you hold a reference to SessionTimer twice, but both with the same scope. Under the hood, scoping it will use a Lazy instance, which is only useful if the same instance needs to be used in multiple injection points. Dependencies are also never destroyed, they just fall out of scope when there are no more references to it and are then garbage collected. If in doubt and unless specifically required, unscoped dependencies are usually better. I agree you don't want to use @Singleton here at all. This video is about scoping ViewModels and IMO does not sufficiently explain Dagger+Hilt scopes and when to use them.
Sorry, but even the Dagger documentation states that you should not really bother with smaller scopes until your application's logic requires it (like it does in this video). The example you've given here is great, but it does not work to say in general that you should always use the smallest scope available/suitable.
should i register my use_case class as ViewModelComponent instead of SingletonComponent considering that most of the use_case class is in charge of fetching data from repository and partly managing flow for logic to ui?
Hey Philipp 👋 I'm learning something new from You everyday. With proficient and detailed explanation I get a clearer picture in my head. 💯🔝💪
Glad it helps! 🙏
As a professional dev, thanks, that's really cool. The part scope vm to nav scope. I spent a lot of time to figure it out.
Hey Philip - thanks again for your videos. I enjoy your full projects where you demonstrate your own "best-practices". I can see these have changed a bit over time as you refine your techniques and new features appear. I would like to see a project that updates your usages (or non-usage) of MVVM, @Singleton injection, single ViewModel State class vs separate state val/vars, SharedStateFlow (and other topics I am missing here) where your practice has been refined over the past year. I like to use your projects as a template for things that I do on my own.
Nice little tutorial! Noticed that you seem to use the Xcode-Dark theme, I really like that theme :)
Your tips and trainings are just extraordinary, man! thank you
Thanks bro! You helped me a lot!
Great video :). Do you have a recommendation for using Retrofit with multiple base URLs? With Hilt in particular one option could be to provide a new retrofit instance for each API interface that uses a different URL. However, I'm not sure if this is the best approach.
I would do the same as you. I think there's no better way
If you know the base URL at compile time, you can just pass the right one into the interface (like localhost + prod). If not, you could replace it using an interceptor
Hmm, then why you simply don't use the BASE_URL and put the complete URL directly instead?
I logged in to ask the same question but saw that you already asked it. I’ll look up how to do it using hilt.
In my case I do know the URLs at compile time. Do you mean like this?
interface ApiOne {
@GET("aPath/")
suspend fun getSomthing(
@Path("thing_id") thingID: String,
): ThingDto
companion object {
const val BASE_URL = "URLONE"
}
}
interface ApiTwo {
@GET("anotherPath/")
suspend fun getSomthing(
@Path("another_thing_id") anotherthingID: String,
): AnotherThingDto
companion object {
const val BASE_URL = "URLTWO"
}
}
@Provides
@Singleton
fun provideApiOne(): ApiOne {
return Retrofit.Builder()
.baseUrl(ApiOne.BASE_URL)
.addConverterFactory(MoshiConverterFactory.create())
.build()
.create()
}
@Provides
@Singleton
fun provideApiTwo(): ApiTwo {
return Retrofit.Builder()
.baseUrl(ApiTwo.BASE_URL)
.addConverterFactory(MoshiConverterFactory.create())
.build()
.create()
}
Exactly the video I was looking for 🙏
Please create a whole new series of Android Development (Kotlin) from Beginner to Advance Level..
Please... Love you from India🥰🥰🥰
A pity you didn't post this video a few months earlier because otherwise I shouldn't have to explain this by myself, saying we shouldn't abuse Singleton, which people at that time didn't agree with me, but they watch your video and they trust you :)
Super amazing!😎👍
Such a nice explanation (Y)
thx a lot for what you r doing! keep it going pls!
What theme are you using? It looks pretty
very awesome man ..... I have a question please ..... I am trying to access my storage by media store .... this needs the context but I think this is a logic and I want to put this fun in my viewModel ....I have tried to inject the instance of this object to the viewModel by hilt but it doesn't work so I have used androidViewModel .....can I Inject it or I am right to use androidViewModel or just let this fun in composable ?
I hope you add subtitles for Indonesian, I am greatly helped from your Android learning video, thank you Mr Philipp Lackner. 🙇
I bet you can improve your english a lot just by watching english youtube videos without subs, that's how I learned english.
What is the safe way to collect flows, in case the app goes to the background, can you make a tutorial on this topic?
Hello Philippe, many thanks for the video. Could you please do a video explaining how to load json data from resources? Point the direction? Trying Gson library (deprecated). Now Moshi lib, but the examples don't contemplate local resources files. Loading json file for mock data is very common (easy) in ios development.
Pleased make video about bottom navigation with compose destinations
very cool video
thank you bro👍👍👍👍
Could you create a video on how to use compose and XML based views like dialogs, fragments?
also singleton timer can be victim to race conditions
Why do you scope the dependency at all? It makes no difference in your examples, which are more about scoping the viewModels to the right anchor, but since there is only a single injection point and you are not consuming the Activity or Fragment as a dependency in your SessionTimer, scoping it to the ViewModel is misleading in my mind. The ViewModel is already retained by Android, so by using @ViewModelScoped you hold a reference to SessionTimer twice, but both with the same scope. Under the hood, scoping it will use a Lazy instance, which is only useful if the same instance needs to be used in multiple injection points. Dependencies are also never destroyed, they just fall out of scope when there are no more references to it and are then garbage collected. If in doubt and unless specifically required, unscoped dependencies are usually better. I agree you don't want to use @Singleton here at all.
This video is about scoping ViewModels and IMO does not sufficiently explain Dagger+Hilt scopes and when to use them.
Yes , it was more about sharing viewmodels across fragments / composables without the viewmodels themselves having lifecycle of activity .
Sorry, but even the Dagger documentation states that you should not really bother with smaller scopes until your application's logic requires it (like it does in this video). The example you've given here is great, but it does not work to say in general that you should always use the smallest scope available/suitable.
should i register my use_case class as ViewModelComponent instead of SingletonComponent considering that most of the use_case class is in charge of fetching data from repository and partly managing flow for logic to ui?
Yes
Is it correct scoping our repository to singleton? In MVVM Clean Architecture
why do your dagger-hilt dependencies differ from those in official dagger hilt site and android docs guide?
Does singleton in dagger survive process kill?
No
Tbh, why are you creating component for your own class, you can directly use constructor injection. It does not make sense in this example.
Should we write the @AndroidEntryPoint annotation on all activities or fragments that we have or only on the activity that is the launcher?
Please take Android's Hilt Codelabs, you don't seem to understand the basics yet, you only use that annotation in the classes you need DI.
Scoping viewmodel in compose is so ugly , fragments with individual composable ftw
you mean sharedViewModel in compose, but yeah cant use that
DI is to me the most uggly part of modern programming, I really hate it :D
You need to create a big project without DI, and later you will love DI. It solves problems that you don't know you had.
@@EnelAlmonte most of the android devs never saw a project as big as a few I worked on for years, never missed DI
First
Haha I'm first again
@@immortal_lnight stop. get some help
@@web3z161 🤣
Soon I will be first!😅
@@EnelAlmonte 😁
how you know this knowledge, where is place that you find document?