[lawgimenez]

I am also an Android developer for over a decade. One thing I dislike about Android development is the fragmented way to do things. There was the support libraries v4, v7 and now the jetpack or androidx.* libraries. My UI is composed of different namespaces like androidx.drawerlayout.widget.DrawerLayout and com.google.android.material.appbar.MaterialToolbar. This is just confusing.

Also you need to choose MVC, MVP, Viper, MVVM, AAC, RxJava, and now Jetpack Compose which completely is different compared to other architectures.

But nonetheless I am excited with Jetpack Compose.

[Ologn]

> Also you need to choose MVC, MVP, Viper, MVVM, AAC, RxJava, and now Jetpack Compose which completely is different compared to other architectures.

Insofar as MVC, MVP, Viper, and MVVM - the vast majority of places I know of use MVVM. I can't think of many using MVC or Viper (a form of clean), and MVP is mostly used by older apps. Some places use clean architecture, which MVVM can work in conjunction with since the concentration is on different things.

Also most new projects I know of use coroutines and flow over RxJava, and plenty of RxJava projects are migrating to this as well.

Just like Clean can work with MVVM, so can Jetpack Compose - you just have a StateFlow (or LiveData) in a ViewModel with the UI model of the screen to display. So Jetpack Compose can work with MVVM, it is just a shift in thinking - and unidirectional data flow is being picked up for non-Compose Android projects too as it can make testing easier - instead of needing to fully rely on Espresso to test UI features, you can complement those tests with lots of JUnit unit tests on the UI model feeding into lean lifecycle components. Compose isn't different than MVVM, it can work with MVVM, it just modifies how MVVM is used.

Compose is also similar to reactive UI that other (non-Android) platforms use.

[rTX5CMRXIfFG]

I have over a decade of experience in iOS dev and I’ve learned that all of the architectures you mentioned except for MVVM are bad advice.

Clean Architecture is a terribly written book with generic, inactionable advice, and where it makes sense, it makes sense for server-side environments in Java, but would result in over-engineering for mobile OSes which have only become more and more tightly integrated over time, therefore encouraging necessary tight couplings in code (e.g. lifecycles of applications, views, and background and concurrent tasks). I’m afraid I don’t think that mobile developers who are advocating this approach are thinking very critically, and are instead imposing a silver-bullet architecture on problems, instead of letting the right solution or architecture emerge from the right problem.

MVVM is also just an augmentation of MVC but it is still inherently MVC—and especially in iOS, the “view model” is really just a model- instead of a view-controller—so I really don’t understand why there are ever programmers who talk about MVVM as if it is different from MVC.

[Apocryphon]

As far as I know, the biggest use of Clean Architecture in mobile is at Uber with the RIBs architecture, and it’s only applicable there because an app of that team size is closer to an enterprise Java server codebase. Most apps everywhere are not anything like that, and thus should not be using VIPER.

[ParanoidShroom]

Speaking from experience where a team here has made a RIBS implementation. Stay away, keep it simple. Even at a fang size company it's not worth it

[Apocryphon]

What's the size of the team/app? Really curious what companies out there besides Uber has used RIBS or VIPER. Not sure why they would do that either, other than it was trendy on some technical blogs back in like 2014.

[lawgimenez]

Slack’s mobile team uses a variation of VIPER.

[kitsunesoba]

As a long time iOS dev who later took on Android, I share the frustrations of platform fragmentation and messy namespaces. I’ll also add that compared to iOS, on average on Android you’re reaching for third party libraries a lot more often which comes with its own set of frustrations. Not that iOS dev is perfect either, but as a whole I feel far more productive there than on Android.

Haven’t yet tried Compose but it seems promising.

[lawgimenez]

I also develop on iOS and I agree with your comment. Example of this is iOS built in URLSession compared to Android’s deprecation of Volley so we have to rely on a third party Retrofit. The thought of that is just insane to me.

[Ologn]

> third party Retrofit

For whatever historical reasons, there has been a flow of Android programmers from Google to Square (and from Square to Google). Square libraries are often written by people who came from the Google Android team. Dagger was written at Square but maintenance was handed over to Google. So technically Square's libraries are third party and Square gets some credit for it all, but it's not totally independent.

[lawgimenez]

Yes I wonder what’s keeping them integrating Retrofit to Android’s SDK.

[tadfisher]

Because bundling APIs in the SDK has traditionally led to more fragmentation, not less. Hence the androidx libraries and now Compose, which creates an API surface that mostly works without having to think about OS versions.

I talk with iOS devs often, and most of them do not use SwiftUI because the feature disparity is massive across iOS releases. Bundling features into the Android SDK would be about 1000 times worse because Android OEMs don't update their devices like Apple does.

[kitsunesoba]

> I talk with iOS devs often, and most of them do not use SwiftUI because the feature disparity is massive across iOS releases. Bundling features into the Android SDK would be about 1000 times worse because Android OEMs don't update their devices like Apple does.

That's largely due to SwiftUI's newness and immaturity, though. Although UIKit gets major new additions each year it doesn't have that problem because all of the essentials have been in place for ages, which means when supporting older releases you can either just use the older APIs or use a combination of old and new with conditionals.

[solardev]

Even as a mere user, I don't think I've ever encountered two Android apps that quite looked or felt the same. It's such a janky platform...