The RIM press release says it all … that developers will be able to repackage and resign existing Android apps to run on PlayBook.
Yeah … That’s what the developer community needs … more undocumented RIM SDKs to add to the existing, poorly documented and cumbersome family of RIM development SDKs!
The cost of writing mobile apps for RIM devices is already about (I estimate) 30% higher than any other device just due to the challenges of dealing with the RIM SDKs and hardware.
Is adding another build step really going to help?
I am excited to see new innovation come out of Research in Motion with the announcement of their tablet. And, I hope it works well.
What I can’t help wonder about though is the quality of the underlying development tools that will be shipped with that product. Is it JDK 6.0? One might assume, but we’ll see when it comes out. But that’s neither here nor there. What’s important is this:
Overall quality of a mobile device is defined as much by the software development toolkit as the device itself.
And that, my friends, is what I’m looking out for.
A healthy, super usable, software development toolkit means you’re going to get healthy, super usable software for the phone/tablet/device/whatever…
On Blackberry devices, the jury is still out. What is clear however, is that many IDEs have long set the standards for mobile development: great toolchains like those for iPhone, cutting edge Android development tools, great IDEs like Netbeans, and even not-so-great IDEs like Eclipse. Even Windows Mobile development tools have a history be being stable and working well. Will RIM finally step up to the plate?
I may have been the first to blog that the lack of an easy to use, stable development and debugging platform, threatens RIM’s domination in the market as much as anything.
The use of HttpConnection.setRequestMethod(“PUT”) is not officially supported on the RIM platform, but I’m finding it is working, much to my surprise.
So, the question remains:
What’s the dangers and caveats of using HttpConnection.setRequestMethod(“PUT”)
I’ve submitted a query to RIM technical support. We’ll see what they say.
You have multiple versions of JDEs installed. You need to sign applciations from all of them. What the tech docs don’t make clear is this:
When you register your developer keys, the version of SigningTool (SignatureTool.jar) that is used is the latest version.
This means that…
You can’t just copy your key files to the bin directory of the other JDE installations. You have to copy the key files and the SignatureTool.jar file to the other directories.
So, to sign from all versions of JDE, copy the following files to all the bin directories of the JDE . This is usually the directory C:\Program Files\Research in Motion\Blackberry JDE x.x.x\bin :
It’s great to know that the signature tool program in the file SignatureTool.jar works across all versions of the JDE. Here’s the response from RIM tech support guy, James, that explains this:
Thank you for contacting BlackBerry Application Development Support.
In response to your most recent email regarding signing your application within multiple versions of the JDE, I would be happy to assist you with this issue.
Your situation is very common as many developers use multiple versions of the JDE to develop their applications, and would also like to sign their applications throughout the JDEs. The signature keys are always registered to the most recently installed version of the JDE, and are only registered to the single version. Similarly, you are only able to register the keys once for security and privacy concerns. However, I will provide you with a simple workaround that will allow you to sign your COD files in multiple versions of JDE.
If you could please navigate to your \bin folder of the version of the JDE that you can sign in (default: C:\Program Files\Research In Motion\BlackBerry JDE 4.5\bin) and COPY the following four (4) files:
If you could than navigate to the \bin folder of the version of the JDE that you wish to have signing in, but currently do not, and PASTE the files there (default: C:\Program Files\Research In Motion\BlackBerry JDE 4.2\bin), you should be able to copy your signing privileges over. This process can be carried out for multiple versions of the JDE, as well as the Eclipse eJDE plug-in.
I hope that this workaround was successful in allowing you to sign through each of your JDEs. If you have any additional questions or related issues, I would be happy to address them. Good luck in your future BlackBerry application development and have a great day Richard!
Added new web page for the Blackberry Java Development Environment (JDE). More ….
Starting out on the path of J2ME development can be hard. You have to get a computer, get a phone, install software from at least two different companies, and then hope that you get all the information in one spot. On top of that there’s the J2ME tutorials/training, reference information from the phone manufacturer, etc … much of which you have to search for on the massive websites of large mysterious companies.
The end result can be a feeling of mental retardation. Or, worse. A conviction that there’s some conspiracy determined to keep the “average citizen” from breaking into J2ME development seriously.
This new page is for you, wayward J2ME traveller…
Added new page to cover Blackberry phones. more …
Added tip to change the Blackberry JDE signtool password on your PC. more …