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