DDPB error: Cannot find BarDeploy.jar

Blackberry | Friday January 11 2013 23:24 | Comments (0)

While testing my apps on my Blackberry PlayBook, I sometimes have to sideload them if I am on another computer without the proper SDK tools installed.

For sideloading, I use a tool called DDPB. It connects to your device, lets you select the .BAR file, and basically handles everything for you.

However, after transferring my copy of DDPB over to another machine, I ran into a problem. When I try to connect to my device, it gave an error: Unable to access jarfile C:\Downloads\BarDeploy.jar

As it happens, I had copied it from a 32-bit machine to a 64-bit machine. DDPB is installed in Program Files directory in Windows, but on 64 bit machines, the 32bit program files directory is called Program files (x86) so when I transferred the backup over, it had the old path and could not find the jar file.

Long story short, if you get this error, just recreate your shortcut to DDPB!

Free Blackberry PlayBook for Android developers

Android,Blackberry,Mobile Development | Tuesday February 14 2012 22:21 | Comments (1)

I recently got an email from a tech magazine I’m subscribed too. Usually they have interesting articles, and all the news in the world of Computers and Technology, as would be expected. However, in last weeks magazine, there was an interesting article relating to Blackberry and their flagship tablet, the PlayBook.

With the imminent release (at time of writing) of their OS2.0 software, Blackberry have decided to give away free (yes, FREE) PlayBooks to any developer who submits an app specifically for the tablet before the deadline. Since the new OS contains its own implementation of Android, which allows Android Apps to run pretty much natively, the offer was originally open exclusively to Android developers. However, with a flood of complaints from existing Blackberry devs, and some noise from iOS and WP7 developers, Blackberry decided to open up the offer to any dev, of any platform, who submits an app before the deadline. Originally the deadline was Monday 13th Feb 2011, but since they’ve had an overwhelming response (over 6000 new devs submitting at least 1 app) since last week, they have extended the deadline. Developers have until Wednesday the 15th of Feb to register as a dev, and until March 2nd to submit an app.

Blackberry PlayBook

There is a bit of small print, however. Not every app will be accepted, and qualify for the free PlayBook. The app has to be of sufficient complexity, and be deemed (by a human tester) to be something that people will be interested in. Examples of apps that will be rejected are: Web Browsers, shortcuts, themes/wallpapers and web apps. They’ll also reject apps with a single function like a “Fart Button” or Buzzer app.

Since I stumbled across this offer, I have submitted my Lotto App, which has been accepted. I even got the email asking for my shipping address, and expect the tablet to be shipped any day now, all for the one time fee of ZERO!! 😀

For anyone looking for info, here’s the latest link with info on the deadline extension:

Free PlayBook offer extended

Technical Specs of PlayBook:
1Ghz dual core processor
HTML5 / Flash 10.2
Proper multitasking due to QNX
7 inch screen
Weight: 0.9lb/425g
Width: 7.6/194mm
Height: 5.1/130mm
Thickness: 0.4/10mm

1080p Playback
3MP front camera
5MP back camera

Blackberry CRC32 issues

Blackberry | Sunday July 3 2011 13:56 | Comments (0)

I’m currently a few weeks into my internship where I’m developing a new blackberry app for a small start-up company. One of the core features of this app is that it can communicate with a remote server. Anyone that knows anything about security will tell you that you simply cannot send these communications in plain text.

So, this week I’ve been working with encrypting strings and sending them to our server. The way we’re handling the encryption/decryption is by using a common method on both client and server side so that messages can be easily decrypted. Pretty common enough. But, in order for the client and server to tell if messages have been tampered with before the arrive at their destination, we also send a CRC of the string that we have encrypted. Once decrypted, we call the CRC method again and can tell if the data is as it should be.

Here’s where the problem arises.

Since the app is cross platform, we have to ensure that the CRC value gotten on a blackberry device matches that gotten on an Android device, not to mention the server will need to be working off the same algorithms. Initially you might think thats no problem because CRCs are universal. Incorrect. It took me a few days but I have realised that the Blackberry implementation of CRC32 is different to the Android and the Apache/PHP implementation. It was frustrating having the Android sending and receiving messages with ease, when my blackberry app was getting errors.

The Solution
Like all good programmers will tell you, there’s no point reinventing the wheel. It felt to me like that was going to be my only solution if I was to ever get this to work, but after spending way too long on this small piece of code, I decided to do what I should’ve done a long time ago….and that is to Google java.util.zip.CRC32 source (and java.util.zip.checksum) and copy and paste the source into a new .java file in my project! Basically the blackberry CRC32 code seems “broken” so why invent the wheel when I can just use the same “working” code that the others use!!!

After I did this, the code worked straight away. I didnt even have to rewrite the code too much because they all have pretty similar methods! Plus, my code is a little bit more “cross-platform” now for when we package all the common stuff into a JAR later.

Getting to grips with Blackberry

Blackberry | Monday June 20 2011 20:20 | Comments (0)

I mentioned previously that I’ve taken on an intern position with a company specialising in making child safety/security apps, and I’ve been given the role of developing the Blackberry version of the app. Well, after being in the job a few weeks now, theres some thing I’ve noticed.

The JRE version used to make Blackberry apps is JRE 1.3, which basically means no ArrayLists, no generics (the pointy braces , eg ArrayList) and no StringBuilder. The absence of StringBuilder isnt that big a deal since you can still use StringBuffer. There’s also no template classes, but I think thats more of a Java thing. Coming from a C++ background, I like to have Template classes instead of overloading where possible, but I suppose thats more of a preference, and not really a limitation.

I’ve also noticed that the simulators (not emulators ;)) for blackberry can be very slow and memory intensive. Much like that Android emulators, they take forever to load up, but unlike that Android emulators, you can’t skip the boot animation to slightly speed things up. My laptop has 1GB of RAM, but I’ve ordered another 1GB off eBay so hopefully that speeds things up a bit. From what I’m told, RAM is more important than CPU speed here.

Also, there are 2 IDEs that are commonly used for Blackberry. There’s the Eclipse plugin, and then there’s RIMs own Blackberry JDE, built in Java. Both work fine but the one thing its missing is the ability to filter the console. In Android, you can filter by a tag or app name. In blackberry there is no such option, so your console outputs get lost in a sea of scrolling lines! The best workaround I’ve found is to get a plugin for eclipse, called grep console that highlights lines in a specificed colour based on text matching. So if you output to the console something like: MyApp::Error with database then the plugin can match MyApp:: and highlight it red, or whatever colour you choose.

Anyway, that’s just my initial observations and a newbie to the Blackberry world. Will keep updating here as I find out more.