Another Helping of Android Studio
Ok, this time around I am having a better experience, but still feels like riding the scree (to quote Peter Gabriel).
Here are some good things:
- there is testing now
- the automatic preview is pretty cool
- the emulator it turns out is much faster if you don‘t close it each time, the Simulator in Xcode doesn‘t care it‘s lightning either way
- there are more videos I‘ve found (and have been watching on AppleTV) and some of them shed light on things
on the less than spectacular side:
- been doing some canvas work, which is just drawing code, OMG, drawing code is dismal in every language I have ever used, but Android is especially bad and for a slew of reasons (more below)
- wanted to just add a unit test last night of a simple class, not an integration test that runs a view or anything, turned into an insane tour of the briar patch, which was partially IntelliJ‘s fault.. (more below)
- the reliance on XML for views is such a stunningly bad choice, it screams out of every pore of this product
Ok, never mind this piece by piece stuff. There are some huge cavernous questions that using this product bring back again.
In 2013, are we really at a place where a company that is making buckets of revenue serving ads floats a product that puts you in an XML editor in one pane, and shows you your view rendered on the face of a fake phone in another, and their ‘developers‘ sing hallelujah?? Sad.
Xcode isn‘t 10 or 20% ahead of Android Studio, it‘s generations.
That said, I kind of like the visualization thingy and it‘s not all bad. For instance, you can construct views from fragments fairly easily and those fragments can appear in multiple places. Xcode does that, but in a slightly less intuitive way. The programming world has never really figured out what it wants to do about the question of components. It‘s fashionable to laugh at the early theorists like Brad Cox for overselling the component as an IC, but wow, 25 years later, it is certainly not the case that some opposing tribe has proven a contrary hypothesis.
Frankly, you could argue that the reason that the NeXT team got so far into the forest is that they decided (we imagine it was conscious), that frameworks should have components, but a rather small finite set of them whose behavior can be shaped easily. For some reason, the VB and then the Java worlds went chasing the idea of custom components as the basis of everything. ‘Here are some tools for you to make any component you want, all you have to do is take on management of a whole lifecycle, custom tags, etc.‘ The tragedy of JSF is that it did a lot of things right, but then it just laid down this limp ‘fill in the components blank with whatever you want to build‘ and the other obligatory fallacy that fuels so many such teams, the Field of Dreams Syndrome. When no one came, they built Creator. Ok, I won‘t go into that again.
So Android Studio is much better. I still hate the emulator. It is kind of stupid too that you are looking at these panes that are rendered immediately and then when you go to run in the Emulator you wait forever to see this bigger, blown up ugly version of your work.
Everything, though, fits into this format of just a rambling wreck/dog‘s dinner of half-baked ideas.
Here are a few other philosophical questions:
- why aren‘t the best minds in tech drawn to the toughest problems. Friend of mine sent me a great thread today that was saying something I‘ve said on here 100x: we regress and keep congratulating ourselves for pulling up a pair of big boy pants others got into a few decades ago (but we are also too poorly read to know that). My favorite part of that was Dave Winer saying ‘people are congratulating themselves for getting things into the browser ecosystem that were working in the mac 30 years ago.‘ Amen.
- Any time you find yourself reaching for XML, first, stop yourself. If you need help with this part, here are a few suggestions (in ascending order to try along an escalating scale): 1. timeout (in the corner) 2. think of your mother‘s smiling face (she doesn‘t want you putting more shit into the world, there‘s enough already) 3. try a breathing exercise 4. chant like George Harrison did when the helpless little stooge broke into his house to steal some shit, when you get light headed, think of Tim Bray 5. gain access to restraints, hopefully like the ones in Strangelove, just more effective.
- Instead of XML, what about the idea of just doing a DSL? Is that a crazy idea? Should we be using composable languages for describing interfaces? It makes me laugh that the most appealing part of Android dev to me is that it‘s in Java and in the best parts, you see a lot of things like Bloch style static builders and the like. Then you wake up in this pane where you are nesting XML tags where you are trying to describe how things should both look and work. A DSL would also make it easier to get tool support that really works. IntelliJ can suggest tags for you when you are making your views and fragments, but there are so damned many it‘s more or less pointless. And you can‘t really understand the relationships.
There is the possibility that Google is awaking to some of these things and is going to really start to inject a lot more intelligence into this tool and it will start looking a lot better quickly. I have thought that through. Not likely, but possible. More likely is that Google will do what they have always done and just kind of take the attitude that I often call the Ballmer Doctrine: ‘wait, what would shutting up this whiney bitch do for my bottom line? I made more ad revenue last quarter from pot holder makers than that jackass will bag in his whole sorry life.‘
One last rant that is related here: drawing code. I wrote a drawing program once in Java (later found HotDraw and it was eerie how similar the code was). Mine was based on PAC (vs. MVC) and it was a blast. But that was for letting you draw things. Programmatically drawing things, using code, is a nightmare. Even in Cocoa, which is powerful as all get out, it‘s really unpleasant. But Cocoa is so far ahead of Android on this one, it‘s not even trousers v. diapers, this is like Einstein and Bohr on one team and 2 Neanderthals who just had their camps raided by humanoids on the other. In Cocoa, you can easily compose things you are writing using layers. I spent so much time looking at how to do layers on a Canvas in Android, after a while I was like ‘wow, forget it.‘ The documentation on the Android Developer site is laughable. There‘s like one page devoted to Drawables and Canvas. The examples are so anemic, they look like an organism that was fed from an eyedropper that was dipped in a toxic puddle. Then I found a Google I/O talk from this year about animation and watched it. Scattered, half-assed, and overall kind of hilarious. Romain Guy is one of the dudes, the other is Chet Haase I think. Romain is pretty damned funny. Which is cool because Google does not have much sense of humor (and think about what it says about your barrel of nerds when the funniest guy in there is french, not that the French are not funny, they can be hilarious, just that their humor is often pretty caustic). Anyway, I went and dug up the example he references in the talk. Reading the code is depressing. Makes you think ‘wow, if this is the example I‘m supposed to follow, maybe it‘s time to think about becoming a travel agent….‘ (so you can book your own passage to some place far away).
Why is graphics programming always so sucky? What is so damned complicated? O-C has the added advantage of having blocks now, which help a lot. But even simple little things are a huge pain in the ass. Part of the answer is that there are a lot of stupid things you have to deal with that you are expected to just pick up, like the coordinate system, how scaling works, what the flow of calls is that makes painting and invalidations occur, etc. And none of that is based on any standard of course. The biggest killer I think though is that ultimately drawing code ends up being a jumble of crap that depends on a lot of shared context, and that‘s always a prescription for disaster. This is the core of the PAC argument, and frankly you see in the Actor model too: shared mutable state that is serving a lot of different interests is a disaster waiting to happen. When you have to paint something, what would make the most sense would be to immediately decompose the thing into parts and then have those parts plug into some means of being notified of state changes. Then of course, have the ability to notify other parts of changes if/when needed. None of this happens, so you end up with lots of ugly code. A good illustration of this in Android is you can look at examples where it shows a drawable shape, but then, if the shape you want to draw is not one of the canned ones, you are out of luck and you are going to have to make your own thing that just goes at the Canvas and tries to braid its snarl of crazy functions. Just go look at the method drawArc. When I first saw it I thought ‘ok, this is going to be awesome because it lets me just define a RECTF and then I can draw an arc in that.‘ (This solves a problem I had for my own case: wanting to depict curves that are flatter or taller in different circumstance, very easily.) But then, it quickly turned into the usual hell. Which parameters are which again? t,l,b,r? I swear some of the docs are wrong. And there‘s a create method that has a different order. This is a case of where builders would make a ton of sense, e.g. new Rect.Builder().top(100).left(10).right(100).bottom(10).build(). Hello.. ?? (Oh wait, I can hear the response ‘Java is middle aged and we should all be writing JS for everything….‘)
Should graphics ever be done programmatically? There‘s a creeping feeling in some of this that this stuff is awful because the creators don‘t see why you would need a shape other than a circle or an oval.