Activity and Fragment division

[JonZarate]

I don't quite understand why you decouple Activity and Fragment.

You seem to be trying to restore the Fragment from the stack, something that (if I am not mistaken) you cannot do unless you set setRetainInstance to true in the fragment. However, I only found it in one so far (CreateFragment).

Could you explain ? Thanks!

[BracketCove]

Hi Jon,

My rational for decoupling Activities and Fragments in general, is that I treat Activities as feature level containers in my architecture, and you won't catch me breaking separation of concerns without a good reason. Whether or not you follow a single root activity approach with fragment subviews for each feature, or you follow my extreme separation of concerns in keeping all features self-contained (both of which have advantages and disadvantages), I don't typically advise anyone use Activities as Views, and I certainly don't advise filling them up with logic at the same time. There are almost always good cases to break any principle though, which I'll address in a moment.

So, setRetainInstance will allow a fragment to keep it's instance, but the view object it holds is still destroyed and redrawn (sounds like you've got that, I'm just sharing how I view setRetainInstance). I see in this repository, that I hadn't quite figured out how to actually apply separation of concerns and truly decouple state from the view (that was a big hurdle for me, and I actually solved it by using AAC's ViewModel as a ViewModel, not as a ViewModelController as many people do).

In any case, my goal with this project was to try and build a simple example of these APIs quite closely to how it was recommended in the initial guide for AAC. I wasn't fond of building applications in that manner back then, and over time, I still don't think it works well in complex applications (although it may serve as a good starting point for some).

With that being said, I do not at this point advise keeping any state in fragments, nor using setRetainInstance as a tool for that. In fact, I don't advise anyone does much with this project other than possibly learn a bit about implementing Room, ViewModel, and LiveData. For better examples of my current approach, these repositories represent my typical approach:
Simplified:
https://github.com/BracketCove/KotlinMVPCalculator

Advanced:
https://github.com/BracketCove/SpaceNotes

Now, I have very good reason to decouple Activities and Fragments in SpaceNotes (easy access to context to grab my DI implementation, supportFragmentManager out of the box, Activities are fragile in nature, I'll probably use onActivityResult, the list goes on), but a pragmatist could certainly complain (they do) about doing so in a Feature as simple as a Calculator. If you do have a very simple feature, and you don't want to decouple View Logic from your Activity, then I'd probably just use the Activity too unless I was deliberately trying to teach or practice my skills.

Hopefully that helps; thank you for the question.