You must read “Hello Android” by Ed Burnette.

If you’re like me, you have a dozen or more books on your bookshelf that you will never ever read again, but you have never considered throwing them away. With titles like “Learn C++ in 30 days” and “3D Game Programming in Java” or whatever. Maybe even something like “PHP 4.0 Tips and Tricks” (ok I made that one up, I don’t even want to look at my bookshelf right now). Because once you learn something and do a few projects in it, you don’t really need to read the books anymore. Well, those are the good books. The bad books, you bought them because you thought they would help you and they turned out to be utter crap. Most computer books are like that. You walk into a bookstore and there’s 10 books on C/C++/Objective C/C design patterns/C#, and “C is the new Cobol”. Maybe a dozen more on C game programming, Linux programming in C, and a dozen more, and you sit there and shake your head. Then you walk over to the Java section and the situation repeats. Except this time it’s worse because in addition to all the normal bloat you have the “Android Section”. And this is where your hell really begins. Because most android books really suck.

Thank god for the internet, I always say. So I went home and downloaded a dozen books on Android development. I ended up buying only two of them which I will name shortly. The losers deserve no mention by name, although I will talk of them first. They were all current (2.1/2.2 and up as of writing). They all looked good. Some of them seemed to be the best in their class. Some were from famous publishers and some were by relatively well-known and experienced people. The main problem is that they were obtuse. And this is a difficult thing to get around since programming for Android is a whole new world from Java. Yes, it’s Java, but it’s like nothing you have ever seen before. Personally I think the people who designed this system were genius dropouts. Genius because the system works, but dropouts because it is a horrid pile of crap from the standpoint of getting in the door.

See in the past you would do programming for an interface by loading the values you wanted into a data structure and sending that data structure to some sort of class library slash interface. This is just how things have been done for billions of years. But along came things like Ruby and AJAX and CSS and suddenly it began to look like the Lisp guys won. You have major services like Twitter using Scala. Scala. Why? Because it’s not mainstream.

But this is besides the point. There is so much XML and other cruft you have to wrap your head around that it is like programming in a different language. There’s absolutely no reason why you have to type stuff into an XML file when Java has a perfectly good way of instantiating arrays of values in code. XML is NOT more human-readable than Java code for doing this, especially for people who have been in deep with the Java for a long time. I’ll give you an example. The layout and value XML code is full of stuff like this:

            android:textSize="24.5sp" />

ok. ‘splain this to me. How is this any different from a simple Java class file, where say a .layout() method is like…

        View view = new TextView();

Short answer: It isn’t. It’s just more difficult to switch contexts and switch files all the time. And it’s more expensive to process by the computer as well. Which, surprise surprise, ends up converting it into machine code along with everything else and running it. The XML crap is a bane, and you have no choice but to learn it.

So, about those failed books? All of them beat you over the head with this stuff. They make things so ridiculously complex, cutting and pasting things in 4 or 5 different places just to declare a class and have it fit in the “Activity” model — which in itself is a giant .wtf().

But I promised I wouldn’t whine about the poor design decisions that went into setting up a public Android Development Environment. This is about books. And the best book I ever read was “Hello Android” by Ed Burnette. I cannot believe how good this book is. If you read anything else, you are wasting your time. Well, that isn’t entirely true. I did read another book which was just as amazing as Ed’s. But I won’t tell you what it is yet. I’ll save that for part 2.

“Hello Android” was really a godsend for me. The examples they use were not assinine (like making a social network app – Jesus Christ which marketing guru got fired over that one) and not useless (no names, no names). The book was also COHESIVE which I cannot stress enough — no other book was as cohesive. What do I mean? Well it’s difficult to describe. Halfway through other books I just felt lost and was like “Shit I better keep reading, and maybe something will sink in”. But nothing ever did. It was one useless paragraph of long winded bullcarp after another. But not “Hello Android”. No, this amazing book was easy to read. For the first time I found myself actually understanding layouts and actually understanding getting from point A to point B with things like buttons and handlers and Activities and Views.

