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.

Kongzi Beta 7 Milestone 6

I’ve been working on Kongzi a lot recently. There are THREE major new features.

1. Mix and match now works again (although I suppose it always needs more testing).

2. Kongzi now supports split dictionary and user files. That means if you are running a class (versus studying on your own) each student can have their own profile but the dictionary data can be edited in one place. VERY convenient.

And 3.. perhaps the most interesting, most-discussed, and most debated feature regarding this program.. well.. what is it? Well let me introduce it to you. Recall the Browse Entries screen from previous versions; here I am showing the Chinese-English dictionary highlighting some vocabulary from the BLI system:


Now, there’s a secret key; Select some entries (as many as you wish) and press F2:


I’ve removed the window title to build suspense, but there is a clue in this image as to what I am working on. Are you ready to see this? It’s so awesome.. scroll down:


Ahh, there it is! Kongzi’s FULLY INTEGRATED, FULLY DEBUGGED spaced repetition flashcard system!

It works off the dictionary so it’s completely configurable in every way all the quizzes are. I use it to teach myself Chinese and Japanese, and I use it to teach my students English. You can even configure your hints. I’ve included one more shot of a standard Chinese – Pinyin – English setup below; this is what you might see after clicking the “hint” button twice:


Wow, I can’t tell you how proud I am of this system! It took Kongzi in a fresh direction and brought me back to working on the project big time. Although I must say, that the dual savefile structure was more difficult (in the sense that I had to keep track of a very large number of things at one time).

All in all, the dual savefile structure was really necessary for classroom instruction. That’s the biggest bit of info which came out of the recent 6 month beta test. And, oddly enough, it was sort of required for the SRS system because the SRS system would only be useful for one “user”.

So, now we’re at 0.7.6. The only thing left for Beta-8 is to add Audio quizzing. I’m a little unsure of how I should do this. There will be audio only quizzing which will repeat the word twice, but due to audio issues I may also include a “replay audio” button. That is, i’ve noticed audio issues in a lot of similar programs on a wide variety of computers, so I want to get that done right before I release it too.

beyond that, what else? A text analyzer, full-script cloze generator, and some sort of guide/helper would all be great but I think they are not going to be necessary to make a release-quality program. So after the audio (which itself might be thrown out and I’ll just release with the current set of features)… Working on those textbooks is now a big priority.

Okay so I am kind of rambling here, bouncing ideas off the wall, so that will be my decision. then. I’ll do a feature freeze now, put Kongzi back into another 2 months of beta testing to test the split savefile system and the SRS system in the classroom. I’ll work on the textbooks and stick to that June release schedule.

This is going to be a big release for me. I am very happy about this program!

If you’d like to be in the next beta test or you’d like to make any comments or suggestions, please, comment! Tell me what you want in a program like this. It’s going to be the best! Gotta be the best! ^^

Styling a Pop-Up Confirmation Dialog and Forcing Focus in Java

This is really Concurrent Programming in Java part II. So consider it part of that post.

Anyways I needed a pop up confirmation box which had a styled entry field. This isn’t possible in normal Java but I am going to show you how to do it anyways. First, why? Because I need the confirmation box entry field to be styled, and I need it to request focus. Unfortunately since I was adding the entryField myself (to get it styled, since I couldn’t figure out how to access the one that comes with Swing) Java wouldn’t autofocus to it. After a lot of hacking around I felt this wasn’t possible normally. So here’s what I did to get it done:

