Archive for August, 2010

SQLite Batch Transactions

Thursday, August 26th, 2010

Just wanted to give props to this guy, circle. He gave an awesome tip about doing many inserts into a SQLite database. Instead of having each statement be treated as its own transaction, group them into one big transaction to cut down on overhead.

Android App Updates: Get to the Top of the “Just in” List

Tuesday, August 24th, 2010

I noticed that when I push a new update for one of my apps, it bumps it to the top of the “Just in” list for my category.  When I tried the same for my newer app it didn’t promote it the same way.  I decided to do some research and found that if you wait about a week between your updates, the Android Market will bump you to the top. That’s actually pretty convenient for a smaller app since a good dev cycle including plenty of testing is about a week (at least for me), and discourages posting constant trivial updates just to continue to stay at the top of the list.

Why is this feature in the Android Market a good thing? People are constantly looking for new content, new games, and updates. You would think it’s kind of cheating to bump yourself to the top of the “Just in” list every week, but it’s really a good thing for developers as well as end users. It ensures that applications that are under active development get exposure while stale ones bubble down to oblivion and also promoting bug fixes and feature additions for anyone wanting the attention. It is a necessity especially in the Android Market with the store becoming flooded with duplicate and garbage applications.

New Release: Pineapple Farm

Thursday, August 19th, 2010

farm3

My newest game, Pineapple Farm, is now available in the android market.  If you liked Green Tree and Planet in a Bottle, I’m sure you will enjoy this one.  The goal is to grow your crops and build up your farm by buying nearby property.  There are also items you can buy that will help you automate maintenance on your fields.  Find it in the Android market by searching for “Pineapple Farm”, or use Barcode Scanner to scan the QR code below.

farm-qrcode

Android Bitmaps and Memory Leaks

Sunday, August 15th, 2010

I wanted to share some info that I have been learning about in my latest project. It seems that Android has an interesting way of memory management for Bitmaps. Drawables seem to act normal and get cleaned up with the garbage collector, but Bitmaps are apparently not in the normal application heap. This causes problems… for me anyway. There is an awesome article about it here if you want to learn more about it and how to find memory leaks in general.

Basically the solution to this problem is to manually recycle any Bitmaps you create once you are done using them. This seems pretty simple because you can basically call recycle() on all your bitmaps in the onDestroy() hook in your Activity. However, most of the time you have a separate thread running that is using these image resources. If you recycle your bitmaps in the Activity, there is no guarantee that your background thread won’t come searching for these resources before it dies.

My solution: I created an “ImageManager” class.

class ImageManager {
    private HashMap<Integer, Bitmap> mBitmaps;
    private HashMap<Integer, Drawable> mDrawables;
    private Context mContext;

    private boolean mActive = true;

    public ImageManager(Context c) {
        mBitmaps = new HashMap<Integer, Bitmap>();
        mDrawables = new HashMap<Integer, Drawable>();
        mContext = c;
    }

    // We need to share and cache resources between objects to save on memory.
    public Bitmap getBitmap(int resource) {
        if (mActive) {
            if (!mBitmaps.containsKey(resource)) {
                mBitmaps.put(resource,
                    BitmapFactory.decodeResource(mContext.getResources(), resource));
            }
            return mBitmaps.get(resource);
        }
        return null;
    }

    public Drawable getDrawable(int resource) {
        if (mActive) {
            if (!mDrawables.containsKey(resource)) {
                mDrawables.put(resource, mContext.getResources().getDrawable(resource));
            }
            return mDrawables.get(resource);
        }
        return null;
    }

    public void recycleBitmaps() {
        Iterator itr = mBitmaps.entrySet().iterator();
        while (itr.hasNext()) {
            Map.Entry e = (Map.Entry)itr.next();
            ((Bitmap) e.getValue()).recycle();
        }
        mBitmaps.clear();
    }

    public ImageManager setActive(boolean b) {
        mActive = b;
        return this;
    }

    public boolean isActive() {
        return mActive;
    }
}

This does two things: first, it makes it easy to recycle all your bitmaps and keep track of when you have recycled them to shut down your app, and second, It enables you to share repeated resources.  In my app, I have images that I use many instances of. Previously I would instantiate a new Drawable or Bitmap for these using up memory for a resource I already had in memory.  When you get a resource from the ImageManager, because it keys on the drawable ID, it checks to see if it is already available before loading it again.

It also makes it a little easier to get an image.  the ImageManager object you create will have to be passed to every object you want to use it, but when it’s available just call im.getDrawable(R.drawable.whatever) to get your Drawable.

You will still have the problem of the background thread trying to access assets after they are recycled.  To avoid this you will have to either check every time to see if the ImageManager is still active, or (the lazy way) catch the NullPointerException it throws when it tries to draw.