It doesn't end.
"Button is actually a special type of view with extra properties." Great, so everything is a... You know what, I don't care. I feel like I did in the mid 2000's with game development: there are a thousand libraries which each are so complex that it's impossible to get good work out of them. Instead, I always ended up falling back to the simplest home-rolled solution. Except in the case of Android, there's really nothing more fundamental. I can (and do) use PhoneGap because it makes my life _significantly_ easier in many respects, but I think Android really needs to be restructured on a more fundamental level.
Android's pieces do force you in to a significant amount of upfront complexity which makes rapid prototyping hard, but that complexity pays off a hundred times over when you start fleshing out the application into a real project. It's very critical infrastructure as the app complexity increases.
I know exactly the feeling jo_ is talking about, but then I've only tried to wade through developer.android.com which is really complete but you really have to know what you are looking for.
The XML itself is really static, which forces you to turn to writing code even for the smallest things and then you're writing UI code in Java, in a UI framework of less than ideal quality.
I knew Java first, then picked up HTML/CSS/JS on my own. I'm cozy enough with Swing and I'm getting there with JavaFX.
I would rather develop in Java with Swing or even JavaFX. I reach for PhoneGap because I can develop my application 'live'. Make code changes, switch windows, changes are live. I can pull up the UI panel and make adjustments to styles to see what looks good. I can test the entire application and debug it before I push it to my device. If something fails to load, I can see why without waiting for an emulator to spin up and without pushing to the device. Plus, if the application crashes in my browser, I can pull up the debug console and step through it. I'm sure all these things are possible with ADB, too. There are lots of little things which irritate me with native Android development. I'm still releasing apps and every so often I try to do a native one. Whenever I do, though, I always find myself stuck on something that seems infuriatingly simple or clear -- something that 'Just Shouldn't Happen," and I look over at PhoneGap and I know that, despite JS being kinda' shitty, and despite the lack of consistency in HTML5/CSS, it still beckons for silly reasons like, "Small annoyances are more soluble! You don't have to rebuild and reupload to fix a null-pointer error! You can use the REPL to play with objects in memory!" and so on.
Maybe I am reluctant to learn the nuance of Android UI on a subconscious level. Maybe I'm reinforcing my own beliefs when I sit down with an Android UI book or go through the UI tutorials online. I've just never felt the workflow was very intuitive, and the small (though frequent) irritations are enough to drive me back to something which is worse architecturally and more time consuming in the long run, but doesn't have the little things that make it unpleasant to work.
I have two routes to work: one of them is short, but goes directly through the city and has a crazy merge that I need to do to get there. Some days I take this route because "it would be totally great if I'd just get familiar with it," and I start out fine. Except for the insane merge which is backed up for a few blocks. I'm driving fine, and I feel like now that it's over I'm home free. Oh. This street has construction. Sudden stops. My head is starting to hurt. Nearly half way there. Okay, I don't see a way around this route. I have to backtrack because I made a wrong turn early on. More construction. Traffic lights that aren't working right (or are, but I'm mixing them up with the ones facing perpendicular traffic). Finally at work. I'm irritable and still have a whole day ahead of me.
The other route is really long. I get on the onramp and it's slow but I'm always moving. Quick scuttle and I'm free to drive. The roads are unfinished and there's an omnipresent farty smell, but I'm moving at a comfortable pace and I'm pretty relaxed. Oh, the bridge my route takes is out. Well, I'll travel down the way a bit. No problem, though it's going to take longer. Swoop around and I arrive at my destination. On the way there I also picked up a Strawman at a barn to use in my analogy.
You can now see changes "live" in Android studio with the preview pane, which is getting pretty good these days. If you haven't played with that I'd suggest giving it a shot.
The emulator is a disaster, I only ever develop on real devices. Pushing isn't that slow, but it's definitely not as nice as just hitting refresh in a browser.
Google developers say to use Fragments for everything in the I/O Fireside Chat. Some leading non-Google developers say not to use Fragments at all. Some devs say one Activity per screen. Some devs say one Activity for the whole app and just swap fragments!
The Android SDK is loaded with tons of components with unfriendly APIs and a huge dictionary of overloaded terminology. It is maddening trying to figure out some of the concepts, especially if you have programming experience on other platforms. WTF is a Loader? There is something named Binder but it doesn't do data binding? Oh, so a BroadcastReceiver is really just a fancy name for event subscription? Do people actually use any of this stuff still or is this blog post from 2008 with no code formatting really the best resource?
And don't get me started on testing...
Meaning pick and choose what you want to do. If you're writing a game, this is probably the way to go.
If you're writing a form entry application with a million controls, fragments fragments fragments. Did I mention fragments should be used here ?
You forgot to mention that there are devs saying many other things. Use C++/Qt. Use unity. Use C#. Use ... your choice !
> The Android SDK is loaded with tons of components with unfriendly APIs
> Do people actually use any of this stuff still or is this blog post from 2008 with no code formatting really the best resource?
Google is trying to improve. Their adoption of IntelliJ as a recommended IDE is a big improvement (IMO) when compared to Eclipse. But they have a lot more fundamental things to fix.
Google is of course at a big disadvantage against Apple and MS which already had good experience with development platforms before smartphones came around.
Except Swing, which allows me to override paintComponent.
Well, I for one have just the opposite experience. Webpages, I develop them often, but I never get anywhere beyond a basic, simple, ugly and unresponsive interface (meaning the server and client actually operate decently in sync without massive refresh times). Anything even remotely complex is just such a huge problem. Having elements move around, drawing complex graphs, ...
Coverflow was trivial to implement in Delphi, and I've gotten various advanced interfaces going in C++ Builder as well. I've gotten games running in C++/Qt on linux in an afternoon flat. Making java games ... slower, but not a huge issue.
2) it's full of surprises, and people's weird ideas about improving things. Canvas is a good example. I want a framebuffer. How do I do that on canvas ? Computers work by moving around framebuffers. Why do you give me this ugly canvas abstraction ? I don't want it ! Do I get a choice ? Nope.
Oh look, AngularJS is indeed being replaced:
or will it be :
or maybe :
All of these are obviously half-done rehashes of technologies that have existed for 20 years in windowing toolkits. Project polymer is essentially the idea of controls with properties, which you first found in apple's interface builder (afaik) and was popularized in visual basic 1.0 FOR DOS before I could safely walk around without a diaper.
And react, well react simply is the idea of combining code layout with it's behaviour ... popularized BEFORE I WAS BORN by object-oriented programming and the very first UI toolkits. React, I have to say, is actually pretty well executed though, and it really does hide some of the web platforms' idiocies. So there's at least that. But it's got nothing on, say, a QT app.
The article felt like it was trying to rationalize something, like Android needs a Swift. I'm not sure that's the case. The main point of the argument by my reading was "less lines of code are possible," but that's not what Swift is trying to bring the to the table (although no header files are nice). Swift's biggest advantage is that since Apple has redefined the rules of the language and don't need to stay C compliant, they can change the optimizer and enforce rules differently. Less lines of code are a side effect.
Android probably doesn't need a Swift as much as iOSX did, but there's still a lot to be gained from having a less verbose programming language (and corresponding platform API). Objective C, despite its older features and unfamiliar syntax, was more expressive already than Java was. With Swift, they removed the legacy and made the syntax familiar.
But I don't think this is the answer. If you debug Scala on Android at least you don't have to make a mental mapping of what the corresponding Java translation of your function would look like. A true new language with good features and 'light' syntax would be great. Google already has such a language: Dart.
But Google has already said that at IO 2014 that Java is the language for Android and it will stay that way.
Again, this is also not the case with Xtend.
See this screencast : https://vimeo.com/38425995
How HARD is it to debug?
Because most of them fail badly as soon as you need to do any complicated breakpoint debugging (non-matching line numbers, broken local variable inspection, useless and misleading stack traces) and that loses more time than the language change will ever gain. After all, most of the time we're developing for Android, we're dealing with Android API's and another language does not address warts connected with those. Also powerful utilities like IDEA/AS provide alot of assistance with writing / folding / managing Java 6 issues without debugging issues.
The other important questions: how big of a space hit is the standard library? E.g. Scala on Android will generate/include alot of methods which means you hit the 64k method limit of DEX format pretty quickly. That means you have to use Proguard for each build (even development) and Proguard pass can easily run for several minutes even on a 16G SSD equipped machine - killing development speed.
No, not really. You can just install the standard library on your Android device for development, and only use ProGuard on the final release.
It shares many features with Xtend but offers more. It has the opposite "problem" wrt IDE support though: Great IDEA support but no Eclipse support.
The thing is, android doesn't really need a marketing blitz as big for alternative languages to be usable. dex converter did well enough on jvm bytecode.
Is it Java Compatible?
Yes. The compiler emits Java byte-code.
It wouldn't make sense to not support Android in a JVM language of 2014, honestly.
But I am really hoping Dart would get there, it is just a really nice language.
Ultimately, the language that will become the Swift on Android is the language that makes it a core goal. This alt-Java could even be blessed by Google. Google could eventually cut Java out of the picture: Swift4Java -> Dalvik/ART.
Xtend, Kotlin and Scala are possibilities.
Kotlin has the Jetbrains Android Studio relationship going for it. Also compiles down to JS so could target Chrome/ChromeOS as well. Not as heavy as Scala - less of a learning curve. Xtend is good, and compiling to Java source could be an advantage. But Google do seem to be leaning towards Jetbrains rather than Eclipse.
About Xtend, I think it is not production ready yet. Having tried it in some POCs I hit several snags, such as incomplete support for inner classes and anonymous classes. (Some support has been added recently, though not sure if it handles all cases fine).
Remember that deploying on Android involves a ProGuard step, so the size of the standard library doesn't matter that much anyway.
ProGuard is useful during deployment but cumbersome during development cycle.
How did you measure that?
Basically, it is very similar to what CoffeeScript does. A better syntax with (largely) same semantics. Which can have massive advantages.
I wish it would look like CoffeeScript
Not to mention that Go is a language built for static binaries running on a distributed server and the code running with alot of callbacks, external exceptions and user-input looks horrible.
In theory, Go could absolutely be used for android development
In reality, the cost of JNI bridging, reboxing objects and the fact that Android APIs heavily use Java objects as parameters makes usage of any non-JVM compatible languages horribly ugly, clunky and rather pointless performance and code-quality wise.