Hi Mitch, thanks for all your videos, your videos have helped me to learn a lot. It would be nice to have like part 2 of the video, after 2 years (2022) of jetpack Compose, what should be the best architecture for jetpack compose for mitch. would it be the same as 2020 or what has changed in 2 years that may force changes for a better architecture?
This is only an issue because they are giving the ui layer way too much responsibility. Should make a pure kotlin class, mine is named AppManager, that is the business logic equivalent of MainActivity. AppManager is responsible for receiving all navigation requests from the view models (not the screen) and in turn creates instances of view models and stores them in a dictionary keyed by a Guid. Guid gets passed on to the screen in ui layer and screen calls AppManager.FindViewModel(Guid) which returns view model instance. Also really important to pass data parameters between view models NOT between screens ( again that makes ui too smart and screens become tightly coupled). Only parameter screens should ever receive is the Guid. First built a small framework to support this using kotlin back in 2015 and again just last year in xamarin and it works great. Also must abstract out navigation methods so that AppManager marshals navigation requests from view models to the related ui framework I.e. compose. Gotta keep that ui layer dumb as possible. UI should be responsible for “how” to navigate while view models are responsible for when, where and why to navigate and for providing data needed for the destination of that navigation request.
This makes me so happy. Such a beautiful, simple way of building. Very well explained. I can't wait to see the follow up video to this one in December 2021 when there is more progress on solving these problems.
Not so simple when you descend into any of those composable functions in NavController.kt or Navigator.kt. So much complexity to solve so simple a problem, it just looks like academics in ivory tower showing off to me, at the cost of bloating and slowing down your apps.
They have a lot of things to do before releasing Compose for production projects. Integrating compose in current projects is confusing, because it still has so many limitations, but on the other hand, I am super excited to see how it will look like when the stable version gets released. I think they just, gave us a sneak peek to get us used to this paradigm shift, because developing android apps using Kotlin is going to be so much different.
@@SphereCore I totally agree with you. I can't wait to build apps 100 % using compose, I feel as excited as when I wrote my first line of code using kotlin. If you are using compose for a while now, you can see how much they are willing to adapt it for developers. i.e. you could align elements in a Row or Column using gravity, but since it was confusing for developers and we asked them to change it to horizontalAlignment and verticalAlignment and they did. For them it might look like a no big deal, but it means a lot to us developers, knowing that our words are being listened to.
They need to show using side to side comparison of two exactly same functioning apps, this many lines/kb of code was needed without Compose (w/ Kotlin+viewbinding), now this many lines of code is needed with Compose. I BET THEY CANNOT REDUCE THE AMOUNT OF CODE.
I'm React Native developer and i will learn android native just because of jetpack compose. In many moments, i think that android still sucks by difficulty and the architecture. But I will give a lot of my experience in React Native deep in Android.
I'm fine with passing in my view model and my nav controller my top level composables will only ever need this two things and I'll handle it when developing my routes
As I've read somewhere, the lifecycle legacy and recreating the entities after rotation is conditioned by the quiet simple thing: the hardware limitations when Android was in development. It was a time when phone had like 128 - 256 mb RAM, slow processors and so on. The problem with hardware has gone relativelty fast, but now we have to take in account the solutions for 128 mb RAM devices till the rest of our lives.
Hi Mitch. Thanks a lot for the videos. You pointed out the most pain of every android developer. Really, why do we need lifecycles? Why activities, fragments should be destroyed and recreated? Why the android team develops a new tool that brings more questions... Why in Navigation fragments are replaced instead of been added to the top. It seems like the android team loves to make challenges for us...
Activities are destroyed on rotation(or any config changes) to give us flexibility to recreate them in different configurations (for example different layouts/dimens/themes for landscape/portrait). If you don't need that flexibility you can get rid of that and specify android:configChanges="orientation/screenSize" in that case your layout will be remeasured and relayouted without recreating its hierarchy (but it is much better to do it with ViewModel's). If it comes to activites being destroyed and recreated while navigating back and forth that is whole different story. It is done this way because before we couldn't afford keeping multiple activites/layout hierarchies in phones memory at the same time. Now we dont need to worry about that precious memory that much as most of the modern phones have more ram than the latest macbook air. But still modern apps tend to waste so much memory that even with 12GB ram you cannot keep 4 complex app open in the background at the same moment - welcome to a fairy tale.
View model is not persisting data because it can be destroyed when you run out of ram or it’ll been a long time when it’s in pause state. If you are expecting view model to store data it’s really dangerous. It can only outlive the screen rotation. But there are cases when it’s killed and then Android is trying to recreate the state and the data is not there. When they announced viewmodel I was hoping it would resolve this issue but what a disgrace it’s not doing what I wanted it to be. I tried also iOS developments there are a lot things that have been taking care of by iOS which we need to implement in android.
@@codingwithmitch i know how to handle it in different ways, but why should i care about it. there is no such thing in ios. also you should consider that instant state is limited by size 1MB. why should i use some hard storage like db, if i want to store it in RAM. Why android is not restarting the app in case of process death ? just do it as ios - restart the app, and a lot pain in the ass would go away. Also, you know ROOM is not giving you the solution for encryption, you should care about it by yourself. I can take easily the room db files from potential target and i can steal the information.
What about the 1000 line per class rule? If you start putting all the layout-code into kotlin classes they quickly will become bigger than 1000 lines of code. I have an app of mine in mind and if I would transfer the layout stuff to compone I think the class(es) would easily become over 2000 lines of code.
I didn't look at it intimately but yep looks like in general that's how I think it should be done. Same as my repo github.com/mitchtabian/MVVMRecipeApp
Great video loved the use of diagrams it makes things a lot clear and stays in the head longer 😀 And the shout out at the end lol 😆 it sounds like "Na-jam" and last name is like sounded like "Shh-Aikkh' But good try thanks for your videos always very helpful 👍
According to developer.android.com/jetpack/androidx/releases/navigation#compose-1.0.0-alpha01 viewModels can already be scoped to composable screens, although I'm wondering how should we provide them? I guess injecting vm for every screen in single activity and then passing it to each destinstion screen as param would be silly. May we could use some ServiceLocator like getIt in Flutter? What do you think?
Hey Mitch. Love your videos. Could you explain what you mean by "you have no way to tie a ViewModel to a Composable"? For example, I am sure you have seen "Compose and ViewModels" (developer.android.com/codelabs/jetpack-compose-state#3) where we have code such as @Composable private fun TodoActivityScreen(todoViewModel: TodoViewModel) { TodoScreen( items = todoViewModel.todoItems, onAddItem = todoViewModel::addItem, onRemoveItem = todoViewModel::removeItem ) } Compose seems very promising but it is certainly not easy to pick up.
In the example you posted all your doing is passing the viewmodel as a constructor argument. To solve the problems I talk about in this video the viewmodel would need to be instantiated inside a particular composable and maintain the same instance across config changes and process death. Currently that is not possible. But if you architect your apps the way I talk about in this video (one fragment per screen, one viewmodel per fragment) you can maintain the viewmodel instance and pass as a constructor argument to the composables.
Hi, Many thanks for this video. since 2020 the jetpack compose has changed let's say a lot. based on the google documentations, the recommended approach for navigation is using compose navigation which removes all fragments and have just some bunch of screen. but I have problem with viewModel and compose. I mean let say I removed all my fragment and instead, have a screen for each one. what about the my view models? should I merge all of my view model in just one ( which is attached to my single activity?) or ...what?
Hi Mitch, thanks for all your work on the videos, very helpful! I just started to develop with Compose and your approach is very interesting but I don't know if I get it completely, You are saying to use activities and fragments as we do today with all the problems you mentioned (lifecycle and all) but with Composables instead of the xml. If so, why using compose in the first place? We just gonna end up dealing with the same old problems of activities and fragments plus the problems compose will expose in the future. What do you think?
Hello Mitch! What do you think about one time events (SingleLiveEvent in LiveData) emitted from ViewModel in the Compose paradigm? I faced a dilemma of how to work with 'old' Views inside Composable which require one-time operations to operate properly and in a performant way. Example: I have a screen with a MapView (I use ArcGis SDK) component inside Composable using AndroidView interoperability mechanism. The goal is to show icons (tracks) on the map as the info about them received in realtime. The most performant way to work with MapView is to load the current state of icons (as State) and subscribe for individual icon updates from a server (SingleLiveEvent). I can't just update ALL icons on MapView every time some single icon changes its position, because it causes computing (forming) every icon again and that's a quite heavy operation. I can't incorporate this scenario in the Composable paradigm AS-IS, because there is no way to receive and react to one-time events inside composable. Instead, I have to create MapView outside composable to work with it as earlier using viewModel.observe (receiving one-time events) mechanism and pass it later as a parameter to Composable function. So, in my opinion, what Compose is missing is Event primitive - analog of State but designed for one-time events, for interoperability with 'old' Views.
Something similar to the one-time event can be achieved using onCommit() function inside Composable, but it causes triggering of the last emitted event again after recomposing the whole component (in case of screen rotation for example).
I've used this setup (Jetpack Compose inside Fragments) and couldn't find any resources on how to test this setup, mainly.. the data & event flow between ViewModel, Fragment and Composable. Are you planning to do any Video on testing Jetpack Compose ?
I did unit testing in the advanced jetpack compose course but no UI testing. I left out the ui tests becasue in the docs it says the testing APIs are unstable and will likely change. codingwithmitch.com/courses/food2fork-recipe-app/
is there any bug in android studio canary 4.2? cause whenever i make changes in jetpack compose app i need to uninstall the app and then have to install it again in order to see changes. I'm not able to see changes after running app or instant run feature.
Do you know anything about Telegram app(most popular and secure messenger in russian community) ? you can find their source code online. They decided to go View-based screens. very interesting how they handle the screen rotation with such approach and restore state
hey mitch, I know this might not be the best feedback, but the Instagram clone series that you made had almost a 100 videos and the end product still did not have that great of a UI it seemed, I watched like 10 videos and all I saw was you doing the appbar and bottomNavBar so I just bailed out. Do you think if you could use compose at that time, then the number of tutorials would have reduced? And also, that android bodybuilder guy in your cover, is that free to use by me or do you have some kinda copyright on that?
It would be nice to cover this also. Fragments are one way of navigation, jetpack compose also has its own navigation for those who want pure compose functions
I wish you could update us if Jetpack Compose already solve those problems you mention in a video like this :D
Hi Mitch, thanks for all your videos, your videos have helped me to learn a lot. It would be nice to have like part 2 of the video, after 2 years (2022) of jetpack Compose, what should be the best architecture for jetpack compose for mitch. would it be the same as 2020 or what has changed in 2 years that may force changes for a better architecture?
This video still engaging 3 month later 😁Thanks!
Nice work Mitch, your online youtube lectures really helps me to keep myself updated with the latest technology with android development. Thank you
This is only an issue because they are giving the ui layer way too much responsibility. Should make a pure kotlin class, mine is named AppManager, that is the business logic equivalent of MainActivity. AppManager is responsible for receiving all navigation requests from the view models (not the screen) and in turn creates instances of view models and stores them in a dictionary keyed by a Guid. Guid gets passed on to the screen in ui layer and screen calls AppManager.FindViewModel(Guid) which returns view model instance. Also really important to pass data parameters between view models NOT between screens ( again that makes ui too smart and screens become tightly coupled). Only parameter screens should ever receive is the Guid. First built a small framework to support this using kotlin back in 2015 and again just last year in xamarin and it works great. Also must abstract out navigation methods so that AppManager marshals navigation requests from view models to the related ui framework I.e. compose. Gotta keep that ui layer dumb as possible. UI should be responsible for “how” to navigate while view models are responsible for when, where and why to navigate and for providing data needed for the destination of that navigation request.
This makes me so happy. Such a beautiful, simple way of building. Very well explained. I can't wait to see the follow up video to this one in December 2021 when there is more progress on solving these problems.
Not so simple when you descend into any of those composable functions in NavController.kt or Navigator.kt. So much complexity to solve so simple a problem, it just looks like academics in ivory tower showing off to me, at the cost of bloating and slowing down your apps.
They have a lot of things to do before releasing Compose for production projects. Integrating compose in current projects is confusing, because it still has so many limitations, but on the other hand, I am super excited to see how it will look like when the stable version gets released. I think they just, gave us a sneak peek to get us used to this paradigm shift, because developing android apps using Kotlin is going to be so much different.
It's still incomplete. But you can already do 90-95% of things and from what i can tell compose is really great
@@SphereCore I totally agree with you. I can't wait to build apps 100 % using compose, I feel as excited as when I wrote my first line of code using kotlin. If you are using compose for a while now, you can see how much they are willing to adapt it for developers. i.e. you could align elements in a Row or Column using gravity, but since it was confusing for developers and we asked them to change it to horizontalAlignment and verticalAlignment and they did. For them it might look like a no big deal, but it means a lot to us developers, knowing that our words are being listened to.
They need to show using side to side comparison of two exactly same functioning apps, this many lines/kb of code was needed without Compose (w/ Kotlin+viewbinding), now this many lines of code is needed with Compose. I BET THEY CANNOT REDUCE THE AMOUNT OF CODE.
@@ZhihengCao I’m seeing that at some point in the near future they make compose visual editor which would really be awesome
I'm React Native developer and i will learn android native just because of jetpack compose. In many moments, i think that android still sucks by difficulty and the architecture. But I will give a lot of my experience in React Native deep in Android.
Hi Mitch!! Do we have any update on how to manage state in compose?
I'm fine with passing in my view model and my nav controller my top level composables will only ever need this two things and I'll handle it when developing my routes
Could you update this video for 2022 if things have changed.
As I've read somewhere, the lifecycle legacy and recreating the entities after rotation is conditioned by the quiet simple thing: the hardware limitations when Android was in development. It was a time when phone had like 128 - 256 mb RAM, slow processors and so on. The problem with hardware has gone relativelty fast, but now we have to take in account the solutions for 128 mb RAM devices till the rest of our lives.
Thanks, Mitch,
Please make a new video talking about Jetpack compose 2021 after releasing the stable version.
Commenting ENGAGEMENT even before watching the video. 😁 ✌️ Pretty sure the video is very good as always 100%
Nice engagement
Ah a man from the Future ... Tell us your wisdom
@@prashantsurti5788 Aliens are real 😹
Hey Mitch, do you think this video is still relevant in May 2021?
Nice Sermon Pastor Mitch - hope Google are tuning in!
Now What's the Status of all the issues about jetpack you just mentioned. I guess dependency injection is a solved problem
Thanks man this was great video , also another question ! , what will be a better architecture now with jetpack compose in 2022 ?!
Nice video Mitch, now I am more convinced to use Jetpack Compose :)
Hi Mitch. Thanks a lot for the videos.
You pointed out the most pain of every android developer. Really, why do we need lifecycles? Why activities, fragments should be destroyed and recreated? Why the android team develops a new tool that brings more questions... Why in Navigation fragments are replaced instead of been added to the top. It seems like the android team loves to make challenges for us...
Activities are destroyed on rotation(or any config changes) to give us flexibility to recreate them in different configurations (for example different layouts/dimens/themes for landscape/portrait). If you don't need that flexibility you can get rid of that and specify android:configChanges="orientation/screenSize" in that case your layout will be remeasured and relayouted without recreating its hierarchy (but it is much better to do it with ViewModel's).
If it comes to activites being destroyed and recreated while navigating back and forth that is whole different story. It is done this way because before we couldn't afford keeping multiple activites/layout hierarchies in phones memory at the same time. Now we dont need to worry about that precious memory that much as most of the modern phones have more ram than the latest macbook air. But still modern apps tend to waste so much memory that even with 12GB ram you cannot keep 4 complex app open in the background at the same moment - welcome to a fairy tale.
View model is not persisting data because it can be destroyed when you run out of ram or it’ll been a long time when it’s in pause state. If you are expecting view model to store data it’s really dangerous. It can only outlive the screen rotation. But there are cases when it’s killed and then Android is trying to recreate the state and the data is not there. When they announced viewmodel I was hoping it would resolve this issue but what a disgrace it’s not doing what I wanted it to be. I tried also iOS developments there are a lot things that have been taking care of by iOS which we need to implement in android.
Yeah so you are talking about process death. You need to save to instance state to handle that
@@codingwithmitch i know how to handle it in different ways, but why should i care about it. there is no such thing in ios. also you should consider that instant state is limited by size 1MB. why should i use some hard storage like db, if i want to store it in RAM. Why android is not restarting the app in case of process death ? just do it as ios - restart the app, and a lot pain in the ass would go away. Also, you know ROOM is not giving you the solution for encryption, you should care about it by yourself. I can take easily the room db files from potential target and i can steal the information.
Great video. Solved many of my question about the recommended compose architecture
plz make video on sync adapter with roomdatabase
What about the 1000 line per class rule? If you start putting all the layout-code into kotlin classes they quickly will become bigger than 1000 lines of code. I have an app of mine in mind and if I would transfer the layout stuff to compone I think the class(es) would easily become over 2000 lines of code.
Abstract out composables you reuse
Don't view models get scoped to composables using compose navigation, or is that one of those things that changed?
Great talk!
In your proposal, you mentioned Fragments as the host of Composables, what if we omit that and each screen be a Composable itself?
Yep you can do that. I show you how in the advanced course codingwithmitch.com/courses/food2fork-recipe-app/
take a look at the jetpack survey sample.
I didn't look at it intimately but yep looks like in general that's how I think it should be done. Same as my repo github.com/mitchtabian/MVVMRecipeApp
@@codingwithmitch yup that is I want to say, they did same as you did, you great Mitch
Great video loved the use of diagrams it makes things a lot clear and stays in the head longer 😀
And the shout out at the end lol 😆 it sounds like "Na-jam" and last name is like sounded like "Shh-Aikkh'
But good try thanks for your videos always very helpful 👍
According to developer.android.com/jetpack/androidx/releases/navigation#compose-1.0.0-alpha01 viewModels can already be scoped to composable screens, although I'm wondering how should we provide them? I guess injecting vm for every screen in single activity and then passing it to each destinstion screen as param would be silly. May we could use some ServiceLocator like getIt in Flutter? What do you think?
Great as always!
Hey Mitch. Love your videos. Could you explain what you mean by "you have no way to tie a ViewModel to a Composable"? For example, I am sure you have seen "Compose and ViewModels" (developer.android.com/codelabs/jetpack-compose-state#3) where we have code such as
@Composable
private fun TodoActivityScreen(todoViewModel: TodoViewModel) {
TodoScreen(
items = todoViewModel.todoItems,
onAddItem = todoViewModel::addItem,
onRemoveItem = todoViewModel::removeItem
)
}
Compose seems very promising but it is certainly not easy to pick up.
I would really like to know the answer to this as well. As of right now, I am having a tough time to decide how to proceed with the app architecture.
In the example you posted all your doing is passing the viewmodel as a constructor argument. To solve the problems I talk about in this video the viewmodel would need to be instantiated inside a particular composable and maintain the same instance across config changes and process death. Currently that is not possible.
But if you architect your apps the way I talk about in this video (one fragment per screen, one viewmodel per fragment) you can maintain the viewmodel instance and pass as a constructor argument to the composables.
Hi, Many thanks for this video. since 2020 the jetpack compose has changed let's say a lot. based on the google documentations, the recommended approach for navigation is using compose navigation which removes all fragments and have just some bunch of screen. but I have problem with viewModel and compose. I mean let say I removed all my fragment and instead, have a screen for each one. what about the my view models? should I merge all of my view model in just one ( which is attached to my single activity?) or ...what?
Hi Mitch, thanks for all your work on the videos, very helpful!
I just started to develop with Compose and your approach is very interesting but I don't know if I get it completely,
You are saying to use activities and fragments as we do today with all the problems you mentioned (lifecycle and all) but with Composables instead of the xml. If so, why using compose in the first place? We just gonna end up dealing with the same old problems of activities and fragments plus the problems compose will expose in the future. What do you think?
Fu***** awesome thoughts bout the biggest problem in android development, man... Why you're so smart....
Im not agree jetpack compose, why, because it's same writting flutter . So can't different native or crossplatform 🤔
Anyone in may 2021
Any update regard this jetpack compose
Video
Particularly now it's in beta
Any improvemen?
Thank you so much mitch, you saved my ass 😂.
I got the clarity now
Hello Mitch! What do you think about one time events (SingleLiveEvent in LiveData) emitted from ViewModel in the Compose paradigm?
I faced a dilemma of how to work with 'old' Views inside Composable which require one-time operations to operate properly and in a performant way.
Example:
I have a screen with a MapView (I use ArcGis SDK) component inside Composable using AndroidView interoperability mechanism. The goal is to show icons (tracks) on the map as the info about them received in realtime. The most performant way to work with MapView is to load the current state of icons (as State) and subscribe for individual icon updates from a server (SingleLiveEvent). I can't just update ALL icons on MapView every time some single icon changes its position, because it causes computing (forming) every icon again and that's a quite heavy operation.
I can't incorporate this scenario in the Composable paradigm AS-IS, because there is no way to receive and react to one-time events inside composable.
Instead, I have to create MapView outside composable to work with it as earlier using viewModel.observe (receiving one-time events) mechanism and pass it later as a parameter to Composable function.
So, in my opinion, what Compose is missing is Event primitive - analog of State but designed for one-time events, for interoperability with 'old' Views.
Something similar to the one-time event can be achieved using onCommit() function inside Composable, but it causes triggering of the last emitted event again after recomposing the whole component (in case of screen rotation for example).
wow, Mitch with a beard, how long have i been in coma?
Took me about 1.5 months to grow that
nice beard
respect +1
I think compose is giving me the urge to try out Flutter
Flutter will be March this year 😁
Nice explanation to start. Thanks, Mitch.
Django or ktor which is best for building rest API
I've used this setup (Jetpack Compose inside Fragments) and couldn't find any resources on how to test this setup, mainly.. the data & event flow between ViewModel, Fragment and Composable. Are you planning to do any Video on testing Jetpack Compose ?
I did unit testing in the advanced jetpack compose course but no UI testing. I left out the ui tests becasue in the docs it says the testing APIs are unstable and will likely change. codingwithmitch.com/courses/food2fork-recipe-app/
does jetpack compose support view model these days 2021 ending?
ok so did this issue get resolved or is this still the best way out there ?
Thanks one more time Mitch for your engagement.
Hey Mitch ! Are there any updates on this ?
Thanks!
Its 2023
Has jetpack compose solved problems which you have mentioned?
Excellent video, thanks Mitch
is there any bug in android studio canary 4.2? cause whenever i make changes in jetpack compose app i need to uninstall the app and then have to install it again in order to see changes. I'm not able to see changes after running app or instant run feature.
this is heck of an engagement :D
Another great engaging video, thanks!
Thanks :)
Why use Navigation instead of a ViewPager? Any advantages/disadvantages? Thoughts?
Compose has its own pagers. Why use ViewPager?
Just curious about Google's fuchsia, is it going to replace everything?
who knows
Interesting stuff to think about! 👍
How do you know all this ?
Great knowledge
Hey mitch...this is my first engagement
Thx for the explanation
Do you know anything about Telegram app(most popular and secure messenger in russian community) ? you can find their source code online. They decided to go View-based screens. very interesting how they handle the screen rotation with such approach and restore state
No but that sounds cool
hey mitch, I know this might not be the best feedback, but the Instagram clone series that you made had almost a 100 videos and the end product still did not have that great of a UI it seemed, I watched like 10 videos and all I saw was you doing the appbar and bottomNavBar so I just bailed out. Do you think if you could use compose at that time, then the number of tutorials would have reduced? And also, that android bodybuilder guy in your cover, is that free to use by me or do you have some kinda copyright on that?
The instagram videos are garbage. Don't watch that at all.
The Android bodybuilder guy? That is my logo.
@@codingwithmitch lol you're so honest, i didn't wanna say trash directly though 😂
@@mehulbisht9708 It is absolute complete garbage and I want to remove it from youtube. But lots of people tell me not to so I don't
awesome! many thanks
Hey TH-cam, this video is very ENGANGEMENT!
ENGAGEMENT: This video hands down has the most beautiful diagrams.
What's your favorite Android app you've made and why?
Thank you Mitch!!!
we need an update !
Thank you Mitch!
Love you man
Does not sound like a very ripe system. Using 100% « composables » does probably not yield a very readable code anyay.
Are you secretly EliasVFishing ?
i like the architecture , still engaging though
'Doopa doop-pa doo' - talking my language!
The structure of the code is very similar to the flutter, isn't it better to go on the flutter instead of kotlin?
flutter and kotlin are made for different purposes
@@ferdiangunawan3265 Please explain the difference
Nice!!
Gratest of the gratests
It would be nice to cover this also. Fragments are one way of navigation, jetpack compose also has its own navigation for those who want pure compose functions
Watch the video. I don't think all composables is the way to go right now
Alright
It just feels great knowing you are bringing useful information to the masses, Job well done
Thx
great
Das undt engagermentunheight
We all waiting for fushia /s
💍
haha no one has given me that kind of engagement yet
ENGAGEMENT HERE
engagment++
Second
ike
ENGAGED
Compose has its own navigation component
Ya I talk about that
+1