
Android, evolvability and Comcast - awinter-py
http://abe-winter.github.io/evolvability/2017/04/23/android-evolvability.html
======
ashark
My advice to a new Android developer:

1) The way things are done in the docs is often _wrong_ on fundamental levels.
Using libraries from the android team for _e.g._ network comm is often _wrong_
, even if it's "new and friendlier" (nope).

2) The docs are often outdated. Also their examples are always for _exactly
not_ the case you need. 100% of the time.

3) Stackoverflow posts are often outdated.

4) You _will_ eventually hit a years-old bug that's been marked "obsolete" in
Android's bug tracker. It isn't. There will be a billion workarounds for
various Android flavors in the comments. There will be a _patch_ for _Android
itself_ with pleas for them to apply and release it. They will not have. The
Android team hates you.

5) Don't expect libraries for Google services to be better on their own damn
operating system than they are for Javascript.

6) Just use all of Square's Android libraries and development practices.
Retrofit, flow, and so on. [0]. In the best of all worlds Google would shutter
the Android SDK/libraries team, acquihire Square, and hand it over to them.

[0] [https://medium.com/square-corner-blog/simpler-android-
apps-w...](https://medium.com/square-corner-blog/simpler-android-apps-with-
flow-and-mortar-5beafcd83761) (sorry, medium post :-( )

[EDIT] 7) the interfaces for many of the more complex UI elements seem to have
been made by the interns. Don't be surprised when you have to resort to
reflection to _style them_.

~~~
ZanyProgrammer
Based on your post I can't ever imagine wanting to develop Android apps.

~~~
dboreham
Or any software ;)

But it's "situation normal" for most software development activities, no?

~~~
ZanyProgrammer
Is it? And if so, I can see the reluctance amongst some to call us a proper
engineering field.

------
guelo
I'm not saying Android development or Java are that great but this guy spent
two weeks on it. That's not enough time to get a feel for the environment. It
doesn't matter what the language is, if you drop a developer into a completely
unfamiliar one they will feel awkward annoyed and lost for at least a couple
months.

~~~
awinter-py
(author here). You're right that it takes more than a month to get a handle on
tricks tools & quirks in a new language / buildsystem.

That said, if you drop me in a dumpster I can tell immediately that it's a hot
day. The forum content around the android problems that I had show that the
same problems have been cropping up for years with no improvement.

I don't doubt there are real reasons for the rigidity of android interfaces.
Could be that the underlying system is written in C and doesn't interface
easily with java. Could be limited staff and high legacy support requirements.

~~~
vt240
No experience on andriod, but I really enjoyed your analogies. Fun to read.

~~~
awinter-py
Thanks! Your acoustics business looks awesome.

------
ryukafalz
Speaking of those terms and conditions, I was really surprised to see this in
there:

>You may not use this SDK to develop applications for other platforms
(including non-compatible implementations of Android) or to develop another
SDK. You are of course free to develop applications for other platforms,
including non-compatible implementations of Android, provided that this SDK is
not used for that purpose.

Older versions of Android Studio were under the Apache License 2.0, but they
seem to have changed that sometime in 2015.

------
mayoff
If this post gains traction, its title will probably be changed to “Android,
evolvability & comcast” since that's the title of the linked article.

So here, for posterity, is the original post title, which made me chuckle:

    
    
      If you like calling comcast you'll love android studio

~~~
gingerbread-man
I'm usually in favor of replacing "flashy" titles, but this is a good one. The
analogy fits.

------
hutzlibu
I have many complaints with java, but this:

"Java is pretty bad at producing portable one-liners. In my opinion that’s
because of the public/private feature (completely unnecessary), "

was the point, when I stopped taking him seriously.

~~~
awinter-py
I'm sensitive to the argument that public/private rules improve
maintainability of libraries by shrinking the exported API. Maybe, but that's
a maintainability argument, not a usability/reusability argument.

It's hard to predict which part of your program developers are going to need.
Also, 'private by default' prevents the gradual modularization of code that
happens in languages lacking visibility rules.

------
diyseguy
Amen! I find Android programming excessively verbose and convoluted. I thought
Google was supposed to be staffed by geniuses. The whole thing feels designed
by a committee - like something Microsoft would put out. Why didn't they use
Python? (Yes I've tried Kivy - meh)

~~~
CyberDildonics
> Why didn't they use Python

Are you seriously suggesting using 50x the processing power as a native
program on a mobile phone?

~~~
lostmsu
Did he even ever develop a single complex UI app (or any app actually) in
Python?

~~~
diyseguy
he did :P

------
Infinitesimus
The Java problems the author complained about can be addressed by switching to
Kotlin.

I hope Google gives Kotlin 1st class support in android studio and even pushes
it as the default language as it is more pleasant to use in my experience.

Not sure single file creation of an Android app (with a user inferface) is
possible/advisable though since the separation of view concerns and logic
concerns can come in handy. Gradle can be confusing to a first time user but
Android studio does provide a GUI for managing dependencies.

~~~
ufmace
Kotlin is pretty cool generally, but I'm not so sure it would help the
problems of Android development that much, since most of your time will be
spent dealing with the plain-Java Android classes and how Android expects you
to do things. You'd have to rearchitect the whole Android system in it to
really make a difference, and if you're doing that already, it probably
doesn't matter that much what language you're doing it in.

------
bitmapbrother
I'm so looking forward to his follow up post when he starts trying to develop
an iOS app with Xcode and Objective-C.

~~~
pducks32
I think you mean with XCode and Swift which I love but you just feel like
XCode doesn't like it's new friend.

------
dingo_bat
I never could put my finger on it till now, but this is why I found Android
dev frustrating.

~~~
Ultramax
As someone who has had to deal with Assembly in the 80s for development
projects, Java sounds and works great!

I guess it depends on your experience, attitude and point of view.

~~~
CyberDildonics
Better than assembly in the 80s is not a high bar.

------
vikeri
The solution is called React Native.

\- Single file app: Check

\- Super fast rebuild: Check

\- Dynamic language (high reusability and one-liners): Check (Use
ClojureScript to take this even further)

~~~
JustSomeNobody
There is something seriously wrong with our industry. How can this even be
suggested as a solution?

~~~
reilly3000
Because Facebook has thrown tens of millions of dollars towards getting a
unified cross platform method of having 60fps rich mobile apps. Because
managing an app of more than trivial complexity on iOS and Android is
massively expensive. Because this approach offers the most leverage with the
least trade offs of performance, development overhead, and future viability.

And because live coding mobile apps with a REPL is epic.

~~~
JustSomeNobody
These are all developer centric points. What about users? Android already
needs huge batteries, make everything run JavaScript and they'll need to be
even larger. And forget computationally heavy apps? The hardware android runs
on doesn't exactly have the best JavaScript performance.

~~~
jbob2000
I'm not sure you understand what react-native is... The app your users use
isn't running javascript, it's not Facebook Cordova. You use javascript to
compose the app, there's no javascript in the app you deliver to the users.

~~~
anonred
Pardon my incredulity, but if you use React, how can you not know that it uses
a JS runtime? While it's not as bad as Cordova, you're hardly doing your users
any favors in terms of performance by using React.

------
pebers
Parts of this definitely resonate with my experience; there's a reasonable
amount of high-level documentation about fixing specific Android build issues,
but nearly nothing describing how the system _actually_ works. Lots of
StackOverflow answers exist saying "add xyz to your build.gradle file" but
there's a dearth of anything describing what the real build process for an
Android app is. (For various reasons I didn't have to deal with a lot of the
actual app coding, so the XML layout systems were less troubling to me than
the author).

> When I get the call from G’s android team to build a better buildsystem

I can only hope that this is "when" and not "if" ;-) I can't believe the
current system can't be improved upon though...

------
relics443
I stopped taking the author seriously when I saw that he was using ListView.
Maybe that's a factor of poor documentation, but there's no reason to use
ListView (and the are many reasons not too).

I'll admit there are issues with Android, but reducing them to the same tired
arguments against Java is just lazy (and lack of config files?).

[Developing for Android for close to 8 years]

~~~
TeMPOraL
So what do you use to display a scrollable list of items?

~~~
larvyde
RecyclerView

------
badprose
A lot of the complaints seem like nice-to-haves.

As in, it would be nice to have a better build system, but if you work in
Android Studio, you don't need to know what gradle is. (Like visual studio
devs not knowing much about msbuild.

It would be nice to have a less verbose language than Java, but the IDE is
starting to do a lot of this syntactic sugar work anyway.

------
warcher
Man, I knew this was a troll when I clicked the link. I'll briefly vent my
spleen and get on with a substantive comment.

I get real tired of web soft boys coming into native and complaining about how
complicated it is on the metal. This stuff is hard cause you're not just
churning html. It's harder work than writing a web page. Sorry.

Specifically, mobile is resource constrained in a way that server-side work
just isn't. Your render thread is a _hot thread_ , and you better not jam it
up. That one singular concept is the underlying cause of so, so much of the
obfuscation and confusion associated with mobile development.

But that's the gig.

No, switching to javascript won't fix it. Switching to javascript will
actually make it much worse, as the kinds of industrial grade tools available
to make concurrency manageable (though prone to removing fingers from script
kiddies or the unwary), to manage memory, to deal with a database directly, to
deal with bluetooth devices, on and on are wholly unavailable, or worse still,
are abstraction libraries that require you to fluently deal with both your
javascript interface and some _really_ deep native interop libraries, lest you
be entrapped in cut-and-paste script kiddiehood.

I could go on at length about the myriad pitfalls and difficulties associated
with mobile development, but the simple fact is that doing something cool is
_hard work_.

~~~
awinter-py
Then don't switch to JS, switch to C++ as the primary dev language. The
performance-sensitive parts of the OS are already in C++ and the NDK exists,
so this isn't that big a jump in terms of support from the android maintenance
team.

C++ is not slower than java on constrained hardware, also is more respectful
of memory. Is it harder to use? I don't think so but I may be in the minority
here.

~~~
warcher
C/Java interop is pretty painful still, and the tooling for native debugging
in android studio is notoriously unreliable. (I hear it's better now, but I
haven't had to get into those libs recently, so I can't say definitively. Last
go round I had to roll Eclipse to debug ndk libs. Yeah. Eclipse.)

