Tuesday, August 10, 2010

A Tip for Independent Contractors

Whatever your local customs may be, you DO NOT tell a potential employer it is lunch time during an interview. I understand you want to go eat with your buddies and might go hungry for a few hours, but was what you ate worth potentially losing several thousand dollars of income? If so, I'll have some of what you're having.

Sunday, August 08, 2010

Blackberry Development Knowledge Dump

While I'm not the sharpest knife in the drawer, I'm far from the dullest. Recognizing my middle of the road capacity for thought, I'm assuming a portion of Internet readers will experience some of the same frustration with Blackberry development that I have experienced. Most notably, what information is current? So, here's a quick dump of some basic Blackberry nuggets of wisdom.

Should you use Eclipse or the Blackberry Java Development Environment (JDE)?

While some may argue that you shouldn't use either (yes, Blackberry development is possible on NetBeans, IdeaJ, etc.), I think most new projects are being done in Eclipse with the Blackberry JDE plug-in.

What version of the JDE should I use?

Notice how I just said not to use the JDE but then referenced the JDE? Get used to it...Blackberry loves ambiguous crap.

Anyway, it appears as though 4.2.1 is recommended for traditional devices, and 4.7 is recommended for the newer touch-screen devices.

How do I build separate cod files for each target platform?

What? You haven't heard of a cod file? Tough...this is Blackberry development. There will be no hand-holding....nor straightforward and complete documentation.

I'm guessing you ditch Eclipse and the JDE for the command line, but who knows. I don't have that kind of time on my hands. Rumor has it this may be easier in other IDE's, but I'm fairly sure there are some Blackberry Ant tools out there waiting for you.

What is a cod file?

Oh, glad you asked. It's your Blackberry application executable. It's analogous to a zip file with other zip and/or jar files inside it, but platforms work better if they ignore simple, established standards?

What are code signing keys?

They're a security measure implemented by Blackberry so evil developers don't do bad things like get the display width and height. Seriously, I'm sure there's some logical reason. Turning off the backlight 255 seconds at a time would definitely run down a battery. Code signing keys to the rescue.

Also, they're a great way to receive a lot of pointless e-mail and require an Internet connection for you to get your work done.

What are the various device resolutions?

Who really knows for certain? The most common are 320x240, 480x360, and 360x480, but you also have 240x260 and 240x320. Good luck writing a useful interface to support all of those devices.

What is compatibility mode?

It's Blackberry's sad attempt at backward compatibility on their touch-screen devices. Apps built for the traditional 320x240 screen will run inside a blue border with a virtual keyboard. What's really fun is you can get your app stuck in this mode even when you're trying to write a touch screen app. The best way I've found to get out of it is to install a new Simulator. What? You accidentally got into compatibility mode on your development device? Well...good luck with that. I'm sure there's a toggle switch somewhere.

What's all this preprocessor stuff?

It's a C/C++ developer's wet dream of how Java development should be. Don't get me wrong...I like a good precompiler macro just like the next guy, but when you have to comment it out to make it work? No, that's just stupid.

Nevertheless, if you want to support multiple builds from one source tree, you will probably need to use precompiler macros. Every file has to have a //#preprocess directive, and you can then use //#ifdef, etc. Of course, the fun part is that Eclipse doesn't recognize the directives and treats them as warnings and ignores that they exist.

My app was running fine a minute ago and now won't do anything now...what gives?

Blackberry has some arbitrary size limit on cod files. If you hit that limit, it's game over. Do not pass go. Do not receive an error message. Do not receive a warning. Experience silent, pointless failures and go directly to jail.

Of course, I'm sure there are other reasons.

The Blackberry 9000 simulator is giving me access denied 0x00000004 error messages...how do I fix it?

You don't. Get a different simulator. Actually, why don't you figure it out and let me know? Okay, thanks, goodbye now.

I have a short audio file that is not working on the device but works in the Simulator...what's wrong?

Welcome to Blackberry. Work around it.

If I remember some more cherished nuggets of Blackberry wisdom, I'll be sure to update this wonderfully informative article.

Labels:

Adventures in Mobile Development

In my time away from this blog, I became heavily involved in mobile application development. I participated in Apple's SDK BETA program and released my first application shortly after its official launch in June 2008. It's been a bumpy road, and while I'm no fan of Objective-C, I can say that other than a few early bugs, the tools and api tend to work and work well.

Fast forward a couple of years, and I'm now dealing with a Blackberry application. Keep in mind of course that Research in Motion is a much more mature mobile computing platform than iPhone. They've had the chance to make and learn from their mistakes. The crazy thing is...Blackberry application development is a disaster. Don't believe me? Go spend some time on the developer forums and see if you can make heads or tails of it.

If I'm using XCode, I can build my application, run it in the simulator, switch to the device, run, debug...do basically whatever I want without things having to restart or me having to start the application manually. Under Eclipse, I'm constantly restarting the simulator or crossing my fingers and tossing salt over my shoulder hoping on-device debugging actually works, usually after a full system restart.

My favorite feature of the development environment is its stubborn refusal to run an application that crosses some magical size, a rather paltry size by today's standards. And, it does this silently as a gift to all overworked developers in serious need of sleep.

I could go on and on about my frustrations with the bugs, the lack of usable documentation on the website, the constantly shifting functionality in the Eclipse plug-in, but you would just get bored. Suffice it to say, Blackberry can't die fast enough for this developer.

Before I sign off tonight, let me just add that Android should be prepared to take its lumps. It's not as bad as Blackberry, but for a company the likes of Google, I expected more. The development experience doesn't even hold a candle to iPhone.

Labels: , , , ,

Thursday, August 05, 2010

TSA Agent -- A Pedophile's Dream Job?

On a recent trip, I had my first encounter with the infamous body scanning devices making their way into security checkpoints across the United States. As my family approached the machines, I seriously considered asking for the alternative as the whole exercise seemed rather creepy and invasive. Once at the front of the line, though, I noticed that the old metal detectors were roped off meaning a full-body pat-down was the only alternative.

While I stood there holding my 5 year old daughter's hand and watching my wife and 7 year old son load their stuff into the bins, I realized I had only two rather absurd choices. I could let the government take naked pictures of my children, or I could let a strange adult put his/her hands all over them. I opted for the pictures.

For some reason, it never occurred to me how disturbing it would be to see my kids go through the process until we were waiting in line. And, it made me wonder...is this a pedophile's dream job?

My daughter had a blast skipping into the machine and following the agent's instructions, dutifully putting her hands up by her head as instructed. She thought it was fun.

Thankfully, it's "our" government, and I seriously doubt anything inappropriate is going on...

CNET News: Feds Admit Storing Checkpoint Body Scan Images

Labels: ,