android-compose-codelabs | repository contains a set of Android Studio projects | Android library

Hey here is my answer to your question

statusBarsPadding() or navigationBarsPadding() as a matter of fact any other Modifiers has to added in its relevant functions.

In the above Code B, let's say DetailsActivity has BottomNavigationBar. Now BottomNavigationBar padding has to be added to DetailsScreen.

It is not always possible to add all the Modifiers to DetailsContent (from the above code) when we have more composable functions or in future, that can be changed to some other.

Maintenance will be easy when we have modifiers at every level.

collectAsState (Code A) is safe for any kind of Flow (cold/hot it doesn't matter). If you look at how collectAsState is implemented then you will see that it uses a LaunchedEffect deep down (collectAsState -> produceState -> LaunchedEffect)

rememberImagePainter does not start loading an image.

It only starts when the corresponding Image is added to the view tree and has non-zero dimensions.

As long as it is not loaded, Image is a transparent view, and you get no performance gain by removing it from the view tree, so part Code A is completely correct.

By creating manually, I mean calling the view model constructor. And this is not practiced with Hilt, because you have to pass down all the injections.

You can't just declare the viewModel: MainViewModel parameter, because then you have to pass it from the calling view.

The viewModel() does all the injection magic for you. Also, if the view model already exists, the same object will be returned. So it's completely automatic.

As here LazyColumn is used fillParentMaxWidth fill be same as fillMaxWidth.

In case of LazyRow, fillMaxWidth will raise an error. So fillParentMaxWidth can be used.

And the other way for LazyColumn.

I've worked with Compose since the early alpha stages and became quickly disappointed with Google's lame attempt at providing a more modern approach to navigating a single-activity app. When you consider that Android's view-based system was entirely replaced with the declaration approach that Compose uses, you have to seriously wonder why they would stick with a navigation controller that doesn't allow you pass objects from one screen to another. There was also the issue that adding animation when transitioning from one screen to another was an afterthought. There is an add-on that supports animation transitions.

But perhaps the worst thing about Compose was its lack of handling device configuration changes. Under the older view-based system, you defined your layouts in xml files and placed these in resource folders that had qualifiers in the folder name that would aid Android in picking the correct layout based on things like screen density, orientation, screen size, etc. That went out the window with Compose. Eventually Google did add APIs to handle composables that need to be selected based on screen sizes and densities. But ultimately, you end up writing this decision logic within your composable and your code starts to look like spaghetti. Google's Android team completely forgot about the most basic "Separation of Concerns" when they chose to mix UI layouts with the logic that determines which layout gets selected. Designing your composables is one thing and how they get selected is another. Don't mix the two. Your composables become increasingly less reusable when you integrate those APIs. The original developers of Android (who weren't from Google) knew well enough to have the operating system manage the layout selection based upon changes to device configurations.

I chose to create my own framework that handles navigation and manages composables in almost an identical way that the view-based system works. It also remedies the issue of not being able to pass objects from screen to screen. If you are interested, you can check it out at:

https://github.com/JohannBlake/Jetmagic

So to answer you question about whether Compose Navigation is good for navigating, I would have to say no. I have worked with it and have found it severely lacking. If you want to be just-another-run-of-the-mill-Android-developer, then use Compose Navigation. But if you want to chart your own path and liberate yourself from Google's poor design practices, then use Jetmagic or even better, create your own navigation framework. It isn't that hard.

Remember that each of the on variables is a callback. onScreenChange implicitly passes the variable it as String, but it is not necessary to use the variable within your callback.

1. it is implicitly passed, but in the GitHub link you gave, the programmer decided to rename it to onScreenChange. That callback then was passed to OverviewBody, which overrides the default {}, as you said. What I don't understand about your question is where onAccountClick is coming from. That is not a parameter of OverviewBody, according to the GitHub code.

2. content has a parameter for another callback, which you noticed. The body variable for each class in the enum is then invoked, and the callback parameter is passed to the invocation. In the future, that callback will only be used by OverviewBody. Remember that body(callback) is the same as body.invoke(callback).

I hope this helps. Please let me know if anything needs some more explanation.

For further reference:

• Kotlin Lambda Docs

Additional Content Edit:

1. I see the parameters in your code, not the one on GitHub. My apologies for missing that.
2. body is a variable function. This means that the variable function can be invoked, either by writing body(...) or body.invoke(...). The String parameter it, which is passed implicitly, is ignored and the default values are used, unless specified like you suggested (onAccountClick=it).

As stated in the documentation

The viewModel() function mentioned in the ViewModel section automatically uses the ViewModel that Hilt constructs with the @HiltViewModel annotation. We've provided documentation with information about Hilt's ViewModel integration.

So as long as your viewmodel has the @HiltViewModel annotation, you don’t have to change anything.