Bye bye birdie!

Last night i decided to do a digital reset of sorts. Ok, well maybe it was thrust upon me because silly me forgot to do a backup before i flashed a new custom rom on my phone. ALWAYS DO A FULL BACKUP FIRST!!!!

I usually do a backup. But i’d flashed this particular rom on several previous occasions and it had always worked flawlessly. Enter Murphy and his annoying law. This was at about 11pm. You know that sinking feeling you get when something really REALLY bad has happened and you’re not sure you can fix it? Ya, that’s what i felt when i was looking at my blank screen. Welcome to “you’ve been bricked”.

After several hours of frustration (at 2am i finally gave up, resigned to having to get a new phone soon – wasn’t that going to be a fun conversation to have with the wife. $$$). But wait, the story has a happy ending. Bear with me. I crashed, and woke up early (it’s impossible to sleep in with young school aged kids in the house). And within about 30 minutes my phone was humming along nicely. Moral of the story? Well. 1st moral: ALWAYS BACKUP before you do something potentially dangerous. 2nd moral: Never try to solve complicated tech problems at 2am.

Sadly, since i hadn’t backed up recently, the best i could do was restore an older backup from 2 months ago. Which might not seem all that bad. But … 2 months of angry birds 3 star levels lost? Seriously. That’s what i was most worried about. Everything else i could either get back through “the cloud” or my other backups. But my angry birds data was irretrievably lost :(

But as the day went on and i starting bringing things back online one by one, i realized something. Probably 90% of the “stuff” i had on my phone was digital clutter that i didn’t really care about. I hightly doubt i’ll miss it (including the angry birds, angry birds rio, angry birds seasons, angry birds space, and bad piggies games that sucked so much of my time). I’m curious to see what i do end up putting back on. Liberation!

Mobile coding lessons i’ve learned from writing an Android application

I recently completed a major version of an Android client for work.  I guess no program is every really “complete”.  But, it’s at a good stopping point for the moment so i thought i would jot down some of the lessons i learned.  These can really apply to any type of development, not just mobile Android.

  • The network layer is unreliable
First of all, cell phones have flaky connections that come and go.  They might be on wi-fi, they might be on a cell connection. They might be in a tunnel.  Maybe they’re in airplane mode.  Doesn’t matter.  You can’t count on a network always being there, and even when it is there, you have to assume that it will be flaky and return strange errors.  It’s important to have a robust network layer that has retries built into it for various errors such as timeouts, unavailable, etc.  Don’t just assume the backend is down.  Assume first that their connection is temporarily out of sorts, retry a few times, and THEN give up.  That will eliminate 90% of the network errors a user has to be aware of.  Oh, and some phones, vendors, flavors of Android all have weird little network quirks that only they exhibit.  Yet another reason for a robust network abstraction.
  • Deal with threading issues

If you don’t want to die from a thousand little cuts, design your code to be thread-safe from the beginning.  Many phones now have multiple cores and really do execute things in parallel.  Add to that fact that any complex app will likely have multiple IO requests in flight at the same time (whether from the file system, database, or network) that can return asynchronously, and you are ripe for threading problems.  Deadlock, data switching out from underneath you, etc.  Use the threading tools. Synchronize, lock, atomic operations and especially the concurrent package are your friend.

  • Be asynchronous

Seriously.  Don’t block the UI thread for any reason.  If you’re loading a file from the file system, accessing the database, making a network call, or even doing some heavy number crunching, do it on a thread and call back to the UI when you’re done.  Android has some nice abstractions to help with this, including AsyncTask, and Handler classes.  You can also do traditional Runnable’s if you like.  But whatever method you use, make sure you have an async layer built into your app that’s easy to use.  Make sure your main application logic can deal with everything being asynchronous.  Your users will thank you for a snappy app.  Corollary: Don’t block the UI needlessly with modal dialogs unless you absolutely have to wait for a result.  Let the user do other things while your background processes are running.

  • Be aware of constrained resources

Ya this is a fun one.  You have very limited memory in which your application can run.  We’re not on a desktop here.  Some phones are far worse than others as far as how much memory they let you have.  Loading images is especially dangerous for running out of memory.  Have a strategy in place to only keep in memory what you need.  Don’t keep things lying around longer than you must.  Memory is fast, but disk is cheap and certainly faster than the network and definitely better to take a few milliseconds to reload an image from the drive all the time rather than running out of memory and crashing the program.  So load it from the network, save it to disk, cash in memory until you run out, then just have some type of LRU cache.

  • Understand and work with the application lifecycle

This one may be somewhat android specific, but the general idea is sound for anything:  Each activity (screen/window) has a lifecycle.  It’s created, setup, running, paused, and eventually destroyed.  It might also be resumed and restored in the middle of all that.  The framework provides rules about when all these things happen and how you should deal with them.  Make sure you do the correct thing at the correct time.  Expect that since this is a mobile environment with lots of stuff going on that your activity might be asked to pause or shutdown at any time, even mid-process.  Save off your state, be able to restore it, and know how to deal with data inconsistencies that might result.  Don’t expect that x then y then z will always happen.  X and Y might happen, and you’ve started Z, but then a phone call comes in and your activity goes away.  When you come back, what do you do?  Make sure you do the right thing.

Googleborg

With the recent introduction of Google+, it got me to thinking how much of my life is tied up in Google. I did a quick count of how many Google products and services I use. Would you like to see the list? How does your list compare? Are we worried that Google will use this to ruin our lives at some point? Or is “do no evil” good enough for you to trust them with everything?

Used all the time (multiple times daily, daily)

  • Google search
  • Gmail
  • Chrome browser
  • Google music
  • Google reader
  • Google+
  • Google calendar
  • Google talk
  • Google voice
  • Android OS
  • Google news

Used often (multiple times a week)

  • Google docs
  • Google maps
  • YouTube

Used occasionally

  • Google buzz
  • Google groups
  • Google translate
  • Google bookmarks
  • Picassa
  • Google earth
  • Google alerts

Before rolling out of bed

I recently read an article that a growing percentage of people check various news and social networking sites before they get out of bed. Funny – I was reading that on my phone in bed after waking up.

I check the weather, the news headlines, Facebook, twitter, email, and then sometimes a few blogs. All before I roll out of bed. I wonder how many others do this.

The Grid


Sparked by the recent Tron movie, i started thinking about the hyper-evolved 1980’s environment which is “The Grid”.  Couple this with an interesting podcast discussion i was listening to about how different generations are interested in different things, and i find myself with something to post. :)

