[jpetitto]

I'm actually surprised they're relying on Activities for the views in the app. I'm not familiar with how the app works, but this is typically an out-dated approach. Activities should really only be treated as entry points into your app.

Also, not a huge deal for an app, but the package structure is organized by layers, not features. Makes Java's non-private access modifiers essentially useless.

The general style of the source code is solid though. I wouldn't be upset if I had to work in this code base on a daily basis.

[unsoundInput]

I disagree with you regarding Activities. For apps they do most of the screen management the developer needs just fine, especially if they are backed by a strong view and data model. If you download the App you can actually really quickly make out where they leverage the single Fragment (switch the project category via the drawer) and it makes sense there; but I think the same App build with a single Activity and Fragments would be much messier (especially regarding animations and back-navigation) and they'd gain (next to) nothing.

[jpetitto]

I'm not a fan of Fragments when it comes to navigation either, but there are other solutions as well (see Conductor). But there are limitations to using a new Activity for each screen, which I mention in my other comment below. They really only make sense for specific features in an app that require a specific entry point. Things like external intents (other apps, push notifications, etc...) or deep linking, as another user mentioned. They may be useful for Google Instant Apps too depending on how it ends up working.

[unsoundInput]

Fully agreed that there are limitations, but I still think calling it an out-dated approach is unfair.

I don't see a simple, low on boilerplate, one-size-fits-all solution for reusable and separated components on Android at the moment. I love that the community didn't settle with just Activities or just Fragments and is actively trying new stuff (after all, if you look at React or Vue or even freaking backbone.marionette, the web is in a much better spot right now regarding UI composition), but right now the right solutions always seems to take the path of least resistance and use whatever mix of pattern that gets you to your goal as easily as possible.

[Plaastix]

I agree with you as well. It makes deep linking easier since you don't need to recreate an entire fragment backstack.

[skewart]

Just curious, why should activities only be treated as entry points to the app? What are the downsides of the only-use-fragments-if-you-need-to approach?

[jpetitto]

Fragments are one option. Another is just to use regular Views. There are libraries to help you with this such as Conductor.

As for Activities, they are usually overkill for most screens. They don't allow for seamless transitions between screens and prevent sharing UI components across screens (e.g. a Toolbar). Fragments and/or regular views have the added flexibility of being able to use more than one at a time and allows for easy re-use and view composition.

Like I said in my previous comment, the only really good reason to create additional Activities is to provide additional entry points into your app. Otherwise Fragments or Views will suffice and provide greater flexibility and improve the UX in many cases.

[BoorishBears]

For one, the backstack story for Fragments is a lot more sane than whole "Task" concept for activities (The backstack for fragments is a list of fragments you can manipulate and debug very easily).