Category Archives: Software Engineering

Android Drawable Instances – Don’t Share Them!

Android robotRecently I’ve been implementing an animated user interface where the animations are defined in a proprietary file format. When the interface is brought up on Androidâ„¢, the file gets walked and all the View objects created; when an animation takes place, the definitions in the file are converted into Android key frames. Everything seemed to work well… until I imported a file with what seemed like a harmless optimization.

Several buttons in the user interface incorporated a “glowing” effect, basically by having the glow defined in an image file and animating its alpha transparency. The same image file was in use at several locations on the screen, just scaled to match the button. I decided to cache the Android Drawable, creating just one for each image and attaching it to multiple ImageView objects as necessary. As I loaded the file, the repeated copies of the glow image appeared in several places on the screen. Surely this would be more efficient?

Continue reading

Flattr this!

Finally Touch Typing With Dvorak

l never learned to type “properly” with a standard QWERTY keyboard. Oh, I gave it a try, getting hold of the Mavis Beacon software, circa 1992, and getting thoroughly frustrated typing nonsense like “fff jjj fjfj jjff” over and over again, never feeling like I was getting anywhere. Over the years, I’ve been able to achieve a respectable forty or fifty words per minute with two-fingered hunt and peck, although there hasn’t been a lot of hunting needed for years. “Eagle Finger” has sounded more appropriate. It never seemed likely I could get close enough to that kind of speed with disheartening touch typing exercises, and I never felt I needed to.

Continue reading

Flattr this!

Git With Subversion: The Trouble With Rebase

It wasn’t all that long ago that I was unfortunate enough to be working on projects whose idea of “version control” was merely to put all the source code in a shared network directory – thus failing to provide any notions of “version” or “control” whatsoever. Things are far more stable now; Subversion is widely used for projects that appreciate the idea of a centralized repository, while git appears to be the common choice for those looking for something distributed, with some remarkably powerful features. With the git svn bridge, developers can work locally (and even detached from the network) using git, and push their work to Subversion when needed. As a git convert, I would never return to straight SVN now; my first task when working on a Subversion project is to clone it with git. It appears to be a very common and successful workflow.

Continue reading

Flattr this!