I’m looking for some insight into architecture paradigms (I think) for an android app (in Kotlin 😃). Do you want to basically have one activity and use the navigation component to switch out fragments inside of it? Or, do you want to have an activity for each screen of your application?

My opinion is one activity, no fragments (switch out custom views). There are a number of different viable approaches. The most important thing is to stick with one as much as possible.

One activity, as the entry point , with fragments, and Nav Component is what Google suggest

I'd alter that to read "One activity per entry point, with fragments..."

@dalexander what would the difference be between fragments and custom views if you can basically set the view of the fragment to be whatever you want?

@scottiedog45 There isn't a single answer for this that applies to all apps. I'd recommend sticking with Activities and Fragments until you get a bit more familiar. The custom view approach, while valid, requires that you do things like manage the back stack, state restoration, etc yourself. There are libraries to help with that, but until you have a good understanding of why you need them it's probably best to stick with the standards.

@rharter I’m totally down with that - I feel like this structure should easily meet my requirements thanks everyone!

I have done the custom view thing for several apps (I used to freelance, so have written a lot of apps) and I consider it a more advanced approach.

The only pro in using Custom views is that you don't have to deal with the Fragment Lifecycle. But the Fragment Lifecycle isn't all that complicated plus with the release NavComponent ,alot things can be handled in the background.

…Right, the advantage of custom views is that you can avoid the Fragment lifecycle, which adds a lot of subtle complexities that are hard to notice during development time. And as Ryan mentioned the cost is that you need a framework to handle parts of the navigation that Fragments / the Fragment Manager normally would take care of.

@dalexander There are also drawbacks from using custom views. For one its not a industry standard to use custom views in that manner, so to a new dev joining a team, the codebase will be quite confusing.Also you might not need to handle fragment callbacks, but custom views also add a level of complexity. and Architecturally speaking, are you going to have a presenter/ view-model for each custom view. This is really not what views are meant to do, . Views are really just meant to display things on the screen

I don’t know why you would put a view-model inside an Android View, or what relationship that would have not using Fragments, but I’m not going to argue over what architecture should be used, I just wanted to mentioned my preferred architecture in response to the question.

For instance, in a MVP pattern a fragment would have has a Presenter. if you replace views for custom views,how would you handle the business logic. In a activity that has multiple screens, would you just have one big presenter?or would you encapsulate all the business logic inside the activity?

Oh I’d be happy to talk about the details of how I structure things outside of the context of which is better 🙂 In my case, the pattern I like to use captures the business logic in what’s basically a ViewModel, in the sense that it “owns” the view and it’s mostly what the rest of the app refers to when navigating to a location. So you’d generally have one activity, and switch out the ViewModels (which can be decoupled from a specific View if necessary). The navigation framework is responsible for displaying the ViewModel and View. The Views are dumb as rocks and contain no business logic, they just expose a few functions for hooking in to.