Thank God for “Hello Android”. Thanks to Ed Burnette, my Android adventure has only just begun.

Dear Netbeans Development Team

Dear Netbeans Development Team;

I’ve been using Netbeans for, wow, as long as I can remember. I switched when the Kawa project folded. I loved Kawa. Netbeans felt like Kawa. It felt like home. So I stayed. I loved the interface and the power. But recently you dropped the ball on SAF support. You promised that it would be okay to use it, even though it would be dropped from the Java spec. You promised that the only thing was that it would not be updated. Maybe, someday in the future, we wouldn’t be able to create projects with it. Okay. Well I’ve been using Netbeans and SAF for a very long time, more than six years. Maybe back since 2002. Not sure. I have code that old but not sure if I was using SAF back then. Of course, if SAF was promoted as the default for new GUI projects in 2002 (it was in 2009, at least) I would have been using it.

But when you released 7.1 and included IF-statements that explicitly prohibited SAF forms from being loaded into the editor, you made a mistake; You did something you had no right to do, you tried to funnel users into migrating away from SAF into NBP (Netbeans Platform). Most of the reasons you gave for your decision were lies or excuses:

1. You said SAF (i.e. JSR-296) was being dropped from the Java Standard and therefore would be removed from Netbeans.
Ok so what is Netbeans Platform then? A JSR? It’s not even a JSR. So dropping it just because it won’t be in Java and then promoting Netbeans Platform does not make sense. If the reason is that it won’t be in Java, then how can we trust you and use NBP? It’s not logical.

2. You said SAF was not supported.
Reality #1: SAF was supported — by several fork teams. BSAF for example. It’s an extremely well known thing in the Java community, yet you failed to bring the BSAF team on-board or consider their work at all.
Reality #2: SAF was supported — by Netbeans. You actively promoted SAF and made it the default for new projects. Then you broke backwards compatibility with no warning, in reverse of previous statements you made that you would not do this. This is an EXTREMELY bad thing, for the reason I am about to tell you at the end of this list.

3. You said that Netbeans Platform was superior to SAF.
Reality #1: It’s not. I tried using Netbeans Platform from the project creation menu. It created a bloated heap of giraffe poo. Why is there a web browser in my new project, and how do I turn it off? You need to seriously think about that and why I was never able to solve the issue. You need to think about how you pissed me off as a developer. Never mind everyone else. We want the features of SAF without the bloat of Platform. Hint: My project is 300kb. Why would I upgrade it to Netbeans platform and have it quintuple in size with no visual benefit?

4. You provided no way out.
No, the “solution” in the form of an XML file which people had to dig thru a buglist to find WAS NOT ACCEPTABLE and did not work on 10-20% of files making the whole thing a pointless effort.
Reality: This was your biggest mistake. You have done this in the past with your Visual Web thingy. You have done this in the past with other technologies. Well, this time you pissed me off.
Reality #2: Sure, for people entering Netbeans today, or people PAID to do it, this is no problem. Welcome to the happy candy land of Netbeans and Netbeans platform. Well I’m not like that, and I am thru with Netbeans forever.
Reality #3: We can’t even use SAF or BSAF as standalone libraries because you put explicit IF-statements in the code blacklisting SAF. I can’t believe you did that.

How dare you do this to me.

Here’s that reason I promised you at the end of the list.

If you’re going to drop the ball like this, users are going to call you on it. You lied. You promised it was okay to make SAF forms. SAF was the default for many years. Many people who just wanted to use Swing were funneled into SAF by Netbeans, then you ripped the floor out from us. So I’ll tell you what. If I have to rewrite my projects in plain Swing, fine, I will.

In Eclipse.

And I will never, ever use Netbeans again and I will relate my story to as many people as possible.

I hope you all burn in hell.