Wednesday, November 26, 2014

Android API First Impressions

I've recently finished my game and have started porting some of the Android only sections back to JavaSE. I have been struck by how everything seems so much easier with the Android API.

I find this very surprisingly. I've been using Swing for a very long time and have gotten good at doing crazy things with it. Even with my knowledge of Swing tricks and hacks it's still easier to do things on Android than Swing.

Take, for example, layouts. I've gotten to the point with Swing where I just use GridBagLayout from the start. I've got my own utilities that makes using GridBagLayout much less painful than it ordinarily would be. Gridbag is surprisingly flexible, if you've managed to survive its brutal learning curve. That said, doing layout with Android's isn't too bad. I certainly didn't have the parade of WTF moments that I experienced trying to wrap my head around Swing's layout system. Android also has the advantage of coming with a GUI layout editor. It means you don't find yourself blindly changing values and recompiling/relaunching every time to see if the changes did anything.

Then there are things like how do you make all the widgets translucent with an animated background? With Swing, I had to use the arcane knowledge I've discovered in my 10 years or so working with it. With Android it's just a property on the view or layout. Golly, that's convenient.

What about have multiple layouts on the screen at the same time and showing/hiding them like cards? With Android it's that way by default. With Swing it's a weird system of content panel layers or you can use CardLayout. Either way it's which is full of the usual Swing WTF moments: I have to do that to show a "card"? JLayeredPane is where?

Events are handled nicely too but to be honest, I was hoping for more here. Swing's event system is actually not too bad. Android's is very similar but also offers additional flexibility: you can define your event handler method directly in the layout. This is cute but this won't scale well if you have a fairly complex Application. That pretty much sums up my feelings towards Android event handling: It's good and tries to make things really convenience but the convenience comes at the price of preferring and unscalable application architecture.

Well, I say that but Android's encourages an application architecture that segments large applications into multiple activities which would help with scalability a great deal. I don't know how these two conflicting factors work out in real applications but I'm certain that either way there's more than enough flexibility in the approaches you can take to make everything work.

So, in conclusion, my experience with Android's APIs has been quite positive so far. I'm looking forward to more.

Tuesday, November 18, 2014


Whenever I hear someone start to talk about Agile methodologies I start to worry because, while the industry has agreed that Agile is the way to go, Agile is often misunderstood.

Agile is often sold to management as a way of getting better quality software faster, with fewer bugs showing up in the field. Well, that might happen as a side effect but Agile is really about being flexible. Change is a big problem on any engineering project. With most engineering disciplines change is very often fatal but at least it's easy to understand why. If you design an engine for a car and it doesn't fit, you're basically screwed. This is where the saying "measure twice cut once" comes from. With software it's not as obvious sometimes why a change would be particularly difficult because software is just a bunch of instructions. Just change the instructions! Duh.

It's never that simple. Software isn't constrained by the laws of physics. As a result, software projects have a tendency to grow in complexity until they become unmanageable. A typical project is a tangle of inter dependencies. Some of these dependencies are design assumptions, some of them are organizational assumptions - like budgeting and estimates. For example, if you write a piece of software for a desktop computer and find out that it really needs to run on a smartphone, you're basically screwed. It's doesn't matter that it's software.

Agile methodologies are a series of mitigation you build into your software and organization to make it resilient to changes during development. Those changes can be discovered difficulties or they could be mistakes.

In order to get into the Agile mindset you must first be convinced that planning is pointless. That the world is too full of unknowns and surprises that trying to plan is like putting on a contact lens in the middle of a sandstorm.


  1. Your time estimates are random numbers
  2. The man in charge of the requirements is a raving madman
  3. The chief architect has some kind of dementia
  4. What you're trying to build might be a logical impossibility anyway
So what does all this mean? It means you can't rely on estimates, the requirements still need to be discovered, you're going to make mistakes at the design phase and the whole thing might be a waste of time anyway.

In other words, it's a typical software project.

The only one thing you're not allowed to assume is that your programmers are idiots or are evil. If your programmers aren't excellent, trustworthy professionals then you're doomed no matter what you do. You might as well go outside and play Frisbee all day. You'll fail either ways but Frisbee is more fun.

Agile mitigation consist of things like this:
  • Chopping the project into many small pieces
  • Prioritizing these pieces with the goal of getting something useful quickly
  • Doing each piece one at a time; avoid over-design - YAGNI
  • Giving this "something useful" to the customer and finding out if you're on the right track as soon as possible
  • Re-evaluating the priorities of these pieces every day as new information is discovered during development
  • Pushing decisions to the edges of the org chart (developers or other) to allow developers to solve problems without a heavy vetting process (self organizing teams)
  • Lightweight, flexible and adaptable process - one that allows people to adapt to changes
  • Improve communication channels between people (co-location, burn down charts to track progress, bug database, unrestricted channels (anyone can talk to anyone else in the organization))
  • Techniques to write maintainable code. Unmaintainable code is by definition hard to change.

My key point is that Agile methodologies don't make change free. It doesn't make software development magically faster or higher quality. It's all about being flexible and mitigating the damage done by routine changes during software development.

Monday, November 17, 2014

Headsets and things

A little while ago I wrote a blog post about replacing my Plantronics 655 headset that had recently stopped working. Well, I spent a great deal of time searching for a good replacement and eventually came to the conclusion that there aren't any good headsets out there. Every single one of them has issues. Either the headset ear cups are not large enough, or the mike doesn't work very well or worse.

Razer Kraken USB isn't too bad. I didn't like the circular earpieces. They were too small (5cm) and the wrong shape. Ears aren't circular, not sure why they were with circular ear cups. Most of the reviews complained they fit funny.

The Steel Series headsets had terrible microphones. I like Steel Series as a company. My mouse is a steel series XAI but I would be embarrassed to use such a terrible microphone.

The worst, however, was the Sennheiser headset. Sennheiser has a fantastic reputation online. So good in fact, that when I found a pair of  PC333D G4ME going for cheap I bought them right then and there. They are normally out of the price range I would spend on a headset even with the sharp discount I got them for so I was hoping they would be amazing. Nope. Crushingly disappointed. Literally. They actually crushed my head with such force I couldn't wear them.

Have you even been back to an elementary as a grown man and tried to sit down at one of those tiny desks. That's pretty much what it felt like trying to put on the PC333D G4ME. I should point out I have never had anything close to this experience before. All headsets I have ever tried fit nicely on my head with plenty of room to spare. It's starting to make me wonder: do you have to grow up with this headset? Is it like artificial cranial deformation? You start off as a toddler playing games with this headset and over time your skull changes to fit the headset?

 Picture of typical Sennheiser customer skull

I had to send the PC333D G4ME back to the online retailer with a financial penalty so that has left me grumpy.

What surprised me is that it's very hard to find a headset with ear cups that are properly circumaural. All of them seem to have ear cups that are about a centimeter too small. Except for Plantronics whose ear cups are 2 cm to small. If you're wearing a headset all day they will press on your ears and become uncomfortable.

I was also surprised that many manufactures (some not explicitly mentioned here) ship their headsets with terrible microphones. If you're gaming online this tends to only annoy other people. However, if you're trying to do digital dictation, a good microphone is important.

The one manufacturer I haven't tried is Koss. This is partly because I can't figure out where Koss products are sold in Montreal and don't want to play the online ordering lotto again. The most comfortable headphones I own are Koss. Talking to their sales staff they might have a headset with large enough ear cups. I say might because no one at the company would commit to any measurements so I am still not sure.

At the moment I'm using a new pair of  Plantronics 655. They aren't the most comfortable headset ever but they were dirt cheap, they have a good microphone and they don't crush my skull.  I'll continue to use them until I can get a decent replacement.

Wednesday, November 12, 2014

Space Smilies (beta)

For the last 4 months or so, I've been writing a video game and it's now at the beta testing phase.

The game is called Space Smilies and is similar to space invaders but with a few differences that show themselves as the game progresses. It also includes a built in level editor so you can tweak your own levels simply by adjusting a few parameters.

The game is based on the old Space Smilies code that made an appearance on this very blog back in 2010. That code was in turn based on a video game I wrote in 1999 while studying at University so the code has had a long history.

The game is built for the Android platform, so if you have an Android phone (or Android compatible) you can try it out below:

Space Smilies for Android

Note, the link above is updated with new versions as they are built so if you want to get the latest build all you need to do is re-download it using the same link.

Monday, November 10, 2014

Nexus 5 and garbage collectors

I really like my Nexus 5. It's at the level of refinement where I would say everything works more or less correctly. This makes a change from my previous smart phone the Samsung Galaxy S. That was a terrible phone. The Galaxy S was too slow, didn't work as a phone owing to a terrible microphone, didn't work as a GPS, would flatten a battery in about 4 hours if you forgot to turn off the GPS or wi-fi and would crash fairly often too. I initially got the Galaxy S due to its reputation as a sort of landmark phone. I figure that means that phones before it were even worse somehow.

So, anyway, I like my Nexus 5. It works as a phone, GPS, keeps a charge and is stable. It also does a cute impression of a flashlight, has a decent camera and can make a sweet Mango Lassi. Well, everything except that last one. I feel like some kind of digital wizard carrying it around. Need a light? Boom! No problem. Need to know the weather? Boom! Weather radar! Need a map of Belgium? Well, that's random but I can get that for you too.

It's also been a good testbed for my application. I've learned quite a few things using that phone like....

Did you know that Android's garbage collector doesn't do compaction? For me this is a little like learning that Ferrari's new car is steam powered; it's a bit difficult to wrap my head around. I figure there some good, technical reason why they do this. I'd wager that they were trying to avoid garbage collector pauses. Google seems to obsessed with avoiding pauses or stuttering on Android (which they call "jank"). The thing is, if you don't have compaction you could run out of memory without.. umm.. running out of memory!

Compaction is the step that un-fragments memory. Wikipedia has good article on memory fragmentation but basically it's when memory gets filled with lots of little holes. Think of it like empty seats in a movie theater. If you arrive too late all the free seats are in singles or groups of two and are scattered all over the place. If you're in a group or four and want to sit together you can't because there aren't four seats together. Compaction is the step where you politely ask people to move around so all the free seats are in one big row - that way large chunks of memory can sit together. If large chunks of memory can't sit together you get an out of memory error even though there's technically enough free seats.

I think I mixed my memory-aphores there.. but you know what I mean.

Luckily the latest release of the Android operating system includes code that does compaction. Although they seemed to imply that it will only do it when you switch out of the application or something. I guess the garbage collector pauses are hard to notice when you've switched out of the application. Does this mean you'll need to switch out of the application you're using every once in a while to avoid running out of memory? I hope not. :-)

Friday, November 7, 2014

The last 10%

Well, that was a fun month or two. I've been working hard on my video game - getting it ready for release. It's so close to being completed I can smell it. To the extent that you can smell software, that it. The one major take away lesson I've learned so far is that software development is slow. Agonizingly slow.

I actually knew this already. I've been writing software for a good 15 years both on my own and in large teams, but it's just hit me again: software development takes forever.

Someone said, the first 90% of the product takes 90% of the time. The second 10% of the product also takes 90% of the time. This is pretty good summary.

The thing that trips you up is it's relatively quick to get something basic working. So if all you've ever done is a little scripting for yourself or in-house tools you're getting a warped perception. Once you want to release software commercially to actual users the quality needs to be much better. And I'm writing software in the consumer space - where no one cares that it's hard and there are no second chances; it has to be perfect first time.

For example, with this game I'm writing it took me about two weeks to get the program to work correctly when it's in the background. You would think this would be fairly simple. After all, it's unlikely you're ever run into an application on Android that's ever had issues when put into the background. Well, my game was crashing. After I fixed that crashing, the game would continue to play itself while in the background. After I fixed that the music would do the same. Then I had to release the graphics to free up memory to be a good Android citizen or risk being barred from Google Play store. Finally I had to correct an edge case where locking the phone would cause the application to reset.

It takes time to understand how things work on a new platform and how to design an architecture that works with the platform instead of fighting it. Throughout the process you can't help but think you're not adding anything to the product; I'm not adding levels or new characters or anything to the game. I'm just fixing stuff that should just work anyway. It also doesn't demo well: Look! Doing this doesn't crash! It did before?

 I don't mind though. In fact, it's what attracts me to the consumer space; because consumers have a choice. People aren't being saddled with your software because their organization chose it for them. They aren't being forced to use it because that's what their client uses. When someone uses your software it's because they want to. No IT department to help with the migration. No pressure to conform. You have to convince people to use it. In this sense it's a more honest type of software development. I've always had high expectations from the software I use and I've observed that, in aggregate, when they have a choice, human beings do too.