Archive for the ‘Programming’ Category

Will Someone Please Make the Kogan Agora Android Phone?

Tuesday, January 11th, 2011

Kogan Agora Phone

I’ve decided to rant a little on my frustrations with Android.  Don’t get me wrong, I’ve been a die-hard fan and developer since Android was announced, and I have owned and loved several Android devices, but I think there are still some problems with the handset makers.  At CES this year it seemed every phone announced was an Android phone.  ”Awesome” you might say, and they are, with the top-of-the line processors and screens and all. However, THEY ARE ALL THE EXACT SAME PHONE as far as the user’s overall experience is concerned (with exception of the Motorola Atrix 4G, and its crazy netbook hybrid technology).  They are all about the same size and shape with similar sized full, portrait screens, and fast processors.  Where is the variation of form factors? Android is flexible enough to easily support many form factors, screen sizes, devices.  It’s being installed in other devices such as tablets, TV’s, and even Refrigerators, so why not make some crazy, sleek, awesome form factor phones?

You may remember around this time two years ago that the Kogan Agora (Planning to be the second Android phone EVER) ended up being delayed indefinitely.  While this phone was not the hottest phone possible with a resistive touch display, mediocre processor, and limited features, I was a fan immediately after gawking at the first renderings.  Also, as a long-time Blackberry user, I loved the position of the hardware keyboard.  Furthermore, this phone represented the original idea of the Android platform – that it was flexible enough to install on a wide range of mobile platforms and form factors.

Two years have gone by, and I still don’t see my phone – the one that fits me like a well fitted pair of Jeggings.  You may be saying “What about the Droid Pro, or the Motorola Charm?” While steps in the right direction, these devices show the chunky design practices of Motorola (also not a fan of the BLUR user interface), and in my opinion, they would not be able to compete with the sleek corners and glossy smooth finish of the proposed Agora.

So is it the market demand that is driving every Android handset maker to release the same phone?  Is it the platform (while advertised as easy and open) limiting the hardware as far as a different screen size and orientation?  In any case I am disappointed in the lack of innovation of the Android handset selection currently on the market.

Disable Pre-Scaling of Android Image Resources

Monday, November 15th, 2010

As more Android powered tablets are released and announced, more developers should be making sure that their applications are optimized for them. In Android this means firstly stating that the application can handle any screen size with the following code.

<supports-screens
android:largeScreens="true"
android:normalScreens="true"
android:smallScreens="true"
android:anyDensity="true" />

Place this in your application’s AndroidManifest.xml file inside the <Application> tags.

However, this didn’t solve all my problems. While enabling my application to run full-screen on tablets without a big black border, it did some funky things with my image sizing. To accomodate large displays Android automatically scales Bitmap images to the display’s dpi. If you are using pixels for placement and sizing of images, like me, this can really screw up the way your app looks.

Solution

Drawable resources are stored in /res/drawable. However there are several other drawable directories you can use to support different things. I just wanted to disable scaling altogether. No matter what dpi the screen is, I want to draw my Bitmap at it’s native size. To do this, place all of these images in the /res/drawable-nodpi directory. Any resources in this directory will never be scaled. You will not have to change anything in your code as the Android API automatically checks this directory for the image.

Learn more on the Android developer guide: Resource directory qualifiers for screen size and density

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.

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.

Green Tree Update 1.2 Has Been Released

Tuesday, March 2nd, 2010

Many were commenting on some issues and frustrations with the app.  I finally got around to releasing an update that hopefully fixes many of those problems.  The issue with storms or bugs appearing while the game was paused should be fixed as well as a couple other bug fixes.  It should generally run smoother now as well.

Some were frustrated that their tree would die overnight.  While my response to this has been “You need to remember to pause before sleeping.”, I’ve made it so it should survive the night in most cases.  I’ve also added difficulty options so the player can specify a difficulty explicitly.

Please keep contacting me about suggestions or problems. They have been extremely helpful.

Distracted

Friday, February 26th, 2010

I feel I need to apologize to all the Green Tree uses for not paying enough attention to bug fixes.  I value everyone’s feedback and I hope to push some updates and bug fixes soon.

However, I do have an excuse for neglecting it.  For the past week or so I’ve been working on a new game.  If you like Green Tree I think you will like this one too. It’s a much more solid and smooth game as I have learned a lot since releasing Green Tree (my first Android app).  I can’t really spend much more time on it because I am broke, and I need to go find some paying gigs, but I hope to release this weekend.  So, check back often or follow me. I may post up some screenshots of it before launching.

Green Tree Re-released

Friday, January 22nd, 2010

greenTreeQrcode

I got a chance to test out my game some more on two phones and a few Android virtual machines.  Because of the nature of this game (The tree “grows” even when you are not playing) it takes a few days to test it out fully.  This was the reason for the number of bugs in the game before.

All that aside, I think it is a pretty fun game, and based on the emails I received after it was removed from the market, there seems to be a sort of a following for it.

To download, scan the above bar code above or search the market for ‘Green Tree’.

Thanks, everyone, for the support, and let me know if you have any issues or feature requests for me.

New Developments

Tuesday, January 12th, 2010

I feel I’ve utilized my time off well.  The job hunt will soon begin, so I had better do as much as possible while I can.  One of the things I hope to finish is my Android game I’m making.  I’ll probably be posting a beta of it on here very soon!

vtree-screen

It isn’t named yet but the basic idea is a virtual tree. The player must care for it by watering (but not over watering) it periodically.  There will also be obstacles that arise randomly such as storms that run the risk of drowning your plant, and bug swarms that eat away at your tree.  While the program does not actually run in the background, it is updated every time you open it as if it never stopped.  This way a user can play off and on for a prolonged period of time.  I hope to have it last from two weeks to a month or so (maybe even indefinitely).

The payoff: fruit that will give the player resources to buy tools and supplies to further the tree’s growth.

How to Use your Plain Old G1 as an Android Dev Phone 1

Tuesday, January 5th, 2010

The Android emulator included in the SDK is helpful in running and debugging your applications.  It provides the ability to spoof locations, calls, and texts and set the data speed to simulate slower networks. In fact it works almost as well as the real thing.  There comes a point, however, when you just need the real thing.

Things you will need

  1. A rooted G1. Haven’t really tried it with non-root, but really what you need is the USB Debugger feature. (I am using a CyanogenMod ROM)
  2. Windows.  I am covering the windows method, but other methods may be found here.
  3. Eclipse
  4. The Android SDK

(more…)