Think back to when you were in your teens.  What was the cool new thing at the time?  For my generation, it was home computers.  Sure, computers had been around for decades as big giant mainframes and house-sized computers in universities and government buildings.  But it wasn’t really until the early 80’s that they became accessible to the masses through the likes of Atari, Amiga, and Commodore.  They were magical things.  The world suddenly opened up to me.  I had this little box that i could control.  I could play pixelated games in 4 colors.  I could write papers and design ascii-art banners and send them to a dot matrix printer.  It made little bleep sounds.  And the best part?  I could write my own programs to do anything i could imagine (well … limited to the sparse programming materials i could find at the time).

The home computer was a wonder.  To my parents it was a little scary.  They didn’t quite know what to do with it.  They coped, but it’s never really been a core part of their lives.  Now let’s rewind a generation.  What’s the cool thing when my parents were growing up?  Televisions in every home?  They probably thought that was the coolest thing ever.  To me, a tv is just a tv.  It’s always been there.  No big deal.  I use it, i like it, but it doesn’t inspire me.

Rewind further.  Radio.  You can actually hear what someone is saying hundreds or perhaps even thousands of miles away.  At the same time as other people all around the country!  They’re talking TO YOU.  Telling funny stories, playing old time music.  But to me (and to my parents i’d imagine), it’s just a radio.  You use it, it’s there.  Certainly not awe-inspiring like it was to the generation when it first came out.  We can go further back, but i think you get the idea.

Let’s instead move forward a bit.  My kids.  They have computers.  All around them.  I’ve got phones that are far more powerful than any computer i had growing up.  My kids have them, they use them, they’re convenient.  But so what?  They’re just things.  They don’t inspire awe or imagination.  They are inspired by other things (although i haven’t quite figured out what it is yet.  Smart phones, music players, the internet, mmorpg’s, youtube, facebook, 3d movies)?

