A Weekend of Thanks

A Weekend of Thanks

As the Memorial Day Holiday here in the U.S. is upon us, I find myself thankful for many things.

Thankful for those in our military, past and present, for their sacrifice in toil, blood, and treasure.

And thankful for the people around me who make my life the good life that it is – my family, my friends, and my colleagues.

This past week has been very gratifying personally and professionally, and I simply can’t relate how grateful I am for the successes now enjoyed and the people who have made it all possible.

Thank You.

Here’s to wishing everyone a safe and restful holiday weekend… hello, Summer.

Being a Fan Boy – I Don’t Get It, And Never Have. I’m Looking at You, Tech “Press”

Being a Fan Boy – I Don’t Get It, And Never Have. I’m Looking at You, Tech “Press”

Something that I’ve never understood as someone long steeped in the Tech Industry is the Fan Boy.

You know ’em when you see ’em or hear ’em.

They’re the people who say Macs are so much easier to use than PCs, though they’ve never owned or used a PC.

They’re the people who used to sit beside you in Comp Sci declaring Rails is the best thing since Jesus, though they’ve never had a job in programming.

They’re the people crying about Apple being the anathema of open standards, and keep “Open” companies (like Adobe) “down.” (sorry if I caused a spit take there).

People.

The companies you project messianic qualities onto are there for one purpose, and one purpose only.

To make money off of your gullible asses.

You love Android?  Cool.  Apple is the Bees Knees?  Fab-oo.  Can’t live without your Blackberry?  Awesome.

But I swear to G-d, if I see one more fawning “journalist” creaming over a product that doesn’t exist, in a niche that has a history of repeated failures (** cough ** Web TV ** cough ** Apple TV ** cough ** Google TV **) I’m gonna yak.

Every story doesn’t have to be balanced.  But it should at the very least be objective and based on reality.

For example, because Adobe announces that mobile Flash will be available in June for one phone doesn’t mean that mobile Flash is available.  It’s not AVAILABLE until it’s AVAILABLE for Sale.

Maybe I’m simply cranky this morning.  I haven’t been so amazed at the gullibility of the tech press since they got woodies over Google’s “Open Social” announcement several years back.

I’m expecting about as much success out of Google TV.

And since pissing on Fan Boy parades always results in “I know you are, but what am I”, let me disclose that I own multiple IBM PCs, multiple Apple iPhones, multiple Apple iMacs, an Apple MacBook Pro, a Google Android Droid, and a Blackberry Bold 9000.  I honestly could care less over what tech company “prevails” – as long as I can create something of value on a platform that people use, and that makes their lives easier in some small way.

Maybe I should just choose sides already and surrender to the Fan Boy-dom.

But I simply don’t see the profit in it.

Scarce Commodities – Google Android, Memory, and Bitmaps

Scarce Commodities – Google Android, Memory, and Bitmaps

Working on mobile devices forces one to make conscious decisions regarding coding choices, if for no other reason that resources are scarce (memory, screen size, bandwidth). Taking the easy route and ignoring wise mobile programming practices can take what could be a promising application and make it a disappointing user experience.

If you’ve spent any time with the Google Android SDK, and have tried to read a JPEG into a Bitmap using Media.getBitmap, you’ve almost certainly run into this little gem of an error message:

bitmap size exceeds VM budget

Unfortunately, since Android caps all applications’ VMs at 16MB in size, it only takes one or two big image reads to get you into trouble, regardless of all the garbage collection and Bitmap recycles you may try (see code snippet at the end of this post for more on that).

So, what’s a programmer to do?

Well, the only thing one can do is to read only what you need into memory.  That means that you won’t be able to read in that 10MB jpeg sitting on your phone (at least, you won’t be able to read it reliably and / or repeatably) without trimming it down a bit.

The code below will do this for you; rather than calling Media.getBitmap, use this readBitmap function instead:

 

 

// Read bitmap
public Bitmap readBitmap(Uri selectedImage) {
Bitmap bm = null;
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 5;
AssetFileDescriptor fileDescriptor =null;
try {
fileDescriptor = this.getContentResolver().openAssetFileDescriptor(selectedImage,”r”);
} catch (FileNotFoundException e) {
e.printStackTrace();
}
finally{
try {
bm = BitmapFactory.decodeFileDescriptor(fileDescriptor.getFileDescriptor(), null, options);
fileDescriptor.close();
} catch (IOException e) {
e.printStackTrace();
}
}
return bm;
}

 

The magic fairy dust in this function that allows you to trim down large bitmaps into digestible sizes is the options.inSampleSize property.  inSampleSize – in this instance – takes a bitmap and reduces its height and width to 20% (1/5) of its original size.  The larger the value of inSampleSize N (where N=5 in our example), the more the bitmap is reduced in size.

There’s also another coding practice that one should always use when dealing with Bitmaps in Android, and that is the use of the Bitmap recycle() method. The recycle() method frees up the memory associated with a bitmap’s pixels, and marks the bitmap as “dead”, meaning it will throw an exception if getPixels() or setPixels() is called, and will draw nothing.

In my projects, I have a helper function that does cleanup when I am finished using a Bitmap, named clearBitmap:

// Clear bitmap

public static void clearBitmap(Bitmap bm) {

bm.recycle();

System.gc();

}

 

Dealing with memory errors on Android apps seems to be the “problem child” issue that crops up the most (like too many threads on Blackberry apps – different post for a different day).

But like parenting a problem child, what’s called for is attention and intention to mitigate havoc wreaked.

Download and Play a WAV file… using Objective-C

Download and Play a WAV file… using Objective-C

A client had a question this morning about loading a WAV file over the web and playing it from within an iPhone app.

Turns out it’s not too difficult to do:

// Grab the sound we wish to play from across the web
NSData * data = [NSData dataWithContentsOfURL:[NSURL URLWithString:@”http://www.dailywav.com/0510/worstSunburn.wav”%5D%5D;

// Load the data into an AVAudioPlayer object
AVAudioPlayer * theAudio = [[AVAudioPlayer alloc] initWithData:data error:NULL];

// Play the sound file
[theAudio play];

Easy, Peasy.

Blackberry Browser “Secret Sauce”

Blackberry Browser “Secret Sauce”

Anyone who has tried to use BrowserField or RenderingApplication on Blackberry 4.6 and 4.7 has probably run into this: you implement an embedded browser field in your app, and notice that the pages that render in your application look like crap, but when viewed under the regular browser everything looks normal.

What gives?

Well, as it turns out, BrowserField (4.6 and 4.7) and the full blown Browser app use two different rendering engines.

Ugh.

So, what is one to do?  Suffer in silence?  Rage against the night?

Nope.  Do this:

// When setting the properties for your rendering session use this
// undocumented bit of magic

_renderingSession.getRenderingOptions().setProperty(RenderingOptions.CORE_OPTIONS_GUID, 17000, true);

This little undocumented gem now makes your embedded browser field use the same rendering engine as the browser.

If you’re using 5.0, the new BrowserField2 is the way to go.  Different article for a different day.

I’m not sure why it seems like every common thing you want to do on Blackberry has to be a total hassle.

But I’m hoping this little jewel will help the next guy down the road spend a lot less time trolling the wilds of StackOverflow and the Blackberry Forums, and more time finishing their project.