He is the worst speaker by far. The essence of what is wrong at Android

what about SupportFragmentManager? :D

lol

@@agusavior_channel yeah,... google talk.. lol

lol, compiler should have showed the error

People just like to hate instead of weighing pros and cons logically.

Shoreline Amphitheatre

really, that's annoying

43:44 if you don't like Fragments, write your own :D

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!

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

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.)

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.. 😋😋

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...

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.

I was thinking the same thing! In his place, I would have accidentally said "pain in the ass".

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

Eugene Kirzhanov have to get out of that Java habit lol

😂

Its kotlin dear

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.

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?