Live data from Hacker News

It’s Been Real, Android: Why I’m Retiring from Android

raptureinvenice.com

141–150 of 342 posts

Re: It’s Been Real, Android: Why I’m Retiring from Android

#141
Just like the web platform, Android is hugely improved when you leverage the community libraries and tools they provided. Gradle actually helps a lot with that, since its clear dependency management makes use of external libraries a breeze.

If in 2016 you're still complaining about AsyncTasks and its management, you certanly have missed a lot of progress in the last few years. It's not unlike having people complain about JavaScript issues without ever looking at jQuery, React or newer tooling.

The most useful things you can do for yourself currently are:

* Adopt Kotlin as a language. It's not all that different from Swift, comes with IDE support, tiny standard library and really fixes the pain of Java 6.

* Use MVP patterns and its friends. There are a few libraries which take most of the pain of lifecycles away.

* Use RxJava, Retrofit, Glide, etc. libraries that make your life easier with concurrency. A lot of these tools are better and easier to use than what even exists on iOS. Using AsyncTask in 2016 is just silly, it was never a good API.

* Use Gradle! Driven by its scripting language, you can do so much to script and automatize your build.

Other than that, I agree, after years of development:

* Some Android APIs just aren't well thought out.

* Gradle badly needs performance improvement.

* State of NDK is just sad. Fixable, but sad.

* MultiDEX is a result of a very very dumb decision in Android 1.0 and it's going to hurt us for a long time :/

All-in-all, I honestly think the author didn't really look into Android all that much to have complaints that he had. The blog post is somewhere on the level of someone complaining about IE6 JavaScript bugs when we've already moved on to React and are dealing now with very different issues.

(And no I'm not saying Android is great or even a great platform. It's not. It's just that, just like on Web, you can do a lot to fix major pains.)

Re: It’s Been Real, Android: Why I’m Retiring from Android

#142

Earlier quoted context omitted.

> After all these years, I still find the most difficult and un-natural thing is mixing concurrency / background tasks that must outlive the UI with complex UI component lifecycles. Completely agree. I've been developing for Android since 1.0 and the complex interaction between background tasks and activity lifecycle is the worst part of Android that a significant majority of devs get wrong, introducing subtle bugs.…

Some historical context, fragments came out with Honeycomb which was the first version of Android specifically for tablets. As such Fragments were meant to be a way write UI in something both tablet and phone layouts could use. So, that's the mysterious reason for the extra layer of complexity. I think at this point, many people don't even use them unless they specifically need to for tablet/phone/tv shared layouts.…

Also, they envisioned tablets to be used mostly in landscape. That's why we got everything on a single bar at the bottom.

The basic concept behind Fragments was pretty much the same as WebOS' Enyo framework. I recall one of the big Enyo demo moments was when a browser window was resized, and the email app ui went from multiple columns to a single column, and back, without missing a beat.

Then again i wonder if Android was partially designed, before Fragments, to rekindle the experience of using Apple's Newton tablet. This in that one app would extend the functionality of another app in a virtually seamless manner via intents.

But as best i can tell, Android left too much of the plumbing in the hands of the app devs. Thus for every app that handled cross-app intents properly, you got 100+ that would jump back through the in-app activity history rather than roll back the intent chain.

And with fragments you got a in-app way to do the activity history backtracking, while still having the intent focused back button of the Android UI.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#143
post #49

> Google’s adoption of gradle has been a disaster and proved to be a terrible decision. It did help out with some previous issues, namely multiple app targets, but it’s slowed down compilation severely. It also makes for masochistic configuration files with major redundancy and fragmented dependency hosts. Getting an app to compile shouldn’t be a challenge. The only thing worse than gradle is ANT, which it replaced.…

> The only thing worse than gradle is ANT, which it replaced. What's wrong with ant? I liked it.. It was simple to understand for the most part. It also made it easy to develop without an IDE, although I'll admit I don't know how easy it is now as I stopped doing Android a year ago

And that's about all it does. Gradle has proper dependency managment with Maven repository support (add one line and your library is in, no fsckery with JARs and whatnot), has scripting in an imperative language instead of craziness of XML (we use it to automate releases, uploads, Git commits, etc.) and really good plugin support.

It's also slow as arse unfortunately.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#144

Earlier quoted context omitted.

> After all these years, I still find the most difficult and un-natural thing is mixing concurrency / background tasks that must outlive the UI with complex UI component lifecycles. Completely agree. I've been developing for Android since 1.0 and the complex interaction between background tasks and activity lifecycle is the worst part of Android that a significant majority of devs get wrong, introducing subtle bugs.…

Some historical context, fragments came out with Honeycomb which was the first version of Android specifically for tablets. As such Fragments were meant to be a way write UI in something both tablet and phone layouts could use. So, that's the mysterious reason for the extra layer of complexity. I think at this point, many people don't even use them unless they specifically need to for tablet/phone/tv shared layouts.…

I use Fragments as "Content View Controller", phone / tablet whatever, it's just a reusable piece of UI / Logic for me.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#145

Earlier quoted context omitted.

This is not a problem with android or google. The only way you can avoid this update problem is to convince ARM SoC manufacturers to standardise their SoCs instead of cooking their own soup every time. I think this is never going to happen. Apple doesn't need to standardise. They can get away with just supporting their own devices.

Even if the SoCs are standardized and drivers are updated, do you think the manufacturers have any motive or incentive to provide updates to the customers for older models? Most of them sell phones for low prices at very thin margins or at a loss and rely on releasing newer models more often to keep up sales. Even with standardization, hardware differences will necessitate testing on older devices. That does not come…

If one get the driver side sorted, it will be easier for Google to push for a scheme similar to Windows.

On top of that Google could implement a standardized UI themeing system, allowing companies to give their products a distinct experience without having to muck with the code as much.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#146
post #6

I don't think that the person is being lazy. I've tried my hand at Android. I will continue to do so. I don't like it for the reasons enumerated in the post. The whole damn thing is a hack at this point. No one has a good generalizable architectural model for laying out an Android project. Attempting to target multiple devices is truly a pain. You can do it. You have to really, really think about. You also have to en…

Ever since i picked up a Nokia N800 back in the day, my go to setup has been a featurephone with bluetooth and a "smart device". Thus if i need a net connection right damn now, i can pair the smart device with the featurephone and get online.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#147
post #141

Just like the web platform, Android is hugely improved when you leverage the community libraries and tools they provided. Gradle actually helps a lot with that, since its clear dependency management makes use of external libraries a breeze. If in 2016 you're still complaining about AsyncTasks and its management, you certanly have missed a lot of progress in the last few years. It's not unlike having people complain a…

Exactly. Criticize is easy. That guy should stop whining and rather enlighten us with his home brewed platform, language, tooling, etc.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#148
post #33

Kind of an OT whine relative to the contents, but I'm still extremely frustrated at how hard it is to get other languages working on Android due to the multidex-style issues. Google should be spending millions being able to get app development up and running in something like Python. Have your app up and working in 2 minutes without having to learn Java. It boggles the mind that this isn't the case, and that the curr…

The same could be said about any platform - e.g. why can't I write my iOS apps in python?

Transpiling languages like that nearly always ends up messy, and adds another layer of potential bugs to the system. Taking the time to learn the platform will end up better in the long run (at least with the current state of transpilers).

And as it stands, you can write Android apps with a native UI in Java, Kotlin, JS (React Native) and C# (Xamarin). And you if you want you can write business logic using any language that will compile to a C binary (using the NDK).

Re: It’s Been Real, Android: Why I’m Retiring from Android

#149
post #121

> Google’s adoption of gradle has been a disaster and proved to be a terrible decision. It did help out with some previous issues, namely multiple app targets, but it’s slowed down compilation severely. It also makes for masochistic configuration files with major redundancy and fragmented dependency hosts. Getting an app to compile shouldn’t be a challenge. The only thing worse than gradle is ANT, which it replaced.…

Moving to Gradle was a terrible mess. Ant was simple, effective and fast. Even now every time I fire up an Android build with gradle my laptop feels like it is going to fly. However Android has come a long way since the early days. The author focuses on the bad things we all know about. Android development is incrementally getting better every month. On top of that Android Studio is a way better development tool than…

I wonder, what's wrong with Gradle? I didn't develop for Android, but I use Gradle for plain Java projects and it's greatest build tool I've ever worked with. It's even better than Maven. Is it because of bad Android plugins?

Re: It’s Been Real, Android: Why I’m Retiring from Android

#150

Android should drop Java. It's nothing like writing 'normal' Java, and the baggage that is bought along isn't worth the effort. I like Java. I hate Android development.

Other than the slightly different standard libraries, what else is different? Android Java is effectively the same as java 7, and any difference is solely attributed to library/SDK/api.
Post reply on HN