There is no “grid” for them.  Which is why Tron is probably just another movie to people from before or after my generation.  Sure, it’s got amazing special effects.  The soundtrack rocks.  But the concept of programs that look and act like us living inside of a virtual city?  To me, it was something cool to ponder and imagine.  Could it really happen?  To my kids … ehh.  They don’t have the context of wonder that i had back in the early 80’s when PC’s were just coming into their own and the grid was an exciting and revolutionary idea.  And it makes me a little sad.  And also a little curious and excited to see what the next revolutionary awe-inspiring thing will be.

Unit testing private java methods

Warning: dry tech article ahead.

As is often the case when beginning a new project, I like to get the ground rules set.  On a well done java project, unit testing is a given in my mind.  But one thing that’s always been a sticky point is how to unit test private methods and members.  In order to keep a clean class, you don’t want to change the scope of a method to public just so you can unit test it.  And you certainly wouldn’t want to put your unit tests inside your actual class.

Some other approaches include package scope or pass-through methods.  Again – this dirties your code just for the sake of a unit test.  After a few minutes pondering, i figured that reflection must be the answer.  And yes – there is a really nifty way to have your cake and eat it too.  Cleanly separate your unit tests from your code AND keep your private methods and members private.

But first, let’s hear the naysayers.  I was surprised to find that many people think you shouldn’t test private methods.  “If it’s private, it’s not part of the contract and the point of a unit test is to test the public contract of a class”.  I couldn’t disagree more.  Often times, business logic and important algorithms that only make sense to the class are encapsulated in private methods.  But in order for the “public contract” to work correctly, all of the underlying pieces must also work correctly.  Sure, you can indirectly test the private internals by assuming they work if you get the right output on a public call, but i just think it’s better to teach each of the individual cogs in the machine to make sure each piece does its job.  Then when you assemble it all together into a larger whole, everything just works.

Another counter argument is “if you test all these private methods, your test cases will be brittle”.  There’s a modicum of truth to that.  Chances are that if you stick to the public API’s, they will change far less frequently than an internal private method.  But i believe that if you properly design your code so that the private methods do one job and do it well, once you write your test, there isn’t much need to go back and ever mess with it again.  And if you do – be sure to update your unit test.

Ok, enough of the philosophy.  On to the technical details of how you actually accomplish this.  Let’s assume a class that has the following private member and method.

public class MyClass
{
    private int _myPrivateMemberVar;
    ...

    public MyClass() { ... }

    private String doSomethingInteresting(String s, List<Integer> li)
    { ... }
    ...
}

Now, how to access these from a unit test that’s not in the same class? Access it via reflection and change the access at runtime.

    //change the accessibility of the method and member
    MyClass c = new MyClass();
    Method method = MyClass.class.getDeclaredMethod(
        "doSomethingInteresting", String.class, List.class);
    method.setAccessible(true);
    Field field = MyClass.class.getDeclaredField("_myPrivateMemberVar");
    field.setAccessible(true);

    //call the method
    String myString = "foo";
    List<Integer> myList = new ArrayList<Integer>();
    String result = (String) method.invoke(c, myString, myList);

    //access the member
    int memberVal = (Integer) field.get(c);

And there you have it – accessing private methods and members at runtime from a unit test. Happy testing!

Don’t diss the Android, dude …

Someone sent me a link at work saying how poor Android is.  I had to respond.

Update: Silly me, forgot to include the original link.

This is my email:

> Android OS (whilst hidden behind the beauty that is HTC Sense) is an inherently geeky, inconsistent, temperamental and beta-like OS.

  • geeky: yes (and in my opinion, that’s a good thing. not everyone is an apple fanboy) :)
  • temperamentaland beta-like: to some degree, yes.  give it time to mature a bit more.  every iteration it improves drastically.  Google isn’t sitting still

> It responds inconsistently to what should be basic functions of a phone

  • Agreed.  That is sometimes annoying.  Slow to load the phone dialer.  Easily fixed via software update.

> Exchange sync having random hiccups.

  • Never noticed any problems with this.  I use the exchange sync for work email and have always had my email there when i wanted it.

> The limitation of the OS not allowing you to install applications onto the microSD card

  • 100% agree with this one.  It’s SUPER annoying and aggravating.  It limits how many apps i can have, how large and complex apps can be.  Google has said they’re working on this and with a future software update this will no longer be an issue.