JTextField entryField = new JTextField(); // global so it's in the same scope as popUpConf and it's thread.
public String popUpConf(String title, String msg) {

        // create a thread to wait until the dialog box pops up.
        (new Thread() {
            public void run() {
                // Sleep long enough for the window to pop up.....
                try {
                    // a half second should be fine...
                } catch (Exception e) {
                    // not required
                // request focus.

        Object[] message = new Object[]{msg, entryField};
        JOptionPane.showConfirmDialog(mainFrame, message, title,

        // return the string.
        String s = entryField.getText();
        return s;

In retrospect I probably should have used entryField.isShowing() and/or entryField.isVisible() to determine when I should request focus. Perhaps a short while loop with a small sleep value (50 or 100). Maybe I’ll go fix that now. But so far I’ve never had it barf on me. The only “error” is that it wouldn’t get focus, I suppose, which would be annoying but not unbearable.

Ok so that’s how you can set the font on a pop up confirmation box’s entry field. Cool, huh?

Concurrent Programming in Java

Perhaps the biggest problem facing concurrent programming today is the ‘herding of cats’ required to force programmers to adopt concurrent programming models. That, and concurrent programming is plain old difficult.

However, there are winds in the air that modern CPU architecture will finally force us to use concurrent programming. As it turns out, these winds are what has propelled good programmers all along; the desire to write a program that runs well on current hardware. To avoid bloat. To be efficient. And small.

As Java programmers, and more loosely as object oriented programmers, the desire to be re-usable (as OO programmers) and the desire to show that Java is superior (let’s face it, it is) similarly propels us to do our best to embody the principles of OO programming.

So let’s get to the point. Java doesn’t have an easy way to do Threads. You have to make all these complex checks and balances and it’s just a big bother, isn’t it? Plus, if you do design or think about program flow, it’s all too easy to visualize program flow as a straight line. A = 1, B = 2, A + B = 3. No one thinks about setting A and B at the same time. Why? Besides not perceiving a need (due to outdated, single-core hardware), one answer could be speed.

Setting A and B might take less than a handful of nanoseconds on a fast computer, but starting a new thread takes time. On my i7 system, I timed the creation-to-execution time and main program impact of 1 million threads. Every time I created a thread it cost my program about 35 milliseconds. Additionally, each thread began executing approximately 18 milliseconds after it was created. Obviously, creating a thread just to add two numbers at the same time is a waste of CPU time. Secondarily, you would need to wait for both threads to finish executing before you added the numbers. So all-in-all, calculating when you should use concurrent programming is a really big headache.

Incidentally this is also why the “sufficiently smart compiler” will never exist; calculating execution time can’t be done in advance. CPUs might be slower or faster, it’s based on real-time and not on some variable which can be known ahead of time.

So what do we know?

a) Concurrent Programming takes a small amount of time to set up (around 50 milliseconds on an i7, on average).
b) It’s easiest to use for small, independent, “fire and forget” tasks that don’t need to be synchronized with the main program.

Have any lightbulbs flashed yet? Well, let me tell you a story.

I was writing code on my Kongzi project, and it kept crashing in the UI thread, which locked up the program itself. I had to open task manager to close it which was a pain. I realized that I was committing a mortal sin of the UI world; I was doing extensive processing in the UI thread. The user would click a button, and the UI thread would fire the button event, which would take the software on a merry romp through CPU land. This was unacceptable, but I didn’t realize I was doing it. Later on, had I put the code into production, the UI would have seemed unresponsive and sluggish under more stressful “normal” use conditions.

So I decided to use a new thread to process the data and “return” immediately. After all, clicking the button just tells the program what to do. We don’t need to freeze up the UI thread each time.

It turned out to be a genius idea. I created a method like this:

// This function does whatever you want -- in a thread!
public void doWhatever()
        (new Thread() {
                public void run() {
                        // Thread Code Goes Here
 // return immediately!

Now notably, such a method can’t return any data (but it can modify global variables), since it does everything in a thread. But it’s perfect for updating status labels, for auto-saving, for printing, for doing any kind of complex task that you don’t want to do in the UI thread. One example can be logging. If you need to institute extensive logging, using a method like the above will return in about 35 miliseconds. No I/O time will be added to the main program. There are surely many applications for this in gaming as well; adding a thread which changes the status of an object over time, and exits on it’s own after a predictable length of time, is an easy way to code simple physics like gravity. Say, for a mario-world/2d platform game. Shots from a spaceship, for example, could be controlled by a thread. This would clean up your game loop considerably.

Now, you normally wouldn’t want to create one thread for each force vector on an object, for example, because 35 miliseconds of game loop time is a lot; that would be only about 30 “shots” which could be fired, or 30 objects created, forces applied, etc. per second. This could have disastrous effects on a program which requires 60fps or higher. Never fear; Have a monitor thread that creates threads for you! If it’s backlocked, it can clone itself and work twice as fast. What it does is monitor a queue and create threads. So you just “list.add(“object name”); for example, and the little helper threads go crazy doing their little thing. It all seems so simple now! The only problem would be locking the list so only one helper thread can pull a value off of it at a time. That’s not really a problem. Use the volatile keyword. “public int”? “public volatile int”! No problem. Use a synchronized block of code. Use a SynchronizedList. No problem! The point is that it will take far less than 35 miliseconds to add data to a list and pull it off again. This kind of simple messaging will help you return values from methods which run in threads as shown above.

In short, threads aren’t really that difficult or time consuming. They can really help. And sometimes they’re even required to achieve certain effects.

I’ll be able to post some more specific examples of this in a bit. Right now, I have to go to work. Sayounara!

Kongzi Beta-8 announced for June

Okay. Kongzi Beta-7 has been in classroom-use testing for about 6 months now and it seems pretty solid. A lot of changes have gone on under the hood. It’s using a database for the main type of save files now and you can merge (import) data from other files without destroying your user info. This will be tuned as time goes by, but as of now it is solid for general use.


All the quizzes have gotten a swift kick up in power, they now don’t just present random items but will sometimes present items which are similar to the correct answer. To do this I have created an engine which analyzes the user’s expected knowledge level and searches for similar words .This works in any language and with sentences (shown below) as well as with words (shown above).

Another thing which I’ve done is add the list of test mistakes to the score screen for easy studying. The following example is from the dictionary I use to teach “Let’s Talk in English” to Chinese students.


Once I give the manual a once-over and double check a few features on my to-do list, I’m going to have to start looking at how to package this beast.

For one, I plan to blow away the competition by offering a companion textbook with preloaded vocabulary. The MCI Chinese project (see the navbar up top) isn’t dead at all and has actually expanded with sister projects such as MCI Japanese and so forth. Here are some shots of the MCI Japanese book, “Welcome to Japanese”:





As you can probably guess I’m really excited to have reached this point in the Kongzi project and I will be able to package and offer these materials to YOU (well, to anyone) very soon. Target is this summer, around June for a complete Chinese/Japanese/Korean package which will take you from step one to “fluency”.

Thank you for keeping patient all these years. The wait has been difficult for me, too! But it is almost ready now, for real!

One step at a time..

An old draft from September 2009…

In just a few short days I seem to have come far enough that I am regaining my confidence working on this project.

I’ve re-integrated all the old logic back into the forms and re-created the “kong” and “ze” graphics from the calligraphy work I had done before. I’ve also identified several key areas which could be improved. For example, Beta-3 had a selective export feature. I asked myself, why was this necessary? If someone wanted to selectively export something they could just delete the stuff they didn’t want and then save it. So, this seems to make more sense, just save everything at once.

I also found and fixed a bug in my unicode encoder-decoder ring. Additionally I’ve completed the new export dialog design and as soon as I hook it up I can delete the old code for exporting tags and what not.

There’s just one problem. I don’t know what look and feel I was using. You can see a blue tint on the screenshots. I like that. And I can’t remember what I was doing. Ungh. I’ll figure it out later. Top priority is getting the anki/stackz-style flashcards up and running.

One step at a time… I’ve been reminded why I’ve been so successful with Kongzi so far. One step at a time, keep chewing away…