bizarre Galaxy S3 driver success screen

I hope you are outnerdishly geeky enough to know that this means you’re on the path to android nirvana…

I came through iPhone territory by way of Handspring, then Zaurus, then Treo turf, so I can handle this kind of pain. But very disappointed…

  1. Install the Kies app from the google play store
  2. Fiddle with it for hours before discovering it’s useless.
  3. Stumble upon the Kies Windows app, install it from official site, let it spend an hour updating
  4. Try to use it and utterly fail to get any reasonable response from it
  5. But first, make sure you google to find all the other people with other different random stories of rage and sadness.
  6. Uninstall it and redownload a newer version from the same site the same day and install it.
  7. Plug your Samsung in and watch it fail to recognize it, fiddle for a few more hours…
  8. Fart with scattered settings on your phone to no avail
  9. Unplug and replug your phone while troubleshooting and reinstalling drivers in the right voodoo manner
  10. Use the Kies troubleshooter for a while, then realize its bizarre failure screens and minutes of spinning anuses are actually installing a working driver for your phone…
  11. In the middle of the night, through bleary eyes, see the Jelly Bean firmware upgrade notice – but only because you’re so tired that you watched a blank wait screen for far longer than any fully conscious human could ever muster.
  12. Have the firmware fail after it starts, scaring you to death, because it detects your battery is slightly below a full charge. Writhe in pain while you wonder if you’ve bricked the thing.
  13. Restart the whole process again after you unplug to charge your phone with a wall wart plug and the drivers get totally fubared all over again
  14. Watch the firmware get dropped on your phone, while you no longer give a shit because you are exhausted and disappointed and frustrated.


I’m using the cross-platform Qt C++ library to write an app for linux, OS X, and Windows. Qt source can be compiled to a wide range of systems and devices, with two obvious omissions that are not likely to be filled any time soon: iPhone and Android. I know I am going to need client code on these devices, and I know that the client code is going to be extremely similar to the Qt client code. How do you design for this?

Applying the concept of separation of concerns, you design your classes into layers. The base layer consists of high level concept classes that perform all fundamental actions using generic data types. Then, the derived layer is used to get the job done, using the most useful and powerful lower level tools at your disposal. Push everything you can into the base layer, until you hit the limit of non-portable information and data types. It’s a beautiful way to code.

To be more specific, in my case, the base class layer will be using C++, including the STL, which gives me tons of power. I will pull in boost if even more horsepower is needed. The derived class layer for the first round of clients will be Qt-powered. The Qt library has a massive amount of real-world usefulness, supporting everything from http to video playback. I have not gotten to the iPhone and Android clients yet so the whole concept may change, but here’s my current plan. The iPhone code will be Objective C with the C++ base class layer linked in. I will attempt to incorporate the C++ base class layer into the Android code using the NDK.

Here’s a quick example of the layer approach, in this case used to quickly set up profiling using Qt’s QTime class at the lower level: (continued…)