> Auto memory management is poor at best.

  • Not sure i agree with this.  There is an excellent article here by a Google engineer involved in this that details how and why they did things the way they did.  http://android-developers.blogspot.com/2010/04/multitasking-android-way.html .  That being said, there are a few poorly designed apps that don’t play nice with Google’s best practices for memory management.  My response: Don’t use those apps.  They will get low market ratings and bad comments so you can easily avoid them.  And there are always a dozen alternatives that don’t have the problem.

> Android is not and can not be an “iPhone Killer”, nor really even a competitor.

  • I’m always annoyed when someone says “Android is an iPhone killer.  It’s not.  But i do think it’s a valid competitor.  Especially with the newer versions of the OS and the newer hardware (Droid Incredible, Nexus One, EVO 4g).  It’s numbers are growing like crazy.  In fact, last quarter, Android outsold iPhone.  (Both of which are behind RIM, which itself is waaaay behind Nokia).

> The Android market is disjointed, confused and inconsistent, whilst Apple have created a stable, consistent platform that whilst limiting in some ways, allows users a level of comfort that Android does not.

  • Apple-fan boy speak there.  I 100% disagree with this statement.  It’s precisely Apple’s “stable, consistent platform … limiting in some ways” that has made me have absolutely no interest in doing personal development for iPhone OS.  I don’t want someone telling me what i can and can’t put on the market.  “Oh, we don’t like your app, sorry”.  and people with big public forums or insider clout at apple get their apps through anyway, where the little guy wouldn’t.
  • And it’s exactly the disjointed, confused, and inconsistent Android market that excites me.  It’s challenging.  Yes – you have different screen resolutions and OS versions.  All of which are documented in detail and EASY to code for and test in the emulators.  It adds maybe an hour of time to do a little testing for different screen sizes.  So what?  And hey – i can publish anything, anytime.  If it’s crap or malware, the market will rate it poorly and nobody will download it.

> Ask older Android handset owners if they enjoy being stuck on Android 1.5

  • He has a point here.  My response: Get a new phone. How long do people keep their phones on average nowadays?  usually the 1-2 year contract from their carriers.

> you can now walk into almost any store anywhere in the world and buy an accessory for an iPhone.

  • That is a also a good point.  But i have no trouble finding accessories on Amazon.  I rarely walk into a store to buy any tech accessories anymore…  Plus it’s cheaper.  You can get a standard micro-usb cable for $5.  You don’t have to pay $30 for a special iphone cable :)

> Too many form factors. Too much variance in OS versions. Too many product releases, too quickly.

  • I think that’s a good thing.  Choice.  You don’t like phone x?  Try phone y.  You want something fixed?  You won’t have to wait long for it, because the releases happen quickly.  Release early, release often.

Both sides of the argument have merit, and i think that both OS’s have a place.  iPhone rocks, no doubt about it.  But don’t discount android as over and done with.  It’s not going anywhere but up.  The more choices consumers have, the better.

Why my bluetooth headset doesn’t like that i’m a lefty

For our anniversary last week, Luann and I decided to go out and each get a set of nice bluetooth stereo headsets for our phones.  We each had different uses in mind. She wanted some light-weight behind the ears/neck that would be good for exercising.  I wanted a nice set that would give excellent sound quality for music / sitting in a cube type setting.  After some searching, we both found what we were looking for.

After a short honeymoon with my new headphones, i started to notice a glitch.  The sound would occasionally cut out briefly.  It was intermittent and sometimes just happened once, sometimes repeatedly.  I couldn’t figure it out.  Did i get a buggy headset?  Was my phone not compatible?  I’d done my research.  These were highly recommended headphones and my phone supported all the right bluetooth specs.

I wasn’t about to give up so easily though.  I loved these things, when they worked.  So last Friday (the same day as the coke incident), i had them on and was just cleaning the kitchen (again, refer to the coke incident) when i noticed the occasional cut-out.  But it only happened when i was facing a certain way.  I didn’t even have my phone in my pocket or anything.  It was sitting on a counter a few feet away from me.  Well within the bluetooth range.

Suddenly it hit me!  My bluetooth headphones didn’t like the fact that i was left-handed.  I kid you not!  No, seriously.  Stop laughing.  It’s absolutely true, and i’ll tell you why.  Whenever my phone was on my right, it worked flawlessly.  Whenever my phone was on my left they would occasionally cut-out.  Why?  Simple.  The headphones receiver is on the right.  Yep.  A simple obstruction like my head or my body or occasionally even my hands/arms would be enough to block the signal for just a second.

This isn’t a big deal for voice when you’re on the phone, but if you’re listening to music at high bitrates, the little pops and cutouts are really annoying.

Solution: Put my phone in my RIGHT pocket rather than my left pocket.  Also, keep it on the right side of my desk at work instead of the left.

eInk v tablet

I had a big old post written up, and was just tweaking it here and there before posting when my computer crashed.  I thought macbook’s weren’t supposed to do that sort of thing.  Oh well.

I’m too lazy to recreate the entire thing, but i’ll just outline some of the main topics i was discussing.

Which is better – an eInk device, or a tablet device?  Or another way to say it would be “If you were to go shopping today, would you buy a kindle or an iPad”?

Kindle has several advantages:

  • Battery life lasts forever.  I sometimes go weeks without charging.  And i use my kindle almost every day for an hour or two at night before bed.  Of course, this is with the wireless turned off.  I only turn it on when i want to transfer a new book i’ve purchased via the “whispernet”.  And to be honest, most of the books on my kindle are not from Amazon and so i just sync them via the cable.
  • You can view in direct sunlight.  The brighter the better.  Do you want to read outside on a warm sunny, summer day?  I sometimes do.  And this works perfectly for that.
  • It’s amazingly easy on the eyes and the device fades into the background.  You quickly forget you’re reading on a device and are just focusing on the story.
  • You can read the same book on multiple devices (thanks to the Kindle app) and pick up wherever you left off (at least, assuming the book was purchased through Amazon).

Kindle has several disadvantages:

  • The eInk refresh rate is slow.
  • The display is greyscale.
  • It’s difficult to annotate and there’s not really a good way to search / share your annotations.
  • You can’t read it in the dark without a light.  Do you like to read in bed at night with the lights off?  I do.  All the time.

iPad has several advantages:

  • Sleek interface
  • Fast
  • Has the Kindle app, as well as a native ebook reader
  • The screen looks beautiful (especially in the dark at night lying in bed)
  • Easy to add annotations
  • Would be easy to add sharing features, animation, colors, embedded media content, etc..

iPod has several disadvantages:

  • Apple
  • Apple
  • closed, ferrari device with a pinto engine
  • can’t view very well in the light at all.  no reading on the beach or in the backyard unless you’re in the shade and the sun isn’t on the device

So which would i choose?  I have a kindle.  I love my kindle.  I wouldn’t buy it again at this time because of up and coming alternatives.  I also don’t plan to get an ipad.  I’ve been playing with one now for a week or two and it’s nice, but there will be nicer devices (and probalby cheaper) coming out in a few months.  I’ll probably get one of those.

Yes, eInk is better than some type of lcd display on a tablet, but bottom line? It’s not THAT much better that it really makes much of a difference.  Maybe in a few years eInk will be faster and prettier, but for now … it’s had its day and it’s time to move on.  Maybe a dual eInk screen/traditional screen “fold-up book-form tablet” is the way to go.  Then you get the best of both worlds (except that it won’t be as thin or “sleek” as an iPad).

(i wish there were a) Palm emulator for Android and iPhone

As i was sitting there using my Android phone this morning, and my wife was using her iPhone next to me, i thought of all the great apps that exist for these devices.  There are literally over 100,000 apps for the iPhone, and over 20,000 for Android.  Of course, probably 80-90% of those are “crapware”, but hey … that still leaves a lot of great apps.

Even so.  Think of Palm.  Sure, today they’re pretty much a has-been, but Palm was the king of the hill for a LONG time.  And during the height of the Treo years, there were tens of thousands of excellent apps written for the Palm.  I even have a few that i still run via the desktop emulator now and then.

So let’s combine some thoughts here.  I have an NES emulator for my Android phone.  It allows me to play literally hundreds of old-school games.  It’s amazing, and works perfectly.  Why not create a Palm emulator for Android and iPhone?  Think of all the great apps everyone would suddenly be able to run!

As a completely unrelated side-note: Why won’t the makers of Pocket God create an Android version?  Or even a WiiWare version?  I’d buy either (probably both)…