Monthly Archives: January 2014

Spot! Animals


As a kid I loved Where’s Waldo.  It was the perfect game that never got old.  Each page was jam packed with tons of items, and it took hours to find all of them.  Where’s Waldo and I Spy were the inspiration for my latest app.  Today I announce another project I’ve been working on called Spot! Animals.

It is a seek & find app for young kids where they search for animals at the zoo, ocean, safari and more.  It is simplified slightly to make it easier for young kids, but there is still many things to find and plenty of replay value.  I’ve already had Logan come up and tell me over and over ‘animals, animals’.  It is always good to have happy customers before it has even launched.

This will be the second app that I’ve contracted nearly all of the work from scratch.  That includes paying for all the development, art, and music.  This is fun for a couple of reasons.  First  of all it is a fun and new experience to take a step back as a developer and jump into the manager roll.  And second because it is fun to have grown my business to a point where I am able to do that.


On the other hand it is hard at times to let other developers design and write the code.  I know it is important let go, but it is hard when I know I’ll probably end up putting time into bug fixes and polishing the app after all is said and done.  I’ve also grown a respect for management in general.  I’m surprised how much time it take

s to find good talent, give a complete vision, and follow up to make sure everything gets complete.

Anyway, the game will probably be released in February 2014, so wish me luck as I wrap things up.

Advice From Three Years of Android Development


Three years ago I started my foray into Android development.  I had followed and played with Android off and on for a while before that, but that is when I started my first app that would eventually get published.  I’ve learned lot’s over the last three years.  Below are some of the lessons I wish I knew when I had started.

1) Iteration –

You will never get it right the first time.  There are so many factors to a really good app:
– Is it a good idea, will it resonate with people?
– Will it work on the huge variety of Android devices?
– Will it be found by potential customers that are looking for it?
– Will you make money off of it?
– Will your users take the time to rate it, write about it, and talk about it?

The fact of the matter is, if you are a single-person operation you can’t answer all those questions before you launch.  Worse yet, you’ll probably spend a lot of time thinking and stressing about them.  But, after you launch, answering those questions becomes a lot easier.  Users will quickly let you know which devices are broken.  You will also find out if it is well downloaded, enjoyed and rated.

The fear is that you’ll lose that first bump, that your app will be marred by bad reviews and never dig itself out of the hole it first started in.  But it turns out that those first days, weeks, even months aren’t really that important.  Your app’s growth will be slow and steady, and you’ll have plenty of time to fix those issues.  Even if your app is downloaded lots, it will tend to maintain that velocity and you’ll have plenty of time to overcome bad reviews and issues.

But only if you iterate.  If you let it sit, it will never get better.

2) Go small – 

Everyone says go big or go home.  This couldn’t be further from the truth as a single app developer.  The best apps are developed by large teams that contain artists, businessmen, designers, developers, and a whole lot of money.  You can not compete, no matter how hard to try.  But the app marketplace is full of customers, and that gives you an advantage that most domains don’t enjoy.  To date there are over a billion Android activations, so even if your app will only be found by 1 in a million, you are still looking at one thousand downloads.  And trust me, you can do much better than that.

The goal is to find a niche market, and build a super simple app.  Don’t add any extra features.  Don’t try to compete with the big kids.  Just keep it simple, well designed, and with a single purpose in mind.  You save time, but get to test the waters a little before investing a lot.  And if you plan to iterate it is easy to add more later, assuming it is well accepted.  Your customers know better what they want than you do, and when you give it to them they’ll be super pleased to have their voice heard.

3) Confide in experts –

No matter how good you are at one thing you are terrible at many others.  When I first started I assumed I could do it all myself.  I’m a great developer, I’ll let that part shine through, but I can also handle the art, music, and business side of things myself.  It turns out, I’m really bad at art.  I mean, my art may be passable in some circles, but the moment you see an experts art nothing else compares.

Don’t get me wrong, to some degree you’ll end up wearing all of the hats.  If you are a single-person operation with no money you don’t have any other choices.  But the moment you can defer your expertise to others.  And the moment you have money iterate with it.  Go find artists to redesign your apps, marketers to improve your listings, and even other developers to alleviate some of the workload.

Find what you are expert in, and focus on that piece.

4) Throw it away – 

Sometimes you will believe you have a great idea.  You will put time, effort, and hours into it.  And one day you’ll wake up and realize that it doesn’t jive.  Perhaps it isn’t a good idea after all.  Perhaps it is too much effort, or puts you in league with the big kids.  Perhaps the people you confided in didn’t follow through, or were as expert as you hoped.  Just throw it away.

It will be hard to do.  Because you’ll have invested so much time and effort into it that you will feel obligated to follow through.  But it turns out that the cost is much higher than the reward in those cases.  Familiarize yourself with the sunk costs principle, and try to recognize when your costs won’t be rewarded after all.

But the good news is, if you are planning to iterate, throwing away isn’t terrible.  You can throw away a piece and iterate over it again.  You can throw away an idea, and start a new one.  Throwing it away shouldn’t be looked at as a terrible idea, but rather a price you paid to improve the quality of your idea or app.  You paid it because you didn’t know the answer, but now that you do you can create a better version.

All in all I believe this experience has been overwhelmingly positive.  But I think if I would have known those four points from the beginning I would have stressed less and enjoyed more.


5) Be Patient

Of course you want your app to be successful.  And it will hurt when you only see a small number of download a day.  But those small numbers add up and will compound with time.

