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.
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
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
@@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 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.
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/
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 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 ?
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!!!
@@thomash1576 Which is crazy because it doesn't have onSaveInstanceState, therefore thankfully it was deprecated. I wish ViewModel had onSaveInstanceState...
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.
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 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
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.
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”
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
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
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.
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
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
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 ?
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.
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.
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!
The music at the start is too loud compared to the voice volume.
Remove the concept of fragments in android and make activity more functional n lighter...
RIP Blobmoji
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.. 😋😋
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 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 ?
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!!!
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...
I wish they had live code demos.
Nav-framework doesn't do "share view(element)" transition. Need update.
@Android Developers Where can I get this ppt
I feel personally lot of bugs in fragment restoring after destroying.
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.
Sometimes Google makes simple things more complex eg. Fragments
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".
Does this shirt mean the blob-emojis might come back?
One can only hope...
Is it just me, or does Ian Lake look like Jimmy Hendricks from Silicon Valley?
Google should choose activities or fragments!
Where could I get that emoji shirt?
Instead of fragments why don't you make activity lightweight....?
Does that mean we don't have to bother with fragment transactions in most cases? This is great!
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?
hehehe watching this in 2021, I have a lotta of catching up to do as a newbie
What a confusing series of Google I/O. Each presentation is about same thing but nothing is clear.
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
They talked a lot. I want they to describe in pictures
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 struggle to get the foundation right -to clean up the mess! .apparently just to help developers !
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”
PLEASE HELP ME 🙏🙏🙏🙏🙏🙏
Thank you!
I'd rather just use my own lightweight controller
Switching to kotlin was a very lame move...
Nice like it
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.
Android Development sucks
我們的訊息者，題供專屬弧度示意，對
Ugly SDK, bad design, I dont know, maybe I vastly overestimate their engineers.
gay ？