I feel like this overlooks one of the more fundamental problems to Android development. It's not an issue with Java, it's an issue of Android being a cathedral of complexity. There are four dozen ways to accomplish the same tasks, each of which utilizes a different (but ultimately incompatible) piece of the API. You can build your Activity and embed your Fragment in it which houses a ListView to display your--- wait no maybe I should override ListView. No, people say that's a bad idea. Okay I'll override this object which ListView displays. Okay that kinda' works well enough. I'll figure out how to style that later. Okay now I need this thing to go to this other activity when cli-- maybe I should just replace the Fragment, since we're kinda' using the same data. No wait. I'll change the activity. Okay it looks like there's no function to do that. I'll go back to changing the Fragment to something else. Okay, that's giving me an exception. Lemme find where I can change the Activity... Oh, I have to do it elsewhere. Well I can hack my way around that.
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.
No, if you're reaching for PhoneGap it's because you already know HTML/CSS/JS and just don't want to learn Android's UI. Android's building blocks are simpler and more predictable than HTML/CSS is, so clearly complexity is very much not the issue you are having. It's just lack of knowledge and a lack of motivation to learn it. Which is fine, just not at all what you are claiming.
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.
Please tell me where I can find a reference of Android UI's building blocks, and how they are supposed to be used.
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.
Actually Android UI is about on par with HTML when it comes to how bad it is. I mean it's basically XML/more XML/Java instead of HTML/CSS/JS.
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.
There is not another UI toolkit on the planet that has the insanity that is CSS's layout and "kinda-box model but not really". CSS is very powerful, but good lord is it complex as hell.
You're probably right. I'm not convinced you're right, but I'll operate on the assumption you are and offer a feeble defense with anecdotal (and experiential) evidence to explain why I would rather use Android UI but consistently turn to PhoneGap.
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.
CAR ANALOGY!
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.
Well, a lot of that gets back to "Android is hard to do rapid prototyping in". I would looove something faster to iterate with personally, but I can also understand how it could be detrimental in the long run. It's too easy to take prototype code and ship it, instead of fixing up the underlying architecture to play nice with all the various lifecycle and different device configuration stuffs. Fragments are a pain to deal with in the early stages, but they force you to modularize your app in such a way that makes long term maintainince and UI changes easier.
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?
> Some devs say one Activity for the whole app and just swap fragments!
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
Sounds way better than javascript, where you have 5 different API's, you have to support at least 3 of them, none of them are equal, they have bugs that will never be fixed, and they are yanked from under your feet every 2 years or so. Oh and that's ignoring that basic things are still completely impossible.
> Do people actually use any of this stuff still or is this blog post from 2008 with no code formatting really the best resource?
Sounds like it's got the javascript documentation beat by a wide margin.
Android development in general is quite lacking. The language (I think) is meh; the APIs are full of antipatterns and type juggling; there is no good simulator/emulator (iOS is leagues better and WP8 is much less painful as well); the 64k DEX limit is ridiculous; the list goes on.
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.
Maybe it's just the way GUIs are done. Every time I tried to do something with Swing / Qt / Gtk / wxWindows, I got exactly the same process. (and rarely any results)
I've found the only sure-fire way I have is to write my own GUI display[1]. I understand it's a bad idea to do stuff like that, but I heavily on inputs which are outside the standard repertoire. Unless there is a standard widget in a GUI toolkit which lets me enter 2D points overlaid on a procedurally generated image with scrolling support.
[1]Except Swing, which allows me to override paintComponent.
In Qt at least there's pretty much one way of separating Ui and model. There is the choice of using QML vs widgets or mixing but those are actually different philosophies of doing UI development, use which you prefer.
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.
When I was writing apps in C++/Delphi it was normal to have an inventory management app drag the various components into a representation of a warehouse. Now ? Textboxes, with javascript validations. Yes it works on phones (more often it doesn't because the UI won't fit), but it's just not comparable. The schedule optimization software was a tool where you dragged things into the schedule and the whole thing would do a live reoptimization for you. Now ? Send it off to the server, wait 3-5 seconds for it to calculate and ... Several departments have simply not switched away from the old windows apps, and to be honest, I understand why.
It's all possible in javascript. But
1) at such a huge, huge computational cost. I could get a 3d rendered village going and walking through doom-style on my 486DX-2. I cannot draw that very same village on canvas on my 64G i7 haswell. Not even if I use the same amount of pixels. It just doesn't get up to the same framerate. Java can draw that village at 2560x1280 no problem. With C++, measuring framerate is useless, it's just stuck at 60 fps. Haskell can fucking do this. Javascript ... nope.
I don't mind paying some CPU for an abstraction, but I find haskell to be over the edge of what is reasonable. To find javascript you'll probably have to jump entirely over, pass the elephants and look under the turtle.
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.
3) Everything about javascript is just such a "we've just had the twenty-third co-committee agree on the pre-election parameters for the members of the committee to decide the color of the book we'll write the standard in" organisation. Nothing works. Nothing is really standard. Nothing lasts.
4) Complexity management. I can manage a 50000 line codebase in C++ or Java. I have worked on codebases that ran into the millions of lines of code. No problem (well, plenty of problems, but manageable). I will fully admit I cannot manage the complexities in a 1000-2000 line javascript program. Too many things interlock. There's no separation. There's no encapsulation. None of the complexity management techniques are there. And there's just no end to the stupid javascript bugs (you know operators not doing what you want. The most recent example : NaN + "NaN" = "NaNNaN". Someone kill me).
5) Compatibility. WTF. You have the javascript community being the main culprit here. No offence, but have these guys ever agreed for even 6 months on a way to design things ? And of course, all the libraries find themselves a "paradigm", meaning it's bloody hard to combine more than one of them in a project. And what do these projects add ? Nothing, really. AngularJS, the "favorite" for the last 4-5 months (which must mean Google's about to abandon it ?) is essentially a basic (and I mean BASIC) reporting toolkit. It's got the same sort of features.
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.
Dart ... well I don't know why anyone would want dart. Anything, anything at all beats javascript of course, but it does nothing to solve the massive problems of the platform that is the web. I learn every language I can find up to the point I can write basic apps in it, but I can find absolutely no reason whatsoever to start using dart beyond that. The few advantages dart does have are much better executed in GWT.
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.
And of course, the mere fact that all these things exist means that nothing can be recovered. You had an application written 1 year ago. You wrote a game 1-2 years ago ? Well it's probably in flash. You wrote it 3-5 years ago ? It's very likely that it's a java applet. And even if it was written in Javascript ... well, it's obviously not in AngularJS, so let's rewrite it ! What ? I have apps that I wrote when I was in highschool that are still running smoothly. And those do not qualify as old, good apps. One of the supermarket chains in Belgium (Colruyt) runs on a Borland Pascal 7.0 DOS client-server application. When you see cashiers using that application, you understand why they haven't upgraded. You can never even tell it's looking up something on a server, that's how fast it is.
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.
> The article felt like it was trying to rationalize something, like Android needs a Swift.
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.
> 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.
The question about those code-generating languages in connection with Android is always:
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.
Debugging Xtend is straight forward. On a normal JVM you can even switch between generated Java and original Xtend source during debug, depending on what level you would like to step through.
On Android you need to decide using a compilation flag whether you want to step through the generated Java or the original Xtend source. This is because Dalvik doesn't support JSR-45 which Xtend uses by default. So it basically just works.
> 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.
Not when you reach 64k methods together with libraries for a debug build. Of course, unless you want to go through the joy that is loading another .dex file :)
I am building a side project app in Kotlin right now and so far it goes well.
There are some minor problems with IDE support (kotlin source folder is not marked as a source folder when mixing Android and Kotlin together), but that is fixed with one click of a button.
I really like it!
I don't know how kotlin fares in practice for android, but I experimented with scala on android a few years back successfully.
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.
Kotlin for instance doesn't support something similar to active annotations aka compile-time macros. This is a very powerful concept. Here's an example of an annotation from the Xtendroid project (https://github.com/tobykurien/Xtendroid/blob/master/examples...)
Does that violate the new ruling in favor of Oracle lately? If not, what if Oracle pursues that in the future, too? If I were Google I'd be like on needles about continuing to support Java on Android, and I'd start looking for a complete replacement (which will take years to come to fruition anyway, so all the more reason to start now).
Imo Android needs a Swift because:
1. Java is too verbose/tedious. Developers are looking for something richer/more expressive.
2. Oracle. Java is non-open.
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.
If I were to pick any language to do Android dev that wasn't Java, it would be Kotlin. It's a great language with a great IDE. I haven't done Android projects with it, but if I were hell bent on not using Java, that'd be my choice.
The nice thing about Xtend is that it has a light run-time library. I wish Scala had a core-library that could be used in Android and such other constrained projects. Perhaps a library without specialisation and/or without collections could be made.
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).
As someone new to both programming and Android development, I think the biggest help is not some easy language but the questions and problems that have been asked on sites like StackOverflow. You can replace the language but how do you replace that whole stack of help articles written for Java for Android.
I've always been intrigued by the possibility of using Clojure or JRuby to build Android applications. There are toolkits (Lein Droid, Ruboto, etc.) and tutorials for both, but the edges are still _very_ rough.
Is this actually true for Scala? I was under the impression that statically typed languages run basically the same as Java on Android. Granted it has some other issues (such as running in to limits on the number of classes).
Because Xtend compiles to plain Java code that is, mostly, readable. So the investmet in Xtend is low: in case it fails, you can compile your codebase into Java and continue from there.
Basically, it is very similar to what CoffeeScript does. A better syntax with (largely) same semantics. Which can have massive advantages.
I'm not sure this answers the question or even explains why Xtend is better than say, RetroLambda. It sounds like lambda support is already being backported from Java 8 by the Android team and since you can use lambdas today, any investment in Xtend is questionable.
What's with this Go obsession in connection with Android? Go's design and the way it works is terribly suited for Android development and currently isn't even capable of plugging into JNI bridging architecture of Dalvik/ART.
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, anything can 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.
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.