
It’s Been Real, Android: Why I’m Retiring from Android - chx
https://raptureinvenice.com/its-been-real-android-why-im-retiring-from-android/
======
clumsysmurf
A while back, Dianne Hackborn famously said:

"We often see questions from developers that are asking from the Android
platform engineers about the kinds of design patterns and architectures they
use in their apps. But the answer, maybe surprisingly, is we often don't have
a strong opinion or really an opinion at all." (1)

While that may have been a lofty ideal, in practice Android has many strict
requirements on how you partition your code between Activity, Fragment,
ContentProvider, and Service classes. Never mind testability and all the new
semi-opaque / intelligent battery optimizations Android applies to your app.

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. This is a frequent and necessary thing to do, and also
quite awkward. The result is unnecessary complexity that often and easily
permeates the code. Dianne says they have no opinions on architecture, but
where I disagree is _concurrency is an architectural concern_ and there are
definitely many corner cases & snafus mixing that with Android APIs.

(1)
[https://plus.google.com/+DianneHackborn/posts/FXCCYxepsDU](https://plus.google.com/+DianneHackborn/posts/FXCCYxepsDU)

~~~
RivieraKid
> 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. (And the worst thing is that the documentation pretends like this issue
doesn't exist last time I checked. Newbie developers have no chance getting
this right, even experienced dev often ignore it.)

Overall, I wouldn't say Android is poorly designed, it's just mediocre, I
would expect more from Google. In general, I'd say the design lacks simplicity
and elegance. Some examples:

\- Fragments. Activities were already overly complicated and for some
mysterious reason they took it to the next level with fragments. (They should
get rid of or redesigned activities too.)

\- Older version of Google Cloud Messaging library - hundreds of lines of
source code to implement a basic hello world example (wth)?

\- Documentation is unclear in some cases, promoting some cargo cult patterns
such view holders (zero effect on performence these days). Also, services, if
you don't need IPC, the only "feature" of a service is that it lowers the
probability that the app gets killed. I usually just create a simple service
and start / stop it as a way to telling the system "don't kill the app".

~~~
0xFFC
>Overall, I wouldn't say Android is poorly designed, it's just mediocre

I think it is mostly have to do with company's talent pool and focus.

As far as I can see (I may be wrong, this is my estimate) Google tries hard to
devote best talents to 1) ads and Search and it's maintaining 2) Chrome team
3) Google apps and services online and on iPhones.

After these option they try to develop Android as kinda (I don't know what is
they correct word, so I am going with kinda) side project because they know
the world needs an open platform for competing with apples devices.

The reason because why Android is unacceptable from Google is we all used
Google's best products. Chrome and search and we kinda (by default) think
about Google as non fallible.

But that's nowhere near the reality, they have limited number of super smart
guys, and they try their best to keep core products (search and browser) much
better than competitors.

Most of the time when Google does release a new app their iOS apps is better
than Android's ones.

We would be okay if Android was from mediocre company. But it is not, it is
from Google , which is the best in some areas. But they don't have unlimited
talent. They are trying their best to balance.

I am not saying people who worked on Android are not that bright. No I am
talking about more broader picture. Of course there some excellent people who
work on Android. But I am not talking about 1,2 or three. I am talking about
management perspective in broader sense.

This is my personal understanding, I may be completely wrong.

~~~
macco
I really doubt that.

By the way, I think Android UI works much better than iOS's.

~~~
0xFFC
>By the way, I think Android UI works much better than iOS's.

You should be specific about what about Android UI is better than iOS?

if you are saying android UI design is better than iOS , I agree , but
remember Material design is not android's design. Google wants to expend to
every platform, it is quite childish if we think they could expand to every
platform without having professional UI design language for themselves. They
designed Material design for all of their product, not just for android. Yes
android was first one to adopt, and I really like Material design. So if you
are talking about material design , it was not _only_ for android, it was
actually Google Design language, and I really like it.

But if you are talking about performance and how ui fits together, I disagree
100% , for example they didn't had splashscreen for long long time (If I
remember correctly they adopt splash screen a year o two ago), every time you
were going to open an app, you were noticing a blank screen for quite a long
time some times(1,2 second) which was quite ridiculous. At the other hand iOS
had fixed splash screen for quite long time. Some third party apps tried to
develop splash screen of their own , but almost all the time result was not on
par (not even close) with iOS counterparts. Right now their rotation animation
have problems which can show itself under pressure. and so many thing I don't
even remember right now.

I am not saying android is bad or something , android is wonderful product.
But lets be honest, it is not core product for Google like chrome is, and it
has huge problems. But its main advantage is its openness.

~~~
vetinari
UI is not only design, but also UX.

One of big Android advantages are activities and intents. It allows for
application cooperation in a way that's not possible on iPhone. Even the
default app concept is based on intent handling - and that's why I can use
Firefox as my default browser, Nine as my default mail app and Sygic as my
default navigation and send stuff from other apps over Threema. On iPhone, I
would be stuck with Safari/Apple mail/Apple maps/iMessage no matter what
others offer.

This also affects integration from third parties. There's no reason for an app
to support just Dropbox, when there are intents, that all other services
support. Unless you want to artificially limit the integration, or you came
from iOS and are not used to that.

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

~~~
exDM69
> It's not unlike having people complain about JavaScript issues without ever
> looking at jQuery, React or newer tooling.

But this is exactly what makes being a Javascript developer a miserable
experience.

And I can give Javascript some benefit of the doubt since it's a multi-vendor
language with complex standardization processes and all the stakeholders have
their own interests and limited financial backing. By contrast, Android is a
single vendor platform with practically infinite financial and labor resources
behind it.

It's just a mess. I'd expect a relatively painless experience: install dev
tools, start a new project, build and go! But no, it's jumping through hoops,
requires understanding a myriad of different SDK/platform versions and a
constant churn in keeping your apps up to date with new versions while trying
not to break backwards compatibility.

And a big part of this mess comes from the fact that device manufacturers and
mobile operators are unwilling to keep old devices up to date (and Google
can't force them, while I think they should with some kind of licensing
contracts), leaving customers exposed to security flaws while keeping the
developers churn high with multiple versions to be supported.

~~~
izacus
You can open Android Studio, create a new project and "Go!". It'll work. Then
you can add a single line of code to dependencies and you get even better
APIs!

I also have no idea why are you mixing the device updates into the developer
tooling argument. New apps are (should be - and the tutorials tell you so)
developed with API 19+ in mind which means that you'll have to work for quite
a while to get any problems with fragmentation and updates. You can even start
development on API 21 and ditch support libraries all together and STILL not
shed significant amount of userbase.

~~~
27182818284
>You can open Android Studio, create a new project and "Go!". It'll work

I tried this after their 1.0 release and it crashed. Mileage varies from
person to person

~~~
V-2
I believe you, but Android Studio has come a long way since.

I agree it was abysmal at first - when it didn't crash, every new update would
break compatibility and your projects wouldn't build anymore etc.

Right now it's pretty decent, considering, although I'm not a fan of Gradle
either.

By the way, even though it's a fork of IntelliJ Idea, it's ultimately shaped
by Google which has sort of a tradition of realeasing alpha-stage software
into the world. Remember first releases of Chrome? I do; they crashed like
crazy and lacked basic functionality such as printing.

------
virmundi
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 end up making whole sub
sections of your product for a specific form factor.

I'm not saying that iOS is better. Don't really know. I've played with Swift
and a few of the Apple tutorials.

In general, I'm against the current incarnation of mobile. After years of
having an Android (and now having an iPhone due to work), I switched to a
Samsung Juke. That's right, a feature phone! The Android just got slower and
slower. No updates, not improvements. Finally it screeched in my ears while
working. I picked it up and slammed it on the desk (felt great for a week).
Both iOS and Android are slow, overly wrought operating systems.

That being said, unlike the author, I'll still use Android and iOS for my
products. I have products that need to be mobile. They have to target the
machines my customers have now. That also means that I'll have two native app
code bases. I'll have to keep track of native app UX/UI standards. I'll have
to keep such hardware around ('cause Android's emulator is still sucks when
I've got an VM running).

~~~
m_mueller
I was surprised to learn that Android in 2016 doesn't even natively come with
an equivalent of JavascriptCore. You have the pleasure of somehow getting V8
to run and then serialize/deserialize all your native objects manually in
order to talk to it if you want javascript outside the browser. Really? From
the company that is the most web native around, and even developed the most
common browserless JS runtime (V8)?

Google's user faced architecture often just seems like an unmanaged jumbled up
bunch of code that they throw at you, good luck have fun.

~~~
zeveb
> I was surprised to learn that Android in 2016 doesn't even natively come
> with an equivalent of JavascriptCore. You have the pleasure of somehow
> getting V8 to run and then serialize/deserialize all your native objects
> manually in order to talk to it if you want javascript outside the browser.

That's a little bit like saying that Chez Panisse doesn't even deliver sewage
to your table, and that if you want to pour it over your food you need to
bring your own chamber pot with you.

Java is not a great language to program in, but if there's any language it is
clearly better than, then that language is JavaScript. Why would one want to
program an Android app in JavaScript rather than in Java?

There's only one reason to use JavaScript: because one is deploying in a
browser, and JavaScript is the only language supported by the vast, _vast_
majority of browsers. In every other way, it's a misbegotten mistake of a
language.

~~~
m_mueller
The big reason: Cross platform compatibility. Not just between mobile
platforms, but even between mobile devices and webservers. Our devices are so
powerful now that you can run a full blown webserver on it if you choose your
DB system wisely. That's why we use CouchDB - replace it with CBL on mobile
and take your whole webapp with you for offline use. I'm Swiss - we have lots
of tunnels ;-).

------
tananaev
I think there are no developers that are true experts in both Android and iOS
platforms. Every developer I know either leans towards one platform or
another. There are also developers who know both platforms pretty well, but I
won't call them experts in either.

I consider myself an expert in Android development. The only point that I
agree with is multidex, but there are historical reasons for the limitation
and I think Google engineers are trying to fix this problem or make it as
simple as possible to use multidex.

I occasionally do iOS development and some things in iOS don't make sense to
me, but I'm sure they would be obvious for an iOS expert.

My advice for mobile developers or future mobile developers is to specialize
in a single platform that you like more. For me it's Android. For the author
of the article, it seems to be iOS.

~~~
tluyben2
I am an expert in iOS dev but I use and want to like Android. It is quite
annoying... I really do not like the walled garden of Apple and on Android
devices, even cheap MTK ones I am quite handy at installing what I want, but
for some reason I find Android development a real pain compared to iOS where I
find most older things (stuff, as it goes in life, needs to mature) very
obvious and easy.

I would say what most annoys me about iOS is the GPL thing which is the
reason, among others, there are no emulators in the Appstore, at least no
relevant ones. As owner of a museum and fan of old machines I cannot do
without emulators. On my Android tablet I have around 50. Emulators is a niche
but no GPL is hampering a lot for everyone on iOS.

~~~
TheCoreh
The GPL incompatibility issue has nothing to do with Apple not allowing
emulators. (After all there are BSD/MIT emulators) They don't want (non-
sandboxed) interpreters running unreviewed code. Right now the only
interpreter allowed to be used with downloaded code is webkit's JS JIT.

~~~
tluyben2
There are multiple reasons as I said: one is the one you say but some
emulators I use are under the GPL and use many GPL libs.

But yes the other restriction sucks too. The point was cannot normally use
emulators under iOS which stands, whatever the reason may be.

~~~
tluyben2
For instance [0] which I use by far the most has both problems; however with
another license the runtime issues would be fixable. For instance, recompile
the runtime with emscripten. Luckily there is webmsx now which looks
promising, but that is not there yet.

[0] [https://github.com/openMSX/openMSX](https://github.com/openMSX/openMSX)

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

> Wait, what is picasso? Oh wow, I hadn’t heard of that one…I was busy
> learning Swift.

I just minimize the amount of platform specific tech in the codebase as much
as possible. RxJava? That's going to be _real_ fun to port...

Ahh, this didn't even touch on my least favorite part of Android - command
line tools that tell you they've "successfully" deployed APKs. And returned
successful return codes. That in reality silently failed due to ever so
slightly loose USB connections.

On the plus side, they finally fixed
[https://code.google.com/p/android/issues/detail?id=197287](https://code.google.com/p/android/issues/detail?id=197287)
in Android 7.0 it looks like...? I'm trying to remember if that was the bug to
blame for my last 16 hour day...

~~~
rifung
> 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

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

~~~
pjmlp
Except many of us are comfortable with XML "craziness" and see no value in
Gradle besides wasting battery.

------
mahyarm
We adopted buck at work for android & objective-c ios and it's been amazing
speed & low-bullshit wise:

[https://buckbuild.com/setup/getting_started.html](https://buckbuild.com/setup/getting_started.html)

If gradle is killing you, I would suggest trying it out.

Warning: we have a few guys in a mobile developer experience team, so I don't
know how good it is for indies.

~~~
iainmerrick
I have the opposite experience -- I tried Buck because I really wanted a
Blaze/Bazel clone (it wasn't open source at the time). It works but I find it
very slow.

My project involves lots of native code and genrules, though. If you're mostly
building Java code I imagine Buck might work well. If starting from scratch I
would try Bazel first.

~~~
krschultz
Buck's speed improvement is heavily dependent on breaking your code into
modules. What was your project setup like?

~~~
iainmerrick
I have 2300 lines in about 40 BUCK files, plus 500 lines in 2 DEFS files. Just
parsing the BUCK files seems to take an inordinate amount of time (tens of
seconds from cold).

------
cyberferret
I found that as I get older, and still try to learn different languages and
platforms, that I have to try and work on my research skills as much as my
coding skills.

As the OP pointed out - straddling several languages means that syntax and
keywords are not always readily apparent when you sit down to code, but
knowing where to look for them and refresh your memory quickly becomes an
activity all on its own.

This from a guy who is a week away from being 50, and still occasionally puts
a ';' at the end of his ruby code blocks.

~~~
shoover
I always thought those language/framework/library cheat sheets were for
newbies only, but I'm beginning to see that's not entirely the case.

------
seibelj
Unless you are writing a Tier 1 application that needs every fancy do-hicky, I
don't see the point of 100% native anymore. Use React Native, then if
necessary have a devoted native developer for each platform to handle parts
that absolutely have to be executed in native and provide a JavaScript API. If
you are a big company with tons of money, sure, create duplicate teams to make
the same app for each platform. But if you are small or just starting, React
Native is the best choice.

~~~
copperx
I'm all for write-once-deploy-everywhere, but React Native is better suited
for apps that could be easily written web-only. Maybe I don't get what's
better about React Native over a native app that is just a web view.

~~~
naiyt
> Maybe I don't get what's better about React Native over a native app that is
> just a web view.

It's better because React Native is actually rendering native components.
Stuff like PhoneGap never feels or works quite right as a side effect of being
rendered in a web view.

~~~
wingerlang
I think his point is - why make a native app that just re-renders the data
which you can just as well look at in a browser.

~~~
suprfnk
Next to the fact that something like push notifications require a native
implementation, people like apps more.

I'm currently working on a way to make our mobile-tailored website into an
app, just because customers keep requesting a _real_ app instead of a webpage.

------
credo
Like the op, I do both iOS and Android development work. However, as an indie,
my platform preference is primarily market-driven. So most of my work has been
on iOS

Unlike the OP, I like and use Android AsyncTasks. I have no problems with
Android fragments either.

However, I did have a lot of other concerns with Android - primarily the low
quality of Google's SDK for Android. Here is what I wrote about it
[https://blog.cascadesoft.net/2013/12/31/the-bigger-
problem-w...](https://blog.cascadesoft.net/2013/12/31/the-bigger-problem-with-
android-bugs-and-quality-not-fragmentation-per-se/)

~~~
popmystack
>primarily the low quality of Google's SDK for Android.

This has always been my biggest frustration with Android. I've written a few
applications for the platform, and while their architecture leaves a lot to be
desired I've never had any real problems with it. However, the immense
disappoint and anger that comes from their SDK idiosyncrasies is astounding.
Google really just hates stability and nice API's, in my opinion. Everything
from GAE to Android, it's always just so terribly frustrating to keep track of
any one-off decisions they make without any form of actual communication from
the development team.

I've been writing Android code since the G1 days.

------
chickenbane
I do not think writing Android apps is straight-forward and would not
recommend it to new developers or engineers like the author who want to do
other things like iOS. People's expectations for apps is only getting higher,
and there are many, many things you need to understand in order to be a
produce great Android apps.

As an example, another commenter noted the Android platform engineers not
being opinionated about application development as a "lofty ideal", but more
likely this is a consequence of the framework team having enough on their
plate. The vanilla Java AOSP API surface (not even considering the NDK,
support libraries, Google Services, etc.) is enormous. The Activity lifecycle
is complicated, and it's very easy to leak memory or write spaghetti code.
There are many ways to do similar tasks, and these also change with time. Etc.

That said, I love being an Android developer, and it is improving at an
accelerated rate. To start, Android Studio and Gradle are far superior to the
pain of getting Eclipse, Ant and the SDK tools working together.

Yes, Swift is awesome and shiny, but there is so much more to a platform than
the language. Java has excellent tooling - great support for debugging,
monitoring, automated testing for CI/CD (automated UI testing still needs
work, but also improving), static analysis, etc.

The support libraries are also a godsend, enabling you to make an app that
looks modern while being frequently updated and handling a lot of the
compatibility headache from the platform's diversity.

Finally, there's a lot of great content online. The conferences are great and
its expected to see their content on YouTube. Google's Android Developer
YouTube channel is also fantastic (shout out to Jo and Ian!), and Google is
slowly but surely improving the developer docs and integrating their sample
code into Android Studio.

So yes, you do need to understand the new functional reactive approach. You
need to know how to write a Gradle build. You have to understand the
complexities of proguard rules. It's all pretty frustrating. But I also feel
that many of the skills are more easily transferrable - I can also write a
Gradle build for a library or I can use IntelliJ to better debug a servlet.
With Swift and iOS, there's only vendor you can build for.

~~~
taplogger
> So yes, you do need to understand the new functional reactive approach. You
> need to know how to write a Gradle build. You have to understand the
> complexities of proguard rules. It's all pretty frustrating. But I also feel
> that many of the skills are more easily transferrable - I can also write a
> Gradle build for a library or I can use IntelliJ to better debug a servlet.
> With Swift and iOS, there's only vendor you can build for.

I couldn't agree more. Android experience is hard-won. You have to 'discover'
and develop an intuition for application architecture and how to use UI
components effectively over time.

The upside is a well-architected Android application --using tools like MVP,
dependency-injection, and functional-reactive programming-- will have the
positive characteristics of a Service Oriented Architecture: encapsulation,
statelessness, composability, loose-coupling. This may seem like overkill for
an app, but it minimizes the effect of UI lifecycle issues novice and
intermediate developers tend to complain about.

Architect a few Android applications in this way and you gain valuable
experience composing abstract services together. A competency that is
transferrable to backend services and other platforms.

~~~
omegaworks
Any resources you'd recommend in particular to learn FRP and how it applies to
Android, specifically.

As a frequently frustrated intermediate developer I'd greatly appreciate it.
I've just begun using RxJava and Robospice to tame my server endpoint call
logic, but I know it's just the tip of the iceberg.

~~~
taplogger
It's taken a few false starts and experiments for me to become comfortable.
Eric Meijer is an excellent resource for understanding the theoretical
underpinnings and the 'why' of it all.

Soundcloud has a reasonable and practical approach on Android:
[https://www.youtube.com/watch?v=R16OHcZJTno](https://www.youtube.com/watch?v=R16OHcZJTno)

A good bet is to search Github for projects where common Android APIs or
libraries are Rx-ified. You'd be surprised at the economy and simplicity of
code you can find in some of the best Rx implementations.

------
ryandrake
Without mentioning which platform(s) I prefer, I have to agree with the
author. On one hand, it's nice to be able to work cross-platform, and
architecting your app such that you maximize code sharing is a worthy and
satisfying goal. But quite a bit of code (the UI mainly) cannot be shared and
it's kind of tiring to finish your Platform A app, look at it with pride, and
then face the need to essentially re-write the exact same thing for Platforms
B and C, only in different languages and frameworks "because platform
competition". You're splitting your attention, expertise, time, and learning
N-ways.

~~~
rhizome
I don't get it. How can there then be all of these weekend tossoff games in
the Play Store that work just fine? Unless I'm unclear on what you mean by
"platform."

~~~
seibelj
An app that uses native UI widgets is very different from a game which uses a
graphics engine. The game compiles cross-platform with minimal changes.

~~~
praneshp
Can you point me to a good resource for "a game which uses a graphics engine".
Last week, I built both an android app and an iOS app, and would like to build
something that compiles cross-platform to complete the set.

~~~
TylerE
I would assume he is talking about something like Unity.

~~~
striking
Or Godot, or Love2D, or many other open source game engines with both desktop
and mobile functionality.

------
rcheu
I've been doing Android development since the G1 release. I agree with most of
these points, but think they're also not a huge deal after you've been working
with the platform for awhile. The biggest issue is by far the iteration speed
though. Build/install take way too long--Android Studio for some reason takes
15 seconds to start my app even if no changes have occurred.

Instant run is supposed to solve this, but it's too buggy to be useable right
now. Sometimes your changes just don't apply, but you never know if that
happened or you messed up your fix.

I actually preferred ant since I better understood what it was doing. Gradle
error messages are often very vague and confusing, and build times are
strangely inconsistent.

------
exanddevxyz
What is surprising is that google with their much celebrated hiring practices
for senior devs managed to hire no one who could say no to such insanities
like Fragments and Async and the entire Android dev platform/toolkit as it
stands today.

Apple, formerly famous for being design hippies who couldnt care less about
performance, have topped the mobile performance charts for nearly a decade
straight now and with no end in sight. An entire decade! They merely had the
wisdom of not choosing java to base their platform on.

~~~
ec109685
Where do you base you claim about apple not caring about performance? They
have pushed the performance envelope ever since the first Apple computer where
Woz built it with way fewer chips than their competitors. Their ui's have
always demanded extreme performance.

------
Ologn
I don't think lifecycles, phone rotation etc. are much of a problem, because
once you know them, you know them.

I think the problem is Android keeps changing the current best practices. I'm
not even sure how to know what those are - if you enter code from the Android
tutorial into Android Studio, much of it is deprecated.

In January 2011, the way to do tabs in Android was via LocalActivityManager.
Then in February 2011, ActionBar.Tab was added. By July 2011, the
LocalActivityManager way was deprecated, and ActionBar.Tab was was pointed to
as the way.

Then in November 2014 with the release of API 21, ActionBar.Tab was deprecated
(
[https://developer.android.com/reference/android/app/ActionBa...](https://developer.android.com/reference/android/app/ActionBar.Tab.html)
). So what do we do for tabs now? Who knows? The most current tutorial (
[https://developer.android.com/training/implementing-
navigati...](https://developer.android.com/training/implementing-
navigation/lateral.html#tabs) ) is still telling you to do it in the way that
was deprecated two years ago.

That's what is maddening with Android - they have a way to do tabs, add a new
way, deprecate the old way within five months, then three years later change
their mind and dump the new way - without changing the documentation and
telling you the new way to do it, it's all just deprecated.

The tutorial is full of deprecated code. What's the new way to do it? Who
knows?

A few years ago some corporate director at Google must have gotten a directive
to push Google TV. So then they were pushing all apps to work with Google TV.
I guess that fizzled out. The latest thing is making sure our legacy apps work
with Chromebooks which allow multiple apps on the screen at the same time.

I don't mind Google and Android continually chasing the new shiny, but I wish
they wouldn't have a tutorial full of deprecated code, I wish they didn't
change how they do things such as tabs every three years (three new ways to do
it in three years). I wish they fixed bugs instead of implementing new
features. On code.google.com, developers post bug reports, then many other
developers jump on saying they see the same thing, and...a few years later, it
just closed for being obsolete.

Another example of continuous churn - Google Analytics looks like its going by
the wayside, to be replaced by Firebase. Admob is now integrated into
Firebase. So that's a whole other thing that needs to be redone in an app. You
have to run to stay in place.

~~~
taneq
I've only dabbled in Android but this is what drives me mad. I spend a month
digging in and learning "how to develop for Android" and then six months later
when I go to use that knowledge for my real job, everything's changed. What
was best practice last time I looked is now frowned upon, deprecated or flat-
out broken, whole generations of new best practice have churned by, and
current 'best practice' isn't compatible with any handset more than three
months old.

If you're doing it 40+ hours a week then maybe the ongoing investment is worth
it but to me it's a colossal waste of time.

~~~
copperx
I feel that way about most of the development world.

------
georgeecollins
Gradle has problems, but it doesn't seem worse to me than making builds in
Eclipse was. I would love to hear why people think it is better or worse.

I agree multidex is terrible. Google please fix this.

I do not know when I should use a fragment instead of a view. I know the
layout reasons google gives in their developer guide but I don't think I have
seen a piece of code that really uses fragments that way. So why?

I do like Android development though.

~~~
fractalwrench
Gradle is just incredibly slow on Android compared to Eclipse. particularly
with larger projects. Instant Run has helped alleviate this to some extent,
but it's still not uncommon for a build to take 2+ minutes.

I guess this is mostly due to all the resource crunching that Android does,
and the fact that Android Studio doesn't perform incremental compilation by
default.

Another annoyance is that every time a minor change such as incrementing a
version number is made, Android Studio grinds to a freeze syncing gradle
files.

~~~
AstralStorm
Incremental compilation seems to be on for newest release of Gradle, but
Android is still on 2.x due to the plugin.

For our project, the most time consuming part is... Packaging. Making apk
splits is slow, why does it zip the whole thing again if it is just replacing
resources?

~~~
vardump
> why does it zip the whole thing again

Maybe fragmented zip files with holes inside are undesired? Because that's
what you get when modifying zip files in-place.

------
rtpg
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 current tooling environment is soooo impossible to wrap ones mind
around.

~~~
GeneralTspoon
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).

~~~
rtpg
So the multidex issue I was referring to makes it pretty hard to write things
that will compile to C with the NDK.

In order to get any access to the Android APIs, you have to do C-JDK bridging
through JNI. And in android VMs, there's a _hard limit_ on the number of
symbols you can reference in the lifetime of an app.

It's the equivalent of if python was like "yeah you can use the standard
library, but only up to 100 functions!"

iOS, since it goes through the LLVM framework stuff, doesn't have that many
barriers to transpiling from other languages. You can just do raw function
calls to the OS libs. But Android doesn't allow this, forces you to go through
the JNI, and makes you have to work around this symbol limit.

------
cageface
iOS has plenty of developer pain points as well, although in their case a lot
of them are as much a result of dumb Apple policies as they are technical
mistakes. I'm going the other way. After six years of iOS work I've had
enough. I still think the web is the smart long term bet so that's where I
intend to focus my energies.

~~~
copperx
I agree. However, I would have never thought that developers would be so
miserable in 2016. Say what you will about the desktop; developing for it was
a pleasure (except for you, Win32 API) compared to what we have in 2016.

~~~
rpeden
The sad part is that things were looking pretty hopeful in 2008-2010.

I particularly liked Cappuccino. It's basically a port of Cocoa to the web.
You could design your interface in OSX's Interface Builder. The project is
still around and is still being worked on. Sproutcore was pretty similar, and
is also still around. Neither of them are being developed as heavily as React
or Angular 2, but they have both been mature for a long time, and perhaps
don't _need_ a lot of work to be done on them.

Maybe it's just me, but I still find 280Atlas[1] and 280Slides[2] more
impressive that many web apps that ship today, and they're nearly 10 years old
and ran in browsers far slower and less capable than what we have now.

I actually think more developers would frameworks like these if they didn't
feel they had to stay on the latest and greatst JS treadmill to remain
employable. And I write that as someone who _likes_ React and Angular. They're
both sane ways to develop complex apps, but they don't feel _that_ much better
than what was possible 8 years ago.

[1]
[https://www.youtube.com/watch?v=ouzAPLaFO7I](https://www.youtube.com/watch?v=ouzAPLaFO7I)
[2] [https://www.youtube.com/watch?v=tMZwfh-
_QEQ](https://www.youtube.com/watch?v=tMZwfh-_QEQ)

------
tn13
When I started development on Android platform I was told that we should not
do IO on UI thread. Fine enough. What is the alternative? Every tutorial out
there including Google's suggested AsyncTask.

Only after few weeks I learned that we should never use AsyncTask for IO
because internally it uses a threadpool of hold your breath 2 threads !

So how do I make all my REST requests ? Through something like Volley. This
library is even more disgusting as it does not support some simple urls such
as [http://example.org/?id=1&id=2](http://example.org/?id=1&id=2).

So I turned by focus on Services only to learn later that Services are meant
for background tasks but run on UI thread.

The best approach to do your own IO is through IntentServices. Something that
should have appeared in the first tutorial.

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

~~~
creshal
Do you still need to do manual malloc/free inside Java code to handle images
in Android? That crap tripped me up when developing for it ca. 2011.

~~~
pjmlp
Yes, they optimized it and did a few changes in the way things work, but you
still need to watch out.

[https://developer.android.com/training/displaying-
bitmaps/ma...](https://developer.android.com/training/displaying-
bitmaps/manage-memory.html)

------
wiradikusuma
The link from HN redirects me to [https://raptureinvenice.com/its-been-real-
android-why-im-ret...](https://raptureinvenice.com/its-been-real-android-why-
im-retiring-from-android/wp-admin/install.php) with this error:

The raptureinvenice.com page isn’t working -- raptureinvenice.com redirected
you too many times.

Anyone having same problem?

~~~
dingdongding
Yes. I faced similar problem so I went to Google Cache.
[http://webcache.googleusercontent.com/search?q=cache:https:/...](http://webcache.googleusercontent.com/search?q=cache:https://raptureinvenice.com/its-
been-real-android-why-im-retiring-from-android/)

------
tabulatouch
I've never been an Android developer, but i am happy Xamarin (Forms)
developer. It is not without some hassle, need to deal with a little amount of
platform-specific code, but it's the way mobile development should be in 2017.
Code the experience and functionality, do not loose (too much) time on
platforms.

~~~
pier25
Last time I checked Xamarin Forms about a year ago it was still limited.

Is it better now? What are some of its limitations?

~~~
rpeden
It's still limited in that it's not a good choice if your app requires UI
functionality that is very platform specific. I think that's intentional - it
isn't intended to be the right solution for every application.

It's still a good choice if your app mainly involves displaying lists and
tables of text and images, and data entry forms. The cross platform Map
control works quite well too.

I don't remember exactly what is different now from a year ago, but if you
list a few of the limitations you faced, I can tell you if they still exist. A
quick look at the Pages, Layouts, and Controls section of the Xamarin Forms
page might tell you if they've added things that were missing last time you
tried it: [https://www.xamarin.com/forms](https://www.xamarin.com/forms)

~~~
pier25
Thanks for the info. From what I've seen things haven't changed much. The idea
still seems to be that Forms is for simple apps that use a number of common
components.

~~~
rpeden
Yeah, it is similar to React Native ins that way. There's a limited set of
cross platform components. In both Xamarin and RN, though, you can also
include your own platform-specific components/plugins when necessary.

------
lucb1e
At least Android doesn't require me to buy a Windows license or Mac computer
(not just the license: OS X requires Mac hardware which is notoriously
expensive). I'll keep it at Android.

------
krschultz
I was an Android developer, then flipped to being an iOS & Android developer.
I chose to go back to solely Android for similar reasons to the OP. It felt
like it was impossible to be excellent on both platforms. I was struggling to
keep up with the pace of change.

I ended up choosing Android because I found more demand for Android developers
in the market. I certainly understand some of the OP's frustration with
Android development.

~~~
cloudjacker
Oversaturation of iOS devs. Many people chasing the perceived glamour,
diluting each other's pie.

There's a lot of silver lining to doing android development for other people.
Inflated demand, and all the client side - server side fires have already been
put out when the company did the iOS project. So I would say, easier or less
stressful.

But I've been at this for a while, so there's the possibility I'm just good at
it.

------
thirdreplicator
Given all the grief expressed in the post and the comments, it seems like if
someone architected a really nice, developer-friendly native mobile API for
_any_ platform you would get droves of devs flocking to it.... Despite the two
major players, the market seems wide open as long as they focused on the
development experience like what Matz did for Ruby... Programmers are
customers too! :)

~~~
JamesBarney
I've heard a lot of praise for the Windows phone developer experience, but
what really matters is the audience. Dev's flock to the audience. Even just a
small pay difference will dev's to deal with the most terrible of developer
experiences(ex. Sharepoint)

~~~
pjmlp
I do hobby coding between Android and WP, and do love the experience.

Microsoft might have lost the mobile war, but they are on good track to win
the hybrid laptops one.

------
cel1ne
Allow me to repost two of my rants against android from a while back:

[https://news.ycombinator.com/item?id=8328646#8329034](https://news.ycombinator.com/item?id=8328646#8329034)
[https://news.ycombinator.com/item?id=9475825#9476547](https://news.ycombinator.com/item?id=9475825#9476547)

------
lubonay
I like comparing iOS to Android development as similar to playing Mario Kart
and Dark Souls... It truly is a mess and I won't be surprised if/when someone
releases an Android SDK SDK (SDK squared!) that generates all the horrible
boilerplate so that you can start a network request, rotate your device and
get the result in your view with no additional headaches.

------
ojm
Cached version as it is down:
[https://webcache.googleusercontent.com/search?q=cache:dFoTDF...](https://webcache.googleusercontent.com/search?q=cache:dFoTDFe6w1AJ:https://raptureinvenice.com/its-
been-real-android-why-im-retiring-from-android/+&cd=1&hl=en&ct=clnk&gl=au)

------
keyle
I get a 404 on that article. Maybe the DB is having issues still. A cache here

[https://webcache.googleusercontent.com/search?q=cache:dFoTDF...](https://webcache.googleusercontent.com/search?q=cache:dFoTDFe6w1AJ:https://raptureinvenice.com/its-
been-real-android-why-im-retiring-from-android/)

~~~
zouhair
Or here [http://archive.is/girlg](http://archive.is/girlg)

------
gagabity
As an Android only Dev I cant disagree with any of his reasons, the tools
especially are just terrible, its not unusual to spend hours trying to figure
out why my project will not build, this is compounded if you live in a country
with poor internet connectivity, GB sized updates to the tools are not fun.

------
arviewer
I get redirected to the Wordpress install page, which cannot connect to the
database?

[https://raptureinvenice.com/its-been-real-android-why-im-
ret...](https://raptureinvenice.com/its-been-real-android-why-im-retiring-
from-android/wp-admin/install.php)

~~~
cerebellum42
I just get infinite redirects.

------
amelius
I'm not an Android developer, but I've seen my Android phone and tablet
greatly deteriorate in performance over the last couple of years, mostly due
to Android updates which were forced on me. I rarely use my tablet anymore
because of this.

~~~
facepalm
That is the same with all computer platforms, though. I think it is OK if
companies have a limited time of support for their OS, but you can debate how
long it should be. With Android, it is also the responsibility of the phone
manufacturers, not just Android/Google alone.

~~~
e40
This is certainly true of Windows (which I don't use anymore on the desktop).
Until as late as Windows 7, I would do a wipe/install every couple of years,
just to get my performance back to the way it was after a fresh install.

I haven't done with this macOS, but I've heard of people doing this.

~~~
facepalm
Even with many Linux distibutions you can't run the latest version on older
Computers anymore. But at least you can probably find a special Linux for
older hardware.

------
digi_owl
After writing a comment elsewhere i find myself wondering if why iOS is
preferred, is that once an app is launched the app can behave pretty much like
they could back in the dos days.Each app its own island, having the run of the
device until the user hits the home button.

Android on the other hand is more about stitching apps together into a larger
whole via intents. Thus you have not not only care about what the user will
see and interact when tapping the icon in the launcher directly, but also when
getting a intent from another app.

And most Android apps seems to fail on the latter. Various IM apps and such
have been notorious for not going back up the intent chain when hitting the
back button.

------
vans
The comparaison with JS is perfect. Like JS is the asm of the web ecosystem
(no one wants to write its code just in JS, we generate it instead), default
android and IOS way of programming have to be be generated.

Try Xamarin [0] or the newcomer flutter [1]. It's such a pain in the ass to
dev in raw android or raw ios, use multi platform sdks.

And if you start with xamarin, you can target windows phone too, even if
nobody cares ;-)

[0] [https://www.xamarin.com/](https://www.xamarin.com/) [1]
[https://flutter.io/](https://flutter.io/)

~~~
rmsaksida
I've had some terrible experiences with Xamarin. The tooling is very
rudimentary compared to Android Studio, performance is subpar, app size is
huge, and development is so slow it's maddening. I wouldn't recommend it other
than for some very specific use cases. I'd much rather deal with just plain
old Android issues than wrapped-by-Xamarin Android issues _and_ Xamarin-
specific issues.

------
tarr11
Interesting, I have avoided much mobile development for the past decade for
the same reasons OP mentions.

However, I have been drawn in by the promise of React Native, which addresses
compilation time and cross platform concerns.

------
nurettin
I've recently been dabbling with the new android studio 2.x and It has
improved considerably in the past 3 months.

For a single application all I need is:

\- A main activity where I commit fragments to show stuff

\- A settings activity foryouknowwhat

\- A main application class to store all the data and state

\- Some model classes for downloading/parsing/storing/data

\- A service that can be used from my main activity and notification manager

I've been at it for a few months and the experience hasn't been as terrible as
described. (Yes I do have async tasks that update the UI)

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

To be fair iOS dependency management is also a huge pain. CocoaPods is worse
than working with Gradle in my opinion.

------
shams93
For me I quit android studio to use aide to develop directly on the device. I
got the remix os tv box for $50. I got fed up with needing and ultra expensive
machine to develop my free software. I don't profit from Android but aide
enables me to continue to contribute free apps without bankrupting myself to
run an expensive development machine to do hobby software.

------
pier25
Mobile development in general is a pita.

We really need a native cross platform solution that doesn't involve either
running a JavaScript VM (ReactNative, NativeScript), writing UI code for each
OS (Xamarin), and doesn't rely on a WebView.

Xamarin Forms could fit the bill, but last time I checked it wasn't there yet.

What other option are there?

~~~
dmix
Has there _ever_ been a cross platform solution in history that was superior
to the native development platform unique to the OS? This seems to be the pipe
dream that everyone repeatedly hopes for then gets burned.

I'd actually prefer if Apple and Google had their own development platforms so
there are competitive driving forces to improve the platform. It will also
accelerate experimentation with new tech where one platform can validate one
tech so the other can adopt it quicker.

Then if you have a simple lightweight app you can use some form of cross-
platform browsery JS app (about the only point where this makes sense).

~~~
pier25
Superior? Depends on what you are doing.

Working with game engines is a joy since you write "client" code, so to speak,
and the engine is compiled for each platform.

QT is also really good, but also really expensive, and you lose native UI
which can be a good thing or not depending on your use case.

NativeScript is working on becoming a universal cross platform solution
similar to ReactNative. It's already on mobile, and I've read there is a macOS
version being worked on.

------
ausjke
I worked on android for 3 years, then did something else for 3 years, now am
back to Android, there are so many vendors selling android phones, so it shall
work just fine I assume? or is it getting much worse for developers(system and
app developer) these days?

------
colund
I think it's good to remember that it goes both ways
[https://twitter.com/devunwired/status/786542912469213184](https://twitter.com/devunwired/status/786542912469213184)

------
macco
I like Android development with React-Native and Clojure.[1]

But this probably doesn't fit the bill for prof Android developers.

[1] [https://github.com/drapanjanas/re-
natal](https://github.com/drapanjanas/re-natal)

------
z3t4
I see two types of dev methods 1) Write it all down, read through the code a
few times. Then compile and do a full test. 2) Write in steps, compile and
test after each step. The later is a Pita on low level. And produce more bugs.

~~~
newscracker
Regardless of the platform, for any application with a non-trivial amount of
complexity, iterative development is the best approach. I don't understand how
anyone could "write it all down, read through the code a few times and test"
and not produce a buggier application that doesn't meet most expectations. It
does help to do some initial design work, create abstractions, loose coupling,
etc. Iterative development does not mean jumping into coding without a high
level plan on how to create the application pieces and how things would work
(or do what's called as "cowboy coding").

With the amount of complexity involved in developing applications, considering
the architecture, design, interactions between application components, error
handling, different classes of platform APIs, UI, UX, state management,
concurrency, hardware configurations to support, and many other things, I
doubt if any human could really keep all that in one's head and really work
through all the possible ways that assumptions during coding would get beaten,
when compared to a real execution of the application and using that practical
feedback in changing, fixing and improving things.

~~~
spdionis
You are confusing scopes here. The parent almost surely meant those approaches
applied to a single task (meaning a few hours to a day of work), not to
building an application.

~~~
newscracker
Being pedantic - the parent was commenting on the article, not on a comment
here dealing with a single task or one small piece worth a day's work. I see
no indication on how you could make a statement saying "...almost surely
meant..." Based on the information available, either of our premises could be
true.

~~~
z3t4
The authors main complain was that it takes two minutes to start the emulator.
And I agree that it is a Pita. But as a mental exercise or fun experience, you
should 1) Picture it in your head 2) Make a plan 3) Write it down 4) Read
through it and fix errors 5) Test it on the emulator.

You could start with a small ten minute fix, then work your way up. The
feeling when it compiles and just works on the first try is amazing.

------
aw4y
oh you'll be missed. I've worked on Android for ages, I don't remember in the
last 3 years of one single AsyncTask I've used.

------
chajath
What takes 3 hours for ios development takes 3 days for Android. Things are
little bit better now that android studio is maturing, though.

------
xHopen
I did the same years ago, I had to decide and... well iOS is a paradise
compare to Android

------
StreamBright
Sorry for my ignorance, but wouldn't React Native help with these sort of
problems?

~~~
rimantas
React Native does not help with any sort of problems.

~~~
cageface
If you need to build an iOS _and_ Android app and you don't need to really
push the envelope on design then React Native is a godsend. It's not the right
solution for everything but for that vast array of apps that are mostly just
list/tableviews talking to a REST backend it's a massive timesaver.

I've been doing native iOS work for six years now and I'd still recommend RN
over straight native for a lot of projects.

------
ClayFerguson
Developers do need to pick a set of core technologies, and stick to it or a
career can fall apart I bet. I don't know from experience. I've been a Java
DEV ever since MSFT tried to hijack the Java language with a proprietary
version back in 1998, and I abandoned MSFT and never went back. I can imagine
trying to be both iOS and Android developer would be about as insane as trying
to be both .NET and Java developer. Oil and water. Doesn't mix. For me there
is one and only one word that i need to hear to know I want to avoid iOS:
"proprietary". I wouldn't touch any Apple product with a 10ft pole. I like
open systems, and Apple is all about maintaining their closed little private
invite-only walled-garden of an ecosystem. No thanks. They may be successful a
while longer but "open" ALWAYS wins in the end.

~~~
echelon
> Developers do need to pick a set of core technologies, and stick to it or a
> career can fall apart I bet.

How boring! I'd go mad if I didn't get to work in new domains with different
tools every so often.

~~~
collyw
Every so often is OK, but every a new language / set of technologies with
every app means you will be writing junior to intermediate level code every
time.

When we are interviewing and I see CV's that have so many technologies listed
that I am fairly sure they have very little depth of knowledge to many of
them.

~~~
pjmlp
Or worked as consultants.

On our case we are required to stay flexible and take whatever projects come
when one is released from a project, it is not always possible to say "I don't
do X".

So every few months there is a new stack to work on.

------
EddieSpeaks
Which is Why he should move to Xamarin. Xamarin Forms can let him maintain one
codebase over multiple platforms and leave the rest to convention

------
caretStick
Librarians often don't realize that they can't keep plugging in method bodies
and get what they want forever. Engineering isn't f&@!ing Madlibs for Christ's
sake. Learn to build things that will work 100% of the time and never
compromise!

------
cloudjacker
lol, I've had those sentiments

employers are also skeptical you are content with both, I wouldn't consider it
a value add unless you can land a lead position for a mobile team

aside from working on multiple platforms diluting your experience with the
latest development patterns, it is just as easy to be stuck maintaining an old
project or legacy code with an employer. This isn't unique to mobile of
course, but multiple platforms really exacerbates how fast it happens.

~~~
cloudjacker
*competent, not content

------
simophin
i have to say, refusing/unable/lazy/ to learn is the most terrible thing ever
happened to a developer. I'm always excited about new things even I have to
learn them hard, even they start with poor quality, but I believe these are
what make developers happy

~~~
Zyst
I feel you are concentrating on a very small and negative part of the post in
a very disingenuous manner.

I read the article more as: "I have found throughout the years I've become a
decent programmer in iOS and Android, I'd rather be a good or excellent iOS
developer."

The end just briefly describes why he decided to go with iOS instead of
Android briefly, but that's about it.

------
ensiferum
Yeah well, Craproid APIs are awful. It's gotten marginally better in tooling
(the new IDE framework shits itself like only half the times compared to the
Shitclipse based one), but there's still just too many brainfarts in the APIs.
And ofc the implementatations are super fragmented and buggy.

Here's a case in point: Androids MediaPlayer and its state diagram. This is
pretty straigthforward pipe to the underlying Khronos OpenMAX API (that is
totally brain damaged and horrible by itself).
[https://developer.android.com/images/mediaplayer_state_diagr...](https://developer.android.com/images/mediaplayer_state_diagram.gif)