When I first release Palette Painter it was only getting 1 or 2 downloads a day.  That grew quite a bit as I iterated over and over.  But it capped out at about 300 downloads a day, a small number compared to many other apps, even many of my other apps.  Yet those 300 a day have slowly added up, and Palette Painter now has a grant total of 49,000 fairly active users.  While still small compared to my other apps it isn’t a tiny number.  And due to the nature of the app people spend more time in that app, and the revenue is just as high as my other more successful ones.

I almost gave up after Palette Painter.  But I now believe it is probably my most successful app so far.

Goodnight Lad


I’m always looking for fun ways to learn.  Over the past decade many new methods for learning have been discovered.  Not only is information more quickly available, but there are many great new ways to explore it.  Interestingly, while technology has taken off, traditional school learning has stayed much the same.  Today I’d like to share one of the projects I’ve been working on: An augmented reality children’s bedtime book.

The idea is that you would have a traditional print book that a child could read and enjoy like normal.  Point a smartphone at it and the world becomes alive in a beautiful interactive 3D scene.  You could see the child rolling in 3D as if floating above the book.  You can interact with it, and even have it read to you.  It is a fun new twist on reading that hopefully will encourage kid’s to want to read and imagine many worlds they can’t see.

Unfortunately 3D modeling is fairly expensive for a single developer like myself.  The story is  written, the book is  illustrated, the code tested, and I currently have a group working on modeling the first page.  My plan is to hopefully garnish interest from others who believe this is a fun new way to learn and to run a campaign on Kickstarter.


I’m really hoping this project pans out, all the pieces are in place for it to turn out wonderfully.  But more than this project I imagine a really cool future of learning. Imagine text books where the math jumps o ut of the page and comes alive.  Or where you can see the anatomy, geography, or astronomy in 3D as you learn about it.  It would encourage you to get up and to circle your book, to view learning from a whole new perspective.

Anyway, it is one of the many projects I’m working on.  I should be getting 3D models back soon, and I plan to update with more pictures once I do.

ListView Customizations

ListView is one of the most useful Android layout classes, but customizing it can be tricky. Part of that is simply glossing over some of the nice features that are already included. It is easy to simply extend BaseAdapter; it is easy and takes care of most the abstract methods for you. But doing so may make you miss some of the nifty built-in features. Below are 3 features you may be missing out on.

1) Custom Types
It turns out that most really good looking ListView’s aren’t just a simple list. The items contain headers, sub-headers, different layouts for different children and so on. But if you extend BaseAdapter you lose all the ability to use custom types.

If you override:
public int getItemViewType(int position) {
return position % 4;

public int getViewTypeCount() {
return 4;

And like magic you have multiple types. The above simply iterates over each type, but real examples would have complex criteria for which type a position is. Then inside your getView simply inflate different layouts for each type and the ListView handles the data for you.

public int getView(int position View convertView, ViewGroup parent) {
int type = getItemViewType(position);
switch (...) {
case 0:
// Inflate type 0.
case 1:
// Inflate type 1.
return view;

2) Custom Separators
Next it may be useful to create custom dividers. But if you do this using items then your dividers will also be selectable. Another nifty method to override is isEnabled. By returning false the item will be visible, but will not be treated like an item but rather a divider.

public boolean getEnabled() {
return false;

public boolean areAllItemsEnabled() {
return false;

3) Setting Stable Ids
The main advantage of stable ideas is the ability to do multi-selection on an ListView, GridView or other View. As long as your ids are unique, you can easily enable this feature by overriding:
public boolean hasStableIds() {
return true;

So while it may seem convenient to simply override the BaseAdapter, don’t forget all the nifty features you may be missing out on!

Android Scene Transitions

One of the less published features of Android KitKat 4.4 was the addition of a new animation framework for Scene Transitions. This is a really nifty framework for developers, because it allows easily providing two layouts and letting the system handle the animations between them. This can be a powerful but simple way to change views around with beautiful animations. While animations in general have been around forever (and they saw a great update with honeycomb) this just makes it even easier. Now you simply provide scenes via xml and let the system do its magic.

Of course with all the new features of Android there is always the question: “When will it be available?”. Since it will probably be years before Android KitKat+ is over 50% of the devices, it is easy to quickly discount the code and move on. Fortunately, though, all the code is Open Source, so I made an attempt to backport the code in a Scene Transitions support library.

In the end the refactoring wasn’t too difficult. Most of the code moved over with minimal problems. But I did run into two big snags, both due to new code.

1) Missing suppressLayout.
New to KitKat ViewGroup’s have a hidden method called suppressLayout. The code is fairly simple, it essentially prevents a layout from being called for some duration of time. The hope was to be able to copy this code over, but my attempt was ruined when I found out that ViewGroup’s layout method is declared as final (which is where the suppression code is). So in order to get this to compile I simply stripped the suppress layout feature.

2) Missing setTransitionAlpha.
New to KitKat View’s have a transition alpha that is composited with their view alpha. The original idea was once again to extend a custom View for this feature. But, since this is applied to all the children in the layout it would be super painful to create a custom view for each of them. Once again the code is stripped. I believe this means views with an alpha less than one won’t work correctly. But if they are few and far between the code could be retrofitted such that only those would have to be replaced.

The result was a mostly working scene transitions. Because of the missing features it is clear to me there will be cases where this won’t work correctly. So use at your own risk.

The final product can be found here: