Android app architecture with bottom navigation

[priyanshi bhardwaj]

Hello everyone,
I wanted to know what's an ideal structure of an app if I am using a bottom navigation in my base activity with three items in the menu Home screen, chat with customer service and profile. How should I design teh app so that app runs fast just like youtube/instagram. I wanted to know How does youtube app runs so fast after multiple videos etc.... Actually I wanted to know what is youtube's/instagram app architecture on android side ? Any reference link is also appreciated. It could be great if any senior android developer can guide me little so that I know the best practices available in the market Thanks in advance

[Tim Moores]

Whether (and how) you use bottom navigation is a design detail that has little impact on the architecture. I doubt there is much information about how specific apps are architected. For general advice on that, start reading at https://developer.android.com/jetpack/guide. Also note that with just about any architecture it's still possible to write sluggish apps - a good architecture just makes it easier to avoid that

[priyanshi bhardwaj]

Tim Moores wrote:Whether (and how) you use bottom navigation is a design detail that has little impact on the architecture. I doubt there is much information about how specific apps are architected. For general advice on that, start reading at https://developer.android.com/jetpack/guide. Also note that with just about any architecture it's still possible to write sluggish apps - a good architecture just makes it easier to avoid that

Hi I have implemented bottom navigation in my app. But actually I am facing few ANR's. Let me tell you what I have used I have used navigation component with bottom navigation. As per my current debugging Anr reasons is multiple switches in bottom navigation. As I am using Navigation component so on every switch my fragment is getting recreated  which is causing ANR in my app. And I am unable to figure out how do we load a fragment from it's backstack with navigation component. Need help on this.

[Campbell Ritchie]

I merged your stuff with the following thread. I hope that is okay by you.

[priyanshi bhardwaj]

Campbell Ritchie wrote:priyanshi bhardwaj,
I have merged your topic into this topic. I hope that helps.

I am sorry but which topic to which topic ? I am unable to understand

[Tim Holloway]

priyanshi bhardwaj wrote:

Campbell Ritchie wrote:priyanshi bhardwaj,
I have merged your topic into this topic. I hope that helps.

I am sorry but which topic to which topic ? I am unable to understand

You seem to keep posting the same question over and over. That isn't going to get an answer any faster, and it just confuses everyone.

I don't know what an "ANR" is. We prefer that people avoid using acronyms where possible.

Anyway, Top navigation, bottom navigation or both, I'd expect you to be using toolbars. The standard Android widgets all have good performance, so the speed issues will generally be in the code you write and attach to them.

[Tim Moores]

priyanshi bhardwaj wrote:As per my current debugging Anr reasons is multiple switches in bottom navigation. As I am using Navigation component so on every switch my fragment is getting recreated  which is causing ANR in my app.

By "switch", do you mean a user clicking on something? That should not happen all that often - maybe once per second? ANRs generally happen if the code does too much on the UI thread - creating a fragment should be a quick operation. Anything you need to do that takes time should be relegated to a background thread instead. And you should think about why time-consuming operations are being done every time a new fragment is created - is there something that could be cached?

Tim Holloway wrote:I don't know what an "ANR" is. We prefer that people avoid using acronyms where possible.

ANR (Application Not Responding) is a term every Android developer would be familiar with, so I think it's fair game in this forum.

[Tim Holloway]

Tim Moores wrote:
ANR (Application Not Responding) is a term every Android developer would be familiar with, so I think it's fair game in this forum.

Lots of platforms have situations where the application becomes unresponsive. None of them have ever used the term "ANR" that I'm aware of. Not desktop apps, not webapps. Say "ANR" in forums dedicated to such beasts and you'll just get blank stares.

Nor am I aware that "ANR" is a term defined in any of my Android books (admittedly, they're rather ancient). Plus it's a vague term, since apps can "hang" and appear unresponsive, but that's not the same as an eternal lockup.

I'm not a big fan of secondary acronyms, and that includes NPE and OOM. Before abbreviating, I always make sure that I've spelled out what the acronym means at least once. Playing "guess-the-alphabet" is to me waste of time and a potential source of misunderstanding or error.

[Tim Moores]

Tim Holloway wrote:Lots of platforms have situations where the application becomes unresponsive. None of them have ever used the term "ANR" that I'm aware of. Not desktop apps, not webapps. Say "ANR" in forums dedicated to such beasts and you'll just get blank stares.

Being Android terminology, it wouldn't make sense to do that, so the point is moot.

Nor am I aware that "ANR" is a term defined in any of my Android books (admittedly, they're rather ancient). Plus it's a vague term, ...

Anyone who has apps in the Android Play Store -or was developing for Android beyond tinkering as a hobby-, would definitely know the term, and its specific meaning: anr site:developer.android.com. Not least because Google would let you know that your apps encounter them :-)

[Tim Holloway]

Nevertheless, I don't approve of careless use of acronyms in any other forum and I'm not inclined to make an exception here.