This talk gives us historical reasons for the invention of fragments, as well as their pros/cons. I found that helpful. Also, I liked the part (somewhere after 44:15) when Adam Powell says he thinks options menus should be deprecated and that android.app.FragmentManager actually is deprecated already. Yay.
I think the title of this presentation should be called how fragment usage is affected by new components. The content of this presentation is all scattered to many topics. There is no new things from fragment.
7:51 Fragments, and "Retain objects across configuration changes"? You can retain the Fragment itself, but it doesn't have something like onRetainCustomNonConfigurationInstance. It's one of those things in the Fragment API that is hard to do, and which is why ViewModel exists.
So does the Navigation library supports having a backstack for each tab in a BottomNavigationView? Now that you recommend single Activity apps or is it still something we have to invent our self
Usually when they are talking about "app chrome" (and I've seen this in several of the Google I/O videos), they are talking about the common part of an app that doesn't change like the App Navigation Bar or a bottom navigation bar, etc. (The idea of "chrome" is that's it's the decoration around the changing UI screens.)
Fragments do provide a supporting behavior for that scenario, allowing you to manipulate the toolbar/actionbar menu, of the hosting activity.droidmentor.com/how-to-use-fragment-specific-menu-in-android/
How to manage fragment state duting backstack. Like first contains recyclerview and user scroll to end then onitemclick navigate to second screen. now if user back to previous fragment there is not state managed. it is possible or not.if possible how to manage ?
This is all because the activity instance being destroyed and new one created. Why not fix Activity instead of adding a bunch of new classes (I know they are awesome but still ). Why not retain the activity instance on configuration changed?? I don't get it 😬
Android has, since the beginning, allowed you to handle configuration changes yourself. However, that involves you manually changing any resources (layouts, dimensions, etc) that differ between the separate configurations. That process is actually a lot more complicated and error prone assuming you are actually doing anything responsive (which you absolutely should) than just keeping your expensive data in a separate ViewModel object.
Ian Lake but if the Activity instance was retained we could just rebind our views from any viewmodel variable in the instance. I know this new viewmodel class is helpful for this case but wouldn't it be even better if the Activity instance is retained?
Kasem Saeed - that doesn't help you in needing to manually inflate a new layout associated with your new configuration or update the padding on every view that you use a @dimen variable on
Ian Lake That can always be taken from the resources inside onCreate method, no need to store it inside the viewmodel. The main issue I'm referring to is the complex variables , asynchronous tasks that is being destroyed along with the Activity. We had to handle that on our own just because the Activity is being destroyed.
Kasem Saeed - you need to handle one or the other. Reload every resource by hand or just store your data in something that survives and we'll reload your resources. One is a just a single line of code to access your ViewModel and a simple class, the other requires more and more work as your views and activities grow in complexity. Like I said, you have always been able to do it and for some apps, like a video player, you should definitely consider it. But there's a much, much, much higher chance of forgetting something and doing it wrong. There are specific lint checks to make it very difficult to do anything wrong with a ViewModel
@@AchrafAmil This is how iOS works. Some call it stagnation some call it stability. The base architecture should work 10 years after release. Android development sucks.
How to change the transition from switching from a drawerlayout to a fragment? How to use the onNavigationItemSelected() with the android navigation component??? MORE EXAMPLES PLS!!!
How would you scale an ever evolving ui module,without the ability to break/encapsulate/apply SRP to it? how would you present a composite ui, showing different ui pieces of different app features,and stay life cycle aware? that's why fragments,or at least the concept of fragments is essential .Api wise i would prefer moving as much abstractions as possible to xml components, keep those ui controllers lean.
If a Fragment was designed to do everything an Activity does plus allow you to compose them, why didn't you just allow Activity to be composed? I'm not saying there isn't a good reason, but I would expect you to address this obvious question.
@@thomash1576 Which is crazy because it doesn't have onSaveInstanceState, therefore thankfully it was deprecated. I wish ViewModel had onSaveInstanceState...
Fragments are far too complicated and broken. Stop adding new stuff on top of them. You’re building on sand. Create a simple yet powerful replacement that does not use fragments at all.
robatoto - we actually specifically mentioned that we want to get to the point where there's no magic in Fragments and you (or us) can build something totally new on top of those better signals. That's exactly what we've been doing with Lifecycle and ViewModels and more of that to come. If anything, we're removing more and more things from Fragments, not building on top of them
Whole of the Android SDK sucks. You have to write half an OS to make simple things. If you use Qt, Xamarin or something similar, you can develop at least 50% faster
@Ian Lake We need more exmaples. How to change the transition from switching from a drawerlayout to a fragment? How to use the onNavigationItemSelected() with the android navigation component? How we should use this if we don't know how?
The alternative is to keep the one complicated way of doing things. Creating a much simpler way of doing things and deprecating the old way is going to be a lot better for developers going forward. It just takes a while to get to that point.
"horrible Android Studio"?! Compared to XCode which is just slightly more sophisticated than VI? The Android guys at Google are finally creating a consistent and usable way of doing things, rather than forcing us app devs to reinvent the wheel all the times.
The important point is using the activity as the entry point to your app. For Instant Apps, you have multiple entry points (each separate feature), so multiple activities are totally in line with that recommendation.
You only need an Activity to enter the app, you can use that entry point to start your "main" activity with the right backstack and just swap out fragments in the main activity container
I prefer to avoid fragments. medium.com/square-corner-blog/advocating-against-android-fragments-81fd0b462c97?source=linkShare-ae009bcd66b-1526096251 But perhaps the navigation framework with fragments won’t be so bad. I’m going to be giving fragments a second chance. Io18 “the rebirth of fragments; one of androids most conflicted components”
This talk gives us historical reasons for the invention of fragments, as well as their pros/cons. I found that helpful. Also, I liked the part (somewhere after 44:15) when Adam Powell says he thinks options menus should be deprecated and that android.app.FragmentManager actually is deprecated already. Yay.
what about SupportFragmentManager? :D
9:16 kotlin doesn't have the keyword "new" :D
lol
@@agusavior_channel yeah,... google talk.. lol
lol, compiler should have showed the error
I feel like I got nothing out of this about how exactly should one use em smartly
He is the worst speaker by far. The essence of what is wrong at Android
Was this conference set in the amazon rain forest?
Shoreline Amphitheatre
really, that's annoying
I think the title of this presentation should be called how fragment usage is affected by new components. The content of this presentation is all scattered to many topics. There is no new things from fragment.
7:51 Fragments, and "Retain objects across configuration changes"? You can retain the Fragment itself, but it doesn't have something like onRetainCustomNonConfigurationInstance. It's one of those things in the Fragment API that is hard to do, and which is why ViewModel exists.
43:44 if you don't like Fragments, write your own :D
I am relatively new to Android (3 years so far).
Fragment maybe not perfect, but it works for me.
Why people hate fragment so much? I don't get it.
People just like to hate instead of weighing pros and cons logically.
So does the Navigation library supports having a backstack for each tab in a BottomNavigationView? Now that you recommend single Activity apps or is it still something we have to invent our self
Could you guys attach the slides to these presentations ?
34:21 what is an "app chrome" in "common app chrome"? I googled it but nothing
Usually when they are talking about "app chrome" (and I've seen this in several of the Google I/O videos), they are talking about the common part of an app that doesn't change like the App Navigation Bar or a bottom navigation bar, etc. (The idea of "chrome" is that's it's the decoration around the changing UI screens.)
How about maintaining the Toolbar in Single Activity Apps? How to have different toolbar styles for different fragments?
Fragments do provide a supporting behavior for that scenario, allowing you to manipulate the toolbar/actionbar menu, of the hosting activity.droidmentor.com/how-to-use-fragment-specific-menu-in-android/
Like everything in Android, Do It Yourself :).
Ha ha!
How to manage fragment state duting backstack. Like first contains recyclerview and user scroll to end then onitemclick navigate to second screen. now if user back to previous fragment there is not state managed. it is possible or not.if possible how to manage ?
This is all because the activity instance being destroyed and new one created. Why not fix Activity instead of adding a bunch of new classes (I know they are awesome but still ). Why not retain the activity instance on configuration changed?? I don't get it 😬
Android has, since the beginning, allowed you to handle configuration changes yourself. However, that involves you manually changing any resources (layouts, dimensions, etc) that differ between the separate configurations. That process is actually a lot more complicated and error prone assuming you are actually doing anything responsive (which you absolutely should) than just keeping your expensive data in a separate ViewModel object.
Ian Lake but if the Activity instance was retained we could just rebind our views from any viewmodel variable in the instance. I know this new viewmodel class is helpful for this case but wouldn't it be even better if the Activity instance is retained?
Kasem Saeed - that doesn't help you in needing to manually inflate a new layout associated with your new configuration or update the padding on every view that you use a @dimen variable on
Ian Lake That can always be taken from the resources inside onCreate method, no need to store it inside the viewmodel. The main issue I'm referring to is the complex variables , asynchronous tasks that is being destroyed along with the Activity. We had to handle that on our own just because the Activity is being destroyed.
Kasem Saeed - you need to handle one or the other. Reload every resource by hand or just store your data in something that survives and we'll reload your resources. One is a just a single line of code to access your ViewModel and a simple class, the other requires more and more work as your views and activities grow in complexity. Like I said, you have always been able to do it and for some apps, like a video player, you should definitely consider it. But there's a much, much, much higher chance of forgetting something and doing it wrong. There are specific lint checks to make it very difficult to do anything wrong with a ViewModel
Maybe it's time to make a mature API instead of making everything deprecated and changing paradigm at each iteration...
No. This is not how it works. I don't want a stagnating platform. It's ok to deprecate if you bring a better API.
@@AchrafAmil This is how iOS works. Some call it stagnation some call it stability. The base architecture should work 10 years after release. Android development sucks.
9:42
.replace(R.id.container, MyFragment())
not
.replace(R.id.container, new MyFragment())
Eugene Kirzhanov have to get out of that Java habit lol
😂
Its kotlin dear
Still think fragment makes things even worse
But activity is horrible.
南风不竞 It’s not the idea of fragments that’s bad, it’s the API design made by Google is horrible.
Both have a different purpose
@@areebjamaliam without activity.. There no fragment.. 😋😋
How to change the transition from switching from a drawerlayout to a fragment? How to use the onNavigationItemSelected() with the android navigation component??? MORE EXAMPLES PLS!!!
How would you scale an ever evolving ui module,without the ability to break/encapsulate/apply SRP to it? how would you present a composite ui, showing different ui pieces of different app features,and stay life cycle aware? that's why fragments,or at least the concept of fragments is essential .Api wise i would prefer moving as much abstractions as possible to xml components, keep those ui controllers lean.
The music at the start is too loud compared to the voice volume.
Nav-framework doesn't do "share view(element)" transition. Need update.
I wish they had live code demos.
@Android Developers Where can I get this ppt
Remove the concept of fragments in android and make activity more functional n lighter...
Sometimes Google makes simple things more complex eg. Fragments
Where could I get that emoji shirt?
Instead of fragments why don't you make activity lightweight....?
RIP Blobmoji
If a Fragment was designed to do everything an Activity does plus allow you to compose them, why didn't you just allow Activity to be composed? I'm not saying there isn't a good reason, but I would expect you to address this obvious question.
hehehe watching this in 2021, I have a lotta of catching up to do as a newbie
I feel personally lot of bugs in fragment restoring after destroying.
Google should choose activities or fragments!
Does anyone still using Loaders?
good question :)
there is an approach for retaining your fragment states by using loaders ;- )
@@thomash1576 Which is crazy because it doesn't have onSaveInstanceState, therefore thankfully it was deprecated. I wish ViewModel had onSaveInstanceState...
Is it just me, or does Ian Lake look like Jimmy Hendricks from Silicon Valley?
Does this shirt mean the blob-emojis might come back?
One can only hope...
Fragments are far too complicated and broken. Stop adding new stuff on top of them. You’re building on sand. Create a simple yet powerful replacement that does not use fragments at all.
robatoto - we actually specifically mentioned that we want to get to the point where there's no magic in Fragments and you (or us) can build something totally new on top of those better signals. That's exactly what we've been doing with Lifecycle and ViewModels and more of that to come. If anything, we're removing more and more things from Fragments, not building on top of them
i love to ues fragment its plug and play
Then maybe you should not be a developer.
Whole of the Android SDK sucks. You have to write half an OS to make simple things. If you use Qt, Xamarin or something similar, you can develop at least 50% faster
@Ian Lake We need more exmaples. How to change the transition from switching from a drawerlayout to a fragment? How to use the onNavigationItemSelected() with the android navigation component? How we should use this if we don't know how?
Does that mean we don't have to bother with fragment transactions in most cases? This is great!
Google keeps adding more and more ways to implement the same thing. This is literally road to hell!
The alternative is to keep the one complicated way of doing things. Creating a much simpler way of doing things and deprecating the old way is going to be a lot better for developers going forward. It just takes a while to get to that point.
Oh man you almost had me fooled, i thought you were being serious until you said 'horrible Android Studio'. :)
"horrible Android Studio"?! Compared to XCode which is just slightly more sophisticated than VI? The Android guys at Google are finally creating a consistent and usable way of doing things, rather than forcing us app devs to reinvent the wheel all the times.
What a confusing series of Google I/O. Each presentation is about same thing but nothing is clear.
Will he get fined if he says "pain in the ass"?
I was thinking the same thing! In his place, I would have accidentally said "pain in the ass".
what a struggle to get the foundation right -to clean up the mess! .apparently just to help developers !
They talked a lot. I want they to describe in pictures
How to make instant apps, when all your app is in one activity with fragments ?
The important point is using the activity as the entry point to your app. For Instant Apps, you have multiple entry points (each separate feature), so multiple activities are totally in line with that recommendation.
You only need an Activity to enter the app, you can use that entry point to start your "main" activity with the right backstack and just swap out fragments in the main activity container
Thank you!
PLEASE HELP ME 🙏🙏🙏🙏🙏🙏
Nice like it
I prefer to avoid fragments. medium.com/square-corner-blog/advocating-against-android-fragments-81fd0b462c97?source=linkShare-ae009bcd66b-1526096251
But perhaps the navigation framework with fragments won’t be so bad. I’m going to be giving fragments a second chance.
Io18 “the rebirth of fragments; one of androids most conflicted components”
I'd rather just use my own lightweight controller
Switching to kotlin was a very lame move...
Android Development sucks
SHOW THE SLIDES!!! We don't care about these guys' faces. We want to see what's on the slides that they're talking about.
Ugly SDK, bad design, I dont know, maybe I vastly overestimate their engineers.
我們的訊息者，題供專屬弧度示意，對
gay ？