I was really happy to share a lot of the best practices around activities, Fragments, Navigation, and most importantly *making your code testable*. Thanks for watching!
One of the best talk for sure. Handling activities navigations it's always a pain. Cant wait to see the progress to the final Navigation component. Thank you 😊
Is there maybe a tiny sample for trying it? Also, suppose we already have a huge app, with many activities, do you suggest to do the switch to this type? It doesn't seem like it has a lot of advantages...
But i dont understand why Android frameworks are very complex even after 10 years of Android. Lot of libraries,I have go through the testing document, I cant understand which library I need to add, which one I need to leave. Lot of confusions. Is it any consolidated document to start unit testing in my fresh project. Also I have a new library called Truth for assertions. Why not Google combine these under single roof? It looks like options for lot of developers but again Google going into fragmentation issues without any control of their developers.
One of the best videos so far of the Android Dev Summit '18. And probably the best speaker so far too. Clear, concise, to the point and relaxed. Very easy to follow and really well explained. Thanks Ian!!
I LOVE YOUR VIDEOS! THEY HAVE HELPED SO MUCH! Even your videos teach Multi-Activity Development. I don't understand Single Activity Development. Using Fragments seems too much like a delicate balancing act. It also seems like double the code without the flexibility and customization.
@@blockbusterlatefees7713 Thank you very much! I saw your comment just now. I'm planning to make a tutorial on Navigation Component with single activity architecture
Have been using single activity pattern for a while (4 years or so). Banner ads can perform uninterrupted and register more impressions when a single activity pattern is employed.
hello sir, i'm still a beginner on android development and i want to ask you something, in Single Activity Architecture, how you can hide the Bottom Navigation Bar on Child Fragments?
I'm pretty sure I'm fed up with Android. Been with it since 2009, but I think it's getting to a point where a lot of what I've spent years mastering are getting reworked, and I don't want to go through the struggles of mastering all this new stuff again. Not to mention all the new "gotcha's" that are going to come along with all these new APIs (remember when fragments came along?). Plus, while I'm busy as hell at work, on what do I spend the 30-45 minutes in the day to learn, Kotlin or Flutter? You've been good and bad to me, Google. Maybe it's time we spend some time apart.
Hopefully, the things that are being reworked are being reworked because they were difficult to work with and required a lot of workarounds and arcane knowledge that is just no longer needed. As an example, compare the navigate call at 12:08 with the FragmentTransaction code you would have had to write (not to mention things like animations, etc. that can be baked into that call automatically). Sometimes times the best code to write is no code at all and I feel like the higher level libraries available today mean you get to spend a lot more time working on the actual unique business logic of your app than the boilerplate that dominated apps in 2009. Work smarter rather than harder eh? That's not to mention the super open development process of all of the AndroidX libraries (all in AOSP, public bugs on the issue tracker such as issuetracker.google.com/issues?q=componentid:409828) that means even if you do encounter a problem, you have a good chance of getting an engineer to look at your issue and actually just fix it for everyone.
Flutter looks great and have a lot of hype, Alibaba have rebuild their app with Flutter and its still such a new framework. I think that it has a lot of potential and it performs well for animations. You are also targeting both android and ios.
Did the old APIs quit working? If you've mastered the old APIs, seems like you are good to go. You don't even need to watch this video if you have mastered the old APIs. ;-)
I'm afraid that unless you specialise in some legacy technology like Cobol, no matter what you do in IT you'll need to constantly learn some new stuff and approaches
Great talk! Can we find some sample app to get an idea of how all the pieces fit together? Sometimes I got lost with the code examples so having a little app to experiment with would greatly help me.
Its good practice to use two navigation(in two deferents activities ) in same app ? example : one navigation for (register ,login) and second navigation for (navigation drawer) ?
haha, I guess, it makes sense to do this way, so I am also gonna do this only, 2 activities, in total. Did you find any other approach, please let us know :P
Like I said at the end, don't contort yourself if it doesn't make sense. Moving each Activity one at a time to Navigation until each is just an empty shell of an Activity makes it a lot easier to later combine the graphs and collapse multiple Activities into one without it being a 'big bang' kind of approach. Updating the Migrating to Navigation guide to call out the steps to make that transition is definitely something we're working on - feel free to star the feature request to track progress: issuetracker.google.com/issues/119646049
What about destroying invisible activities and recreating them when user navigates back to it in order to save memory and resources? Did we stopped to care about that and expect phone manufactures to put more RAM in phones than we used to have in our computers?
thanks for effort. As a feedback: As usual, it turned another Google presentation focused nothing. Atleast, as a developer I was expected to hear in depth about navigation.
Yep, for a lot of seasoned developers, none of this should be a surprise, although we did talk about FragmentScenario and FragmentFactory which were literally just released and help considerably towards not just making a Single Activity structure work, but also make it testable. If you want in depth talks on Navigation, I'd suggest the I/O 2018 talk and the Droidcon NYC 2018 talk: th-cam.com/video/ST2W1Y_Ztvk/w-d-xo.html
Very nice, but what's happens when you have a app where some screens have a navbar or drawer and some screens do not? Can you really do the same with one activity
How does this work with when you have app that supports phones and tablet. For example a master detail view on tablet?. In tablet we don't add or replace the fragment as master and detail fragment are side by side. Different navigation graph for phones and tablets??
You can have two layouts in your Single Activity on your res/layout-large variant and from the Activity react upon your current screen size which is also easy to determine with a res/values large variant
I talked about this in some detail in this reddit AMA: www.reddit.com/r/androiddev/comments/8xspo7/were_on_the_engineering_team_for_android_p_ask_us/e2ojrwn/ - basically, due to free-form multi-window being available on Chrome OS devices, you should focus on *every* screen of your app being responsive rather than making huge changes like switching to master/detail. We're working on making that more officially part of our documentation - you can star the feature request for updates on that: issuetracker.google.com/issues/79668915
Codelabs are super helpful, yep! We have both a Navigation codelab at codelabs.developers.google.com/codelabs/android-navigation/ and a codelab about responsive Android apps which I think fits well with a single activity structure: codelabs.developers.google.com/codelabs/chromeos-resizing/
For a real world app that has many screens to follow the Single Activity approach, I can think of two possible scenarios. First, a single ViewModel is used and shared by all destinations. This single ViewModel is going to be bloated and not scalable. For this reason, I think the first approach is not suitable for real world development. Second, multiple ViewModels are used. (Not necessary one ViewModel per destination but would be close.) Given the lifecycle of a ViewModel is tied to the lifecycle of the (single) Activity, how is a "cold" (instantiated by no longer needed) ViewModel going to be released?
IIRC Memory management was one of the reasons they used to consider single-Activity as an anti-pattern for all but the simplest apps (or games & native apps, which were ostensibly doing their own memory-management anyway).
" Given the lifecycle of a ViewModel is tied to the lifecycle of the (single) Activity" Where did you read that? ViewModels are life cycle aware of any LifeCycle owner. Fragments are LifeCycle owners as well
After all this time, have you found a solution? Maybe we can talk about it.Time has passed so long, have you found the corresponding solution? Maybe we can talk about it.
@@Zhuinden That's what I was thinking. Alot of whats coming out of android team seems to be targeted at making devs more lazy instead of giving them real new tools. It's not that freaking hard to do transactions
@@nickadams2361 i've been using and updating simple-stack and open-sourcing some then-internal components for simple-stack since writing this comment, you can always check what that's like over defining NavGraphs and Actions and generating code
Yep, if you're using multiple activities, there's definitely some gotchas as described in medium.com/google-developers/navigation-patterns-with-pip-2c5b6a446ba0 - a lot of these are significantly minimized if you are using a single activity since that avoids any noticeable effects of the task change that occurs when entering picture in picture mode.
I was really happy to share a lot of the best practices around activities, Fragments, Navigation, and most importantly *making your code testable*. Thanks for watching!
One of the best talk for sure. Handling activities navigations it's always a pain. Cant wait to see the progress to the final Navigation component. Thank you 😊
The best talk for sure. I'm using the navigation component and it is very good. Thank you !
Is there maybe a tiny sample for trying it?
Also, suppose we already have a huge app, with many activities, do you suggest to do the switch to this type?
It doesn't seem like it has a lot of advantages...
thanks a lot for providing examples also in documentLaunchMode section
But i dont understand why Android frameworks are very complex even after 10 years of Android. Lot of libraries,I have go through the testing document, I cant understand which library I need to add, which one I need to leave. Lot of confusions. Is it any consolidated document to start unit testing in my fresh project. Also I have a new library called Truth for assertions. Why not Google combine these under single roof? It looks like options for lot of developers but again Google going into fragmentation issues without any control of their developers.
One of the best videos so far of the Android Dev Summit '18. And probably the best speaker so far too. Clear, concise, to the point and relaxed. Very easy to follow and really well explained. Thanks Ian!!
Thanks for the kind words!
MAGICAL~
I LOVE YOUR VIDEOS! THEY HAVE HELPED SO MUCH!
Even your videos teach Multi-Activity Development. I don't understand Single Activity Development. Using Fragments seems too much like a delicate balancing act. It also seems like double the code without the flexibility and customization.
@@blockbusterlatefees7713 Thank you very much! I saw your comment just now. I'm planning to make a tutorial on Navigation Component with single activity architecture
@@codinginflow is it already uploaded?
Have been using single activity pattern for a while (4 years or so). Banner ads can perform uninterrupted and register more impressions when a single activity pattern is employed.
hello sir, i'm still a beginner on android development and i want to ask you something, in Single Activity Architecture, how you can hide the Bottom Navigation Bar on Child Fragments?
I'm pretty sure I'm fed up with Android. Been with it since 2009, but I think it's getting to a point where a lot of what I've spent years mastering are getting reworked, and I don't want to go through the struggles of mastering all this new stuff again. Not to mention all the new "gotcha's" that are going to come along with all these new APIs (remember when fragments came along?). Plus, while I'm busy as hell at work, on what do I spend the 30-45 minutes in the day to learn, Kotlin or Flutter?
You've been good and bad to me, Google. Maybe it's time we spend some time apart.
Hopefully, the things that are being reworked are being reworked because they were difficult to work with and required a lot of workarounds and arcane knowledge that is just no longer needed. As an example, compare the navigate call at 12:08 with the FragmentTransaction code you would have had to write (not to mention things like animations, etc. that can be baked into that call automatically).
Sometimes times the best code to write is no code at all and I feel like the higher level libraries available today mean you get to spend a lot more time working on the actual unique business logic of your app than the boilerplate that dominated apps in 2009. Work smarter rather than harder eh?
That's not to mention the super open development process of all of the AndroidX libraries (all in AOSP, public bugs on the issue tracker such as issuetracker.google.com/issues?q=componentid:409828) that means even if you do encounter a problem, you have a good chance of getting an engineer to look at your issue and actually just fix it for everyone.
My feelings exactly, the Android ecosystem and API is a nightmare for developers. Google has a clear patern of bad decisions when it comes to Android.
Flutter looks great and have a lot of hype, Alibaba have rebuild their app with Flutter and its still such a new framework. I think that it has a lot of potential and it performs well for animations. You are also targeting both android and ios.
Did the old APIs quit working? If you've mastered the old APIs, seems like you are good to go. You don't even need to watch this video if you have mastered the old APIs. ;-)
I'm afraid that unless you specialise in some legacy technology like Cobol, no matter what you do in IT you'll need to constantly learn some new stuff and approaches
Ian's videos are always my favourite 'cause he's always passinote and enthusiastic. Keep up the good work, you're amazing. And thanks for the video.
Thanks! Sharing that passion with you all is really my favorite part of giving talks.
Great talk! Can we find some sample app to get an idea of how all the pieces fit together? Sometimes I got lost with the code examples so having a little app to experiment with would greatly help me.
...
36:09 Dynamic Feature Modules
37:45 Thank you! (summary)
Its good practice to use two navigation(in two deferents activities ) in same app ?
example : one navigation for (register ,login) and second navigation for (navigation drawer) ?
haha, I guess, it makes sense to do this way, so I am also gonna do this only, 2 activities, in total. Did you find any other approach, please let us know :P
That's how I always do it, since the both are totally detached.
25:37: "Use cases for multiple activities"
Thanks, this was what I came here for!
how can we handle multiple backstack with Navigation component? can we handle multiple navigation graph with this ?
Not knowing that you don't know of what there is to know is easy once you know it!
Ian's the best. His Udacity courses were great too :-). Now I'm off to bug my manager to make the app single activity haha.
Like I said at the end, don't contort yourself if it doesn't make sense. Moving each Activity one at a time to Navigation until each is just an empty shell of an Activity makes it a lot easier to later combine the graphs and collapse multiple Activities into one without it being a 'big bang' kind of approach. Updating the Migrating to Navigation guide to call out the steps to make that transition is definitely something we're working on - feel free to star the feature request to track progress: issuetracker.google.com/issues/119646049
What about destroying invisible activities and recreating them when user navigates back to it in order to save memory and resources? Did we stopped to care about that and expect phone manufactures to put more RAM in phones than we used to have in our computers?
thanks for effort.
As a feedback:
As usual, it turned another Google presentation focused nothing. Atleast, as a developer I was expected to hear in depth about navigation.
Yep, for a lot of seasoned developers, none of this should be a surprise, although we did talk about FragmentScenario and FragmentFactory which were literally just released and help considerably towards not just making a Single Activity structure work, but also make it testable.
If you want in depth talks on Navigation, I'd suggest the I/O 2018 talk and the Droidcon NYC 2018 talk: th-cam.com/video/ST2W1Y_Ztvk/w-d-xo.html
Very nice, but what's happens when you have a app where some screens have a navbar or drawer and some screens do not? Can you really do the same with one activity
Wouldn't it be as simple as hiding those views depending on what fragment is visible?
How does this work with when you have app that supports phones and tablet. For example a master detail view on tablet?. In tablet we don't add or replace the fragment as master and detail fragment are side by side. Different navigation graph for phones and tablets??
You can have two layouts in your Single Activity on your res/layout-large variant and from the Activity react upon your current screen size which is also easy to determine with a res/values large variant
I talked about this in some detail in this reddit AMA: www.reddit.com/r/androiddev/comments/8xspo7/were_on_the_engineering_team_for_android_p_ask_us/e2ojrwn/ - basically, due to free-form multi-window being available on Chrome OS devices, you should focus on *every* screen of your app being responsive rather than making huge changes like switching to master/detail. We're working on making that more officially part of our documentation - you can star the feature request for updates on that: issuetracker.google.com/issues/79668915
@@IanLake thanks. cleared most of my doubts.
need a codelab for this
Codelabs are super helpful, yep! We have both a Navigation codelab at codelabs.developers.google.com/codelabs/android-navigation/ and a codelab about responsive Android apps which I think fits well with a single activity structure: codelabs.developers.google.com/codelabs/chromeos-resizing/
@@IanLake yass! thank you, Ian :3
@@IanLake is this a recommended architecture now?
@@danishamjad4816 - that's why I did the talk, yep.
@@IanLake Thanks for quick reply 🙂
Good practice in 2016 , then become Bad practice in 2018 ... all things with google is strange ..
superb way of explaining ...
For a real world app that has many screens to follow the Single Activity approach, I can think of two possible scenarios.
First, a single ViewModel is used and shared by all destinations. This single ViewModel is going to be bloated and not scalable. For this reason, I think the first approach is not suitable for real world development.
Second, multiple ViewModels are used. (Not necessary one ViewModel per destination but would be close.) Given the lifecycle of a ViewModel is tied to the lifecycle of the (single) Activity, how is a "cold" (instantiated by no longer needed) ViewModel going to be released?
Word
IIRC Memory management was one of the reasons they used to consider single-Activity as an anti-pattern for all but the simplest apps (or games & native apps, which were ostensibly doing their own memory-management anyway).
" Given the lifecycle of a ViewModel is tied to the lifecycle of the (single) Activity" Where did you read that? ViewModels are life cycle aware of any LifeCycle owner. Fragments are LifeCycle owners as well
@@areebjamaliam nice to know :)
1.) you can create your own ViewModelStoreOwner and 2.) they have made NavGraphs become ViewModelStoreOwners.
How to restrict fragment recreation in this architecture?
I also want to know how to achieve it.Are we going in the wrong direction?
After all this time, have you found a solution? Maybe we can talk about it.Time has passed so long, have you found the corresponding solution? Maybe we can talk about it.
Great vid!
Great talk!
How can we participate in google submit?
Im stuck with login flow and navigation 🙁
Thanks
This is WAY more confusing than Multiple Activity Development. Still interested in learning more though.
It's possible to use a single-activity for the app, without all this complication, tbh.
@@Zhuinden That's what I was thinking. Alot of whats coming out of android team seems to be targeted at making devs more lazy instead of giving them real new tools. It's not that freaking hard to do transactions
@@nickadams2361 i've been using and updating simple-stack and open-sourcing some then-internal components for simple-stack since writing this comment, you can always check what that's like over defining NavGraphs and Actions and generating code
its been always kotlin these days on your IO presentations. Some of us are still java developers.
because there is no point using java in IO presentations nor documentation. Kotlin dominate android ecosystem for fair reasons.
Time to switch
ENJOY THANKSGIVING
Is there a Java version of this video??
no
Good
Baby bear
Yeah I’m lost
0:21
Picture in picture mode is so broken
Yep, if you're using multiple activities, there's definitely some gotchas as described in medium.com/google-developers/navigation-patterns-with-pip-2c5b6a446ba0 - a lot of these are significantly minimized if you are using a single activity since that avoids any noticeable effects of the task change that occurs when entering picture in picture mode.
Not a good talk at all if you looking for practical tips or for the theory/architecture.
android development is such a pain in the A@#
That's a sure sign that you're doing it wrong.
Stick with Multi-Activity Development. Like he keeps saying, do what works best for you.
The only issue I have with android development is fragmentation..