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