4 ms·

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 librar

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.

kitsunesoba 4y ago
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 4y ago
  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 4y ago
    > 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 4y ago
      Yes I wonder what’s keeping them integrating Retrofit to Android’s SDK.
      - tadfisher 4y ago
        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 4y ago
        > 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 4y ago
  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...
Ologn 4y ago
> 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 4y ago
  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 4y ago

kitsunesoba 4y ago

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 4y ago
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 4y ago
  > 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 4y ago
    Yes I wonder what’s keeping them integrating Retrofit to Android’s SDK.
    - tadfisher 4y ago
      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 4y ago
        > 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 4y ago
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...

Ologn 4y ago

> 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 4y ago
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 4y ago