Member Avatar for LaughingOtter

Hello!
I've just nearly finished a mobile app for my company, and there are quite a number of Activities in it.
I've also been advised (here, in fact!) to check out the possibility of using Fragments for the various screens.

Fragments in this case sounds like the way it should have been developed, but I'm still learning this whole Android programming thing.

So, the main Activity fires off after the login Activity and retrieves the user's XML data file, which will usually be generated immediately after login, unless the user is returning that same day, in which case the same XML file would be loaded and reused. (Our company regenerates data only once a day.) This XML file is about 32KB in length, so should not be a hassle to the XMLParser class.

Does it make sense that this Activity should be used to read, parse, and persistently store the XML data for the Fragments to read and display as necessary?

If so, I have read that layout inflaters and declarative XML are the best way to write the display screens for each Fragment. Is this true?

Not looking for code examples here. I'd just like to know if this is the right approach.

Thanks, dudes!

  • 2 Contributors
  • 4 Replies
  • 88 Views
  • 4 Days Discussion Span
  • Latest Post Latest Post by LaughingOtter

Dani AI

Generated

Good instinct, — Fragments are great for screen-level UI reuse. Building on 's container/view analogy, modern Android separates data ownership from UI controllers so Activities and Fragments stay thin.

Put parsing and persistence into a lifecycle-aware, non-UI layer (a Repository) and expose the resulting model through a ViewModel that Fragments observe. That lets parsing run off the UI thread, caches results for reuse, and survives rotations without forcing Activity-to-Fragment plumbing. Fragments should get either a small key via their arguments or observe a shared, activity-scoped ViewModel rather than receiving large blobs in Bundles (avoid TransactionTooLarge and Parcelable pitfalls). Do not store Context or Views in ViewModels.

Practical notes: parse on a background thread (streaming parser for memory efficiency), persist the structured data to a local store (Room, file) if needed, and expose changes via LiveData or Flow so UI updates automatically. If a screen truly requires its own Activity because of complexity, reuse the same Repository/ViewModel approach so data handling is consistent. Watch for leaks when holding references to Activities/Fragments and use lifecycle-aware observers.

For recommended patterns and lifecycle behavior, see the Android architecture guidance and the ViewModel docs:
Guide to app architecture
ViewModel

Recommended Answers

All 4 Replies

Member Avatar for peter_budo

If you ever did any Java AWT/Swing development Android Activity would be something like your application frame, where Fragment is more like View that you can dynamically swap as need it. Therefore in most cases it does make sense for Activity to be data handling part.

Member Avatar for LaughingOtter

But that's really only practical if your screen size is large enough. For most phone-type mobile devices that won't cut it. GAAH! Now what do I do?

Member Avatar for LaughingOtter

OK. I will give that a read and see if it can be done. I already see one section of the app that will probably have to be its own Activity due to the size and complexity of data it needs to load/work with, but the rest could be Fragments if the XML can get from the main Activity to the Fragment for display.
Thanks for the tip, Peter!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.