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

N+1) Android vendors who think they know what they are doing will make customizations that utterly screw you (e.g., mucking with date/time pickers to the point that they are busted on some random set of phones).

N+2) Oh, so you want to make a buildbot that does stable builds based on known versions of tools and libraries? What a quaint notion.

[Can we just say that Activities and Intents died, or at least achieved effective bankruptcy as actual abstractions, around the time the 32nd flag modifying behavior was added? At some point you need to step back, take an honest look at what developers are actually doing and realize that things are simply not working out. All that anyone does with the UI framework is to try different things and "twist knobs" until the apps seems to work, and hope that it doesn't break much in the future.]

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

Or any software ;)

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

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

So it's not just me then. Good to know, I thought I was going crazy.

But you can always check the code easily and figure out how something actually works. Not the best solution, but it saved me more than once when the documentation or stack overflow doesn't suffice.

This kinda thing makes me glad I'm in web dev.

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.

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

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

Thanks! Your acoustics business looks awesome.

It does matter what the language / ecosystem is; learning curves are not equal across all of them. Having learnt Go a while back, I was surprised at how short a period it took to feel at least reasonably comfortable & productive with it. I've seen the same with colleagues as well.

That might not be so easily possible for a GUI mobile app though; maybe there's more necessary complexity there. But aiming for simplicity is a good goal to have regardless.

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.

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

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

I miss that title. I have no clue what the article is about from reading the new title.

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.

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.

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)

> Why didn't they use Python

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

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

he did :P

Probably historical reasons; when Android was created, was Python good enough? Particularly on underpowered processors with tight power requirements?

At the time Google started promoting Android OS, Google was well known to use primarily Python internally. So I was very shocked and discouraged by their choice of Java. I assume it was to reach the widest developer audience at the time. Maybe a case can be made for using Java otherwise, but Java is my least favorite language due to it's excessive verbosity and other pointlessly fussy restrictions.

Android was not started by Google; I presume when they bought Android Java was already entrenched

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.

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.

Android studio is based on Intellij by Jetbrains, the creator of Kotlin. I would count on it.

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

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

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

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.

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

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)

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

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.

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.

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.

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.

What? Surely the JS you write is embedded in the release build.

Portability? With a little setup you can write your logic in one language with a reasonably low amount of extra work to handle different platforms. Staffing up two separate teams working in Objective-C and Java isn't ideal either.

I'm guessing the answer to this is: because the problem is ridiculously bad.

People will always suggest what they know as a solution to everything. A lot of people only have deep knowledge of, say, Javascript or Python. That's why you see people in threads like this suggesting these languages as the solution for whatever problem they envision.

That's also why you see horrible solutions for problems that have already been solved in the past.

There should be a rule that says that you are not allowed to design a framework until you have direct experience in developing for at least 5 different systems from different periods in history first.

If a key problem is the need to build every app for multiple platforms, why wouldn't an abstraction layer be a valid approach?

Sure there have been some failed attempts in the past but why not encourage RN? Clearly it's working for many applications and being actively developed.

But there is a single problem with React Native: Javascript (and all languages that come from it). It's frequently one of the most hated ones as it is loved.

Dynamic language is not necessary the best thing invented, if it were there wouldn't be any other kind of languages.

Lots of great experiences with Typescript being reported and I am loving Flowtype lately so the era of only dynamic JS is fading out.

A lot of the JS hate goes out the window with ES6 and type systems.

Doesn't it follow that static language is not necessarily the best thing invented, if it were there wouldn't be any other kind of languages?

Yes, but parent response suggested that dynamic langs are the answer to android development problems.

Adding more to the discussion: Android env is like a framework (as opposed to library), it is always harder to work in frameworks than using libraries - e.g. lots of stuff you will have trouble mocking out in unit tests.

I was just addressing the issues outlined in the post. I would hardly define ClojureScript as a language that came from JavaScript.

Naturally there are cases when a typed language is better than a dynamic one.

I really need to give Reagent+React native another shot. Last I tried there where still some apparently minor, but annoying issues.

That said, even as a clojurescript fan, I wouldn't call this a solution, more like a practical workaround for a deeply flawed dev experience.

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

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]

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

RecyclerView

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.

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.

> I get real tired of web soft boys coming into native and complaining about how complicated it is on the metal.

I've done a lot of native development, real native development, not this fluffy Java stuff and Android is still overly complicated in both design and tooling.

My needs as a developer on Android are far from cool and that shouldn't be unnecessarily hard -- but it is.

You talking about the pseudo-restful activity/intent design? Cause I'm not gonna defend that, haha. It's a neat idea that simplifies corner cases at the expense of making a lot of common cases very counterintuitive. If the article was bitching about that, I'd take it a lot more seriously.

I dunno, I have a soft spot for Java. Yes, the verbosity can be annoying, but compare that to the scavenger hunt that modern web languages put you on when you're trying to figure out exactly who is doing exactly what.

My biggest beef with Android is the frequency with which stuff gets stuffed in a Bundle and sent off elsewhere. Which means the typing isn't "you don't have to worry about getting this wrong, the compiler will help you" but rather "yet another thing you can get wrong that will explode at runtime."

Ugh. From your lips to god's ears.

Don't get me wrong, the inter-application intent stuff is really cool and good, but sometimes, guys, it's all in-app stuff. I need to tightly couple these objects. I need to pass actual non-serializable objects amongst activities within my app. I'm sorry, I just do. Marshalling and de-marshalling data out to a bundle or the database isn't going to cut it.

People who like this sort of thing, like things that are needlessly hard. Like climbing up a mountain by crawling backwards feet first. Sure it took a lot more sweat to get there, and maybe you are personally proud of conquering the large amounts of unneeded extra effort it took, and enjoying pointless cognitive overload as a way of life. Primary gain for such mindsets is it creates a barrier to entry for most people that doesn't really need to be there and perhaps allows a false sense of job security.

"Metal is just the last layer you care to look under."

That quote is gold and I am absolutely going to steal it.

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.

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

I think this may have been intended as sarcasm, but yeah man. I do C development for my real high performance mobile development. Everybody does. If you saw an app and wondered "Oh wow, that was cool, how did they do that?!", more often than not, somebody wrote some nasty old C/++.