Live data from Hacker News

I quit Android Development after 10 years and what I plan to do now

levelup.gitconnected.com

21–30 of 39 posts

Re: I quit Android Development after 10 years and what I plan to do now

#21
post #17

Ironically what has put me off was the way Android team deals with their Android Java flavour, how clunky NDK happens to be versus the C and C++ experience on Apple and Microsoft platforms, and that for most apps, the mobile Web is good enough for forms over data. At least Chrome gets more updates than the underlying Android version.

> how clunky NDK happens to be versus the C and C++ experience on Apple and Microsoft platforms

Also in 2012 there was just gcc support, and by 2015 gcc was deprecated for Clang, creating a lot of extra work for app developers due to that (technical? commercial?) decision.

Re: I quit Android Development after 10 years and what I plan to do now

#22

Earlier quoted context omitted.

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, t…

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.

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

Re: I quit Android Development after 10 years and what I plan to do now

#23

Earlier quoted context omitted.

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.

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

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.

Re: I quit Android Development after 10 years and what I plan to do now

#24

Earlier quoted context omitted.

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

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.

Slack’s mobile team uses a variation of VIPER.

Re: I quit Android Development after 10 years and what I plan to do now

#25

Earlier quoted context omitted.

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.

Slack’s mobile team uses a variation of VIPER.

Ah, I see: https://slack.engineering/scaling-slacks-mobile-codebases-mo...

Re: I quit Android Development after 10 years and what I plan to do now

#27
post #13

Earlier quoted context omitted.

> 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 i…

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

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.

Re: I quit Android Development after 10 years and what I plan to do now

#28
post #17

Ironically what has put me off was the way Android team deals with their Android Java flavour, how clunky NDK happens to be versus the C and C++ experience on Apple and Microsoft platforms, and that for most apps, the mobile Web is good enough for forms over data. At least Chrome gets more updates than the underlying Android version.

How does the rollout of Jetpack Compose compare with that of SwiftUI, any idea?

I bet our company's app on Compose (shipped with 1.0), and it's been a very positive experience. The teething pains were real, but with 1.2 most of them have been addressed.

The iOS devs I've talked to don't use SwiftUI because it's bundled with OS releases, so they have to use the lowest-common denominator of features for their minimum target. This is less of a problem as time goes on and the framework matures, but it has definitely slowed adoption as I see it.

Re: I quit Android Development after 10 years and what I plan to do now

#29

Earlier quoted context omitted.

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

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…

> 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.

Re: I quit Android Development after 10 years and what I plan to do now

#30

This article really does bring up a valid point about the career path for mobile does seem undefined. How is one expected to advance into principal / staff as a mobile developer? While to do so as a backend dev, whose code affects all downstream, is much more clear.

I mean, they're mostly correct, but it's not like you have to be a "pure Android developer". I contribute to our backend all the time, but my primary role is still Android, and I hit staff pretty quickly. The mindset that you can only contribute to your functional domain is what keeps you from a staff position, and if you work at a place that doesn't share this mindset, there are always ways to contribute outside of your primary domain. It doesn't have to be code, either, and mobile engineers at the staff level should have pretty wide-ranging exposure to design, product management, systems architecture, etc.
Post reply on HN