You're making me learn compose in a mere couple of weeks. Why is noone else coming up with these essential videos? These solutions are so simple yet noone will mention them in a documentation
I dont like that he uses compose in each video. Sure it is nice if you want to learn it but I like when something is explained without much boilerplate. His older videos were more focused, idk. Nowadays he explains that subject but also 10 other :).
I have learnt a lot of languages and watched a lot of videos but yours are next level, whatever I need you have a video and exactly at the level I need and perfectly explained.
I really liked that you explained in such great detail. When you don't use Dagger-Hilt, everything becomes clearer despite the boilerplate code. I had a lot of memory leak issues with Context 🎉
Yeah i had the same its difficult to avoid Memory leaks if app context needed in ViewModel. But after i implemented Dagger Hilt, this Problem is practical non existent.
@@USS_Daedalus There are different approaches and sometimes you can work around using Context. However with injection it is much easier and I prefer Koin (KMP) instead Hilt (Android).
Thank you Philip. Btw love the random number guessing game at @13:30, real android development showcase. Also who at Google came up with that view model factory thing at @17:15 should be held accountable for his/her war crimes :)
Videos like this are necessary for developers in any level, sometime you need to know how a component really works and what its purpose is, in order to avoid bugs, performance issues and leaks.
Kotlin, OOP, Android... the more I learn, the more I am completely stunned at how ludicroulsy complex it is... so many different ways to overcome the global vs local variable problem (aka client-server where do I put the code/data problem)... Synthetics, deprecated, no longer supported, then findViewById/binding, now Jetpack Compose... what next?
Sadly it isn't called VVMM (View ViewModel Model) or MVMV (Model ViewModel View). That order makes more sense regarding what part has contact with which part.
Is this telling us we need to use ViewModel or just what it can be used for if we want to use it? Is it the only way to handle configuration changes or is it an alternative to APIs like rememberSaveable?
The deciding factor should be speed. If your project is simple enough, you can use rememberSaveable and it runs perfectly fine, you don't need much code either. If you have more complexity, it's better to use remember in combination with a viewmodel. Usually when it becomes too complex, you have a lot of logic functions regarding how you map your states. This is best done in a viewmodel to create the separation from the ui. This way the code is more flexible and less buggy. You can then update and save 100 specifically selected states in 1 small function according to a logic algorithm. Of course you would never reach this efficiency using rememberSaveable
@@nesletchimaew9209 Thanks! In some ways it's a tricky time to be an Android noob during the change from Views to Compose and picking up only bits and pieces of techniques and terminology from each with so much info referring to or expecting knowledge of earlier stuff. So far I've only done simple enough things to juse rememberSaveable but even then got lost with the list and mutable versions.
@@andrewdunbar828 it's very hard to find info on what you can do to make things easier. I use a wrapper class with a val value: T so that primitive data types can get put into the same class type. When I set a state for a boolean, i say val bs = States.VALUE.BOOLEAN(true). Then i make a map in the viewmodel for each data class i need to have access to in the UI. Then I put all of them i side another map, and make a new privatemap with mutable stateflows for all of them, and another public one using the mutable stateflows as regular stateflows. In the UI I then collect all of them as stateflows and then as states. The state in the UI will then be of the following type: Map If I have a States.VALUE and want to get the value, i have to read it like this: lets say i need a boolean, i go into the map and fetch the value like this: val entry = map[someConstant][someOtherConstant] i then read the state like this val state: Boolean = (entry as States.VALUE.BOOLEAN).value of course i have dozens of helper functions that do all of this with a few lines of code
This video is pretty much Android development in a nutshell. Part 1: The motivation behind MVVM; how it just totally simplifies the process of making changes on the UI, and keeping it synced with the data model that's being represented. Easy to implement, easy to understand, there's a good deal of boilerplate but it's easy to ignore. Part 2: There's a small Gotcha! When you rotate the device, the screen re-renders and your viewmodel gets destroyed & reinitialized. Not a problem though, Android gives you a solution for this, you just need your viewmodel to extend the androidx ViewModel class and it will persist the viewmodel's state during screen configuration changes for you. Part 3: So here's a common scenario where you're in a sub-component that doesn't know which activity is calling it. You'll need to do that in a specific Android way, but the android package for doing it isn't included by default so you'll need to update the gradle dependencies (that's the build.gradle (:app) one, not the other build.grade top-level file). Doing this (or maybe for reasons totally unrelated?) sometimes causes a "duplicate class" error message to appear that, thankfully someone has tracked as being an issue with the latest kotlin.android plugin (in build.gradle (:project)), so just downgrade to an older and more stable version of that; and for reasons only about 5 people understand you also need to update your composeOptions (build.gradle (:app)) to a newer version; and then your project builds again! But it's a hollow victory, because now you're left with this sense of unease and uncertainty over whether it will work as prescribed when you actually do try to implement it in a subcomponent instead of MainActivity; that maybe there's an edge case related to using this same component from different intents, or on different devices, or with different versions of Jetpack Compose or Android. Or that maybe this will break the project in the future; or that you'll be forced to continue using this older version of kotlin.android and miss out on future features. Your code works now, but the feeling of unease over your software will never leave now. And then also here's a common scenario where you might want to use constructor arguments for your Android-specific ViewModel that you are required to use. You'll need to create a whole ViewModel Factory from the ViewModelProvider and override the create method with your own way of creating ViewModels and then create the ViewModel using that; all that even if you only want one instance of your ViewModel. Some developers just put the entire Android project in a WebView. Anyway, you're a phenomenal teacher and this video explained things really well. Thank you for helping us navigate the eternally-changing landscape that is native Android development.
10:25 i just want to say out loud that the whole confusing configuration change hack since android OS 1.0 is a ridiculous hack and should have been addressed years ago What a sloppy mess
but it is addressed, it's just opt-in, you do it like that: (this is xamarin c# but you get the point) ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation. This way you say to Android "I will handle screen size changes and orientation changes myself". With those flags the whole activity re-creation won't happen on rotation, and it's especially nice when you use ConstraintLayout, the whole rotation of your app is smoother and ConstraintLayout re-calculates the view layout automatically View re-creation is there "because it was that way from the beginning", and it was that way because there was no ConstraintLayout for quite some time. Nowadays this is completely unnecessary, it only slows down app on rotation and it's one more thing that brings a lot of gotcha bugs. iOS doesn't recreate view on rotation, it just triggers AutoLayout and this is why rotation on iOS is smoother.
You are great! I learn so much from you and still improving myself. I have a small request from you, Please create a playlist/single video for MVVM architecture with Retrofit API call. Also please make this with Activity & XML (don't use Jetpack Compose).
Hi sir, thanks for your helpful series. But I got one more question about the differences between MVP and MVVM, can you help me figure it out. Thankyou
if model layer is exposing a list of objects with epoch time, is it good to convert all of them to new object by parsing them to corresponding strings?.. If I follow this approach, I would have 4 data classes that represents the same data: dto, entity, model that repository exposes and model that is parsed for the view. Should I follow this approach?
~15:00 the crash due to adding a parameter... this type of issue is why I am having so much difficulty learning how to use Android... half the time, there is no obvious reason why a crash occurs, and the log often gives the wrong line number... is there an easy way to debug such problems?
Hi, I never know how to import viewModel. Using by viewmodels() is the newest way? What os the best way to use viewModel with XML. Do you have tutorials?
Android's ViewModel is not a VM from MVVM. It's just a container which allow to survive configuration changes. Here is also what documentation stated: "The ViewModel class is a business logic or screen level state holder. " ... just a holder. I can implement MVP in my app and use ViewModel as a container for a Presenter in order to survive configuration changes.
Typically a ViewModel = 1 screen of your app. If you have multiple screens, you don't want to handle them all with a single ViewModel, because it makes your code unflexible, the ViewModel overly big, and violates single responsibility principle. It would also create lifescope problems (eg. imagine you have an email app, and there is a "general" view with a list of your emails, but also a "detail" view, where you navigate to read a specific email thread - now obviously the natural lifespan of the detailed screen is shorter than the lifespan of the main screen)
Ich habe gehört, dass Du ein Händchen dafür hast AndroidStudio super gut zu erklären. Aber warum auf englisch? Gibt’s da nicht schon jede Menge guter Video s? Ich deutsch dagegen sieht’s da schon viel schlimmer aus. Warum also nicht auf deutsch?? Die AutoÜbersetzung ist viel zu schnell und auch nicht immer genau. Vielen Dank fürs Verständnis. Andreas Blechschmidt
Weil ich in deutsch eben deutlich weniger Leute erreichen könnte in einer bereits kleinen Nische :) Viele andere größere aktive channels gibt's auf englisch auch nicht
bro sorry for interpart i really dont understand like view model and some many other so i want you suggestion .plz dont say life circle it only show me how is work i doent show what inside is do .plz i am lost
I do not know how anyone can learn Android coding without these videos, thank you so much.
You're making me learn compose in a mere couple of weeks. Why is noone else coming up with these essential videos? These solutions are so simple yet noone will mention them in a documentation
I dont like that he uses compose in each video. Sure it is nice if you want to learn it but I like when something is explained without much boilerplate. His older videos were more focused, idk. Nowadays he explains that subject but also 10 other :).
the tutorials from Google are also very good
I have learnt a lot of languages and watched a lot of videos but yours are next level, whatever I need you have a video and exactly at the level I need and perfectly explained.
Thank you!!
I really liked that you explained in such great detail. When you don't use Dagger-Hilt, everything becomes clearer despite the boilerplate code. I had a lot of memory leak issues with Context 🎉
Yeah i had the same its difficult to avoid Memory leaks if app context needed in ViewModel. But after i implemented Dagger Hilt, this Problem is practical non existent.
@@USS_Daedalus There are different approaches and sometimes you can work around using Context. However with injection it is much easier and I prefer Koin (KMP) instead Hilt (Android).
Is Google making all this unnecessarily complex? Newbie here
It's actually the opposite
Not necessarily Google but OOP is. Android development is the worst abstraction hell out there
It makes perfect sense to destroy an activity and forget everything whenever the screen rotates. Really forward thinking from Google.
Yes they are. Swift development was far easier for me.
@@saadahmed688 Real.
Please make a video on how to make usecases for a complex app having many features
This series is gonna be very useful
Thank you Philip. Btw love the random number guessing game at @13:30, real android development showcase. Also who at Google came up with that view model factory thing at @17:15 should be held accountable for his/her war crimes :)
User: turns the screen
Activity: nooo! I don't want to die!!!
Videos like this are necessary for developers in any level, sometime you need to know how a component really works and what its purpose is, in order to avoid bugs, performance issues and leaks.
Phillipp too good, i have gone thru your 4-5 videos and the way u explain is worth for people want to learn Jet Compose, keep it up.....
Thanks it really cleared my doubt i was confused but now its clear.
Thanks for your efforts and videos. Very helpful in studying and repetition. I have an interview tomorrow, hopefully I'll pass, hehehe
Native android development is so cool.
You're the goat i was having difficult in state management and your video clarify my mind, thanks
Philipp the 🐏 in Android tutorials 🔥
Kotlin, OOP, Android... the more I learn, the more I am completely stunned at how ludicroulsy complex it is... so many different ways to overcome the global vs local variable problem (aka client-server where do I put the code/data problem)... Synthetics, deprecated, no longer supported, then findViewById/binding, now Jetpack Compose... what next?
@CrankyLive So, I should switch from one difficult to work with Google product to a different Google product? Or are you being snarky?
thank you.. I was stuck and didnt know whats wrong,, turned out i needed to sync it..
Amazing explanation dear Philipp! 🤩
Great series! Maybe you could include things like - this could be asked in an android interview and share some trick questions :)
a big thanks to all your efforts one day i will surely become a great android developer only because of you ❤
It's a very clear and detailed explanation as usual. Thank you!
Perfectly explained, I have been struggling the idea of mvvm and how it works, but now WOW. Thanks man very appreciated.
Hi, Philipp! Thank you so much 🙏 I would like to ask you what is written on your T-shirt in this video? Thanks
Very clearly explained. Thank you very much
Sadly it isn't called VVMM (View ViewModel Model) or MVMV (Model ViewModel View). That order makes more sense regarding what part has contact with which part.
Perfect as usual, Philipp! I wish you a lot more subscribers! Keep sharing your knowledge please in a clear and understandable way! Danke😉
If I find my first job, I will donate you to show my love❤
Thank you Philipp for all your work. You are really an inspiration for me as Android Developer and I've learned so much thanks to you 😊
Thanks, you explain kotlin compose very well. There is little information at an advanced level in the Russian-speaking segment.
It's a cool explanation of MVVM, but what a pity I don't have enough money to buy your premium courses...
Perfect explanation, thanks Philipp
安卓现在的框架给我的感觉很庞杂，有时候不知从何入手。但是这个视频讲解了ViewModel是什么，怎样手动构造，这样只要懂基本的知识就能使用，拨开了框架的神秘面纱。
Great content 😁 thanks for making this !
In depth explanation thank you so much Philipp
I just want to thank you, I am learning a lot from your videos! Cheers!
Hello, which theme are you using, it looks very nice ?
14:15 Duplicate class error fix
17:15 Factory for view model parameters
Is this telling us we need to use ViewModel or just what it can be used for if we want to use it? Is it the only way to handle configuration changes or is it an alternative to APIs like rememberSaveable?
The deciding factor should be speed. If your project is simple enough, you can use rememberSaveable and it runs perfectly fine, you don't need much code either. If you have more complexity, it's better to use remember in combination with a viewmodel. Usually when it becomes too complex, you have a lot of logic functions regarding how you map your states. This is best done in a viewmodel to create the separation from the ui. This way the code is more flexible and less buggy. You can then update and save 100 specifically selected states in 1 small function according to a logic algorithm. Of course you would never reach this efficiency using rememberSaveable
@@nesletchimaew9209 Thanks! In some ways it's a tricky time to be an Android noob during the change from Views to Compose and picking up only bits and pieces of techniques and terminology from each with so much info referring to or expecting knowledge of earlier stuff. So far I've only done simple enough things to juse rememberSaveable but even then got lost with the list and mutable versions.
@@andrewdunbar828 it's very hard to find info on what you can do to make things easier. I use a wrapper class with a val value: T so that primitive data types can get put into the same class type. When I set a state for a boolean, i say val bs = States.VALUE.BOOLEAN(true). Then i make a map in the viewmodel for each data class i need to have access to in the UI. Then I put all of them i side another map, and make a new privatemap with mutable stateflows for all of them, and another public one using the mutable stateflows as regular stateflows. In the UI I then collect all of them as stateflows and then as states. The state in the UI will then be of the following type:
Map
If I have a States.VALUE and want to get the value, i have to read it like this: lets say i need a boolean, i go into the map and fetch the value like this:
val entry = map[someConstant][someOtherConstant]
i then read the state like this
val state: Boolean = (entry as States.VALUE.BOOLEAN).value
of course i have dozens of helper functions that do all of this with a few lines of code
Congratulations Philipp. A simple question, can I work with WorkManager inside the ViewModel class?
You can, but I'd keep them free of Android dependencies to make them locally unit testable
Can you make the video of viewmodal showing the datas and images from internet
which book did you use to learn this stuff ?
MVVM is a modification of MVI, the only difference being that MVVM is based on Data Binding. In the case of Compose, MVVM is some kind of MVI
This video is pretty much Android development in a nutshell.
Part 1: The motivation behind MVVM; how it just totally simplifies the process of making changes on the UI, and keeping it synced with the data model that's being represented. Easy to implement, easy to understand, there's a good deal of boilerplate but it's easy to ignore.
Part 2: There's a small Gotcha! When you rotate the device, the screen re-renders and your viewmodel gets destroyed & reinitialized. Not a problem though, Android gives you a solution for this, you just need your viewmodel to extend the androidx ViewModel class and it will persist the viewmodel's state during screen configuration changes for you.
Part 3: So here's a common scenario where you're in a sub-component that doesn't know which activity is calling it. You'll need to do that in a specific Android way, but the android package for doing it isn't included by default so you'll need to update the gradle dependencies (that's the build.gradle (:app) one, not the other build.grade top-level file). Doing this (or maybe for reasons totally unrelated?) sometimes causes a "duplicate class" error message to appear that, thankfully someone has tracked as being an issue with the latest kotlin.android plugin (in build.gradle (:project)), so just downgrade to an older and more stable version of that; and for reasons only about 5 people understand you also need to update your composeOptions (build.gradle (:app)) to a newer version; and then your project builds again! But it's a hollow victory, because now you're left with this sense of unease and uncertainty over whether it will work as prescribed when you actually do try to implement it in a subcomponent instead of MainActivity; that maybe there's an edge case related to using this same component from different intents, or on different devices, or with different versions of Jetpack Compose or Android. Or that maybe this will break the project in the future; or that you'll be forced to continue using this older version of kotlin.android and miss out on future features. Your code works now, but the feeling of unease over your software will never leave now.
And then also here's a common scenario where you might want to use constructor arguments for your Android-specific ViewModel that you are required to use. You'll need to create a whole ViewModel Factory from the ViewModelProvider and override the create method with your own way of creating ViewModels and then create the ViewModel using that; all that even if you only want one instance of your ViewModel.
Some developers just put the entire Android project in a WebView.
Anyway, you're a phenomenal teacher and this video explained things really well. Thank you for helping us navigate the eternally-changing landscape that is native Android development.
You're awesome man, thanks a lot.
Hi Philipp, Can You Also Make a Video About Repository And Data Classes? Would Be very Helpful
Those are both not really android specific concepts, but I might make one about repos on future
10:25 i just want to say out loud that the whole confusing configuration change hack since android OS 1.0 is a ridiculous hack and should have been addressed years ago
What a sloppy mess
but it is addressed, it's just opt-in, you do it like that: (this is xamarin c# but you get the point) ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation. This way you say to Android "I will handle screen size changes and orientation changes myself".
With those flags the whole activity re-creation won't happen on rotation, and it's especially nice when you use ConstraintLayout, the whole rotation of your app is smoother and ConstraintLayout re-calculates the view layout automatically
View re-creation is there "because it was that way from the beginning", and it was that way because there was no ConstraintLayout for quite some time.
Nowadays this is completely unnecessary, it only slows down app on rotation and it's one more thing that brings a lot of gotcha bugs.
iOS doesn't recreate view on rotation, it just triggers AutoLayout and this is why rotation on iOS is smoother.
You are great! I learn so much from you and still improving myself. I have a small request from you, Please create a playlist/single video for MVVM architecture with Retrofit API call. Also please make this with Activity & XML (don't use Jetpack Compose).
Hi sir, thanks for your helpful series. But I got one more question about the differences between MVP and MVVM, can you help me figure it out. Thankyou
Can you please explain the reason of getting dublicate class error? thanks
This man is soon to become the God of native android apps 🙂 Amazing content and best in the world
Thank you bro...was waiting on this to start using KMM...will this work for compose ios if I share the ui and the logics ?
Not like I showed here since you're dealing with an Android specific dependency, but there are ways to make it work
Hello, can you make a wideo with istalation of Android studio and show how to config it, and what emulator you use ?
In order to get data from Broacastreceiver to compose functions should we use this aproach?
Hi Philipp, could u share your theme settings plz?
1. What's the name of theme?
2. What's the name of fonts?
Thanks ahead :)
Theme: XCode-Dark
you are the best bro
sir, how to know that meetups are going on and how to join them and joining them is worth it ?
Thanks
Thx for this great video.
Hi! Is there any compose view for single row calendar view? With date highlight?
If yes, can you please help me to get reference
I saw the similar kind of requirements from philip lackner. But still, I could not find it anywhere
thx a lot for this basics video!
sehr schön 👍aka very nice
if model layer is exposing a list of objects with epoch time, is it good to convert all of them to new object by parsing them to corresponding strings?.. If I follow this approach, I would have 4 data classes that represents the same data: dto, entity, model that repository exposes and model that is parsed for the view. Should I follow this approach?
thanks for great content 🙏🙏❤ ,
I think this is similar to React virtual dom 😮
Hey! can you share your green wallpaper?
👌👌
thanks
What emulator do you use?
❤ good one
Why don't we use the Singleton Pattern instead of the view model
Awesome
i don't understand why not to make UI actions update the model itself and vice versa.
To separate different jobs and give each part a single responsibility
~15:00 the crash due to adding a parameter... this type of issue is why I am having so much difficulty learning how to use Android... half the time, there is no obvious reason why a crash occurs, and the log often gives the wrong line number... is there an easy way to debug such problems?
Hi, I never know how to import viewModel. Using by viewmodels() is the newest way? What os the best way to use viewModel with XML. Do you have tutorials?
by viewModels() for XML projects and the composable function for Compose projects
The GOAT ♥
Android's ViewModel is not a VM from MVVM. It's just a container which allow to survive configuration changes.
Here is also what documentation stated: "The ViewModel class is a business logic or screen level state holder. " ... just a holder.
I can implement MVP in my app and use ViewModel as a container for a Presenter in order to survive configuration changes.
cool bro
8:54
Should we use only one viewModel in whole app or create different viewModels for different purposes?
Typically a ViewModel = 1 screen of your app.
If you have multiple screens, you don't want to handle them all with a single ViewModel, because it makes your code unflexible, the ViewModel overly big, and violates single responsibility principle. It would also create lifescope problems (eg. imagine you have an email app, and there is a "general" view with a list of your emails, but also a "detail" view, where you navigate to read a specific email thread - now obviously the natural lifespan of the detailed screen is shorter than the lifespan of the main screen)
Ich habe gehört, dass Du ein Händchen dafür hast AndroidStudio super gut zu erklären. Aber warum auf englisch? Gibt’s da nicht schon jede Menge guter Video s? Ich deutsch dagegen sieht’s da schon viel schlimmer aus. Warum also nicht auf deutsch?? Die AutoÜbersetzung ist viel zu schnell und auch nicht immer genau.
Vielen Dank fürs Verständnis.
Andreas Blechschmidt
Weil ich in deutsch eben deutlich weniger Leute erreichen könnte in einer bereits kleinen Nische :)
Viele andere größere aktive channels gibt's auf englisch auch nicht
waiting for 123K
Davis Kenneth Perez William White Kevin
bro sorry for interpart i really dont understand like view model and some many other so i want you suggestion .plz dont say life circle it only show me how is work i doent show what inside is do .plz i am lost
Was es aussieht Was es aussieht parAmeter parAmeter
Can MVVM be done with Java or must it be Kotlin!?