Donnerstag, 4. Februar 2010

BlackBerry JVM errors

More as a reminder for myself than a normal blog:

http://www.blackberry.com/developers/javaknowledge/general/kpa0307163334.shtml

good to know:
When you have one of those JVM whitescreen you can still use javaloader.
I could capture a screenshot and grab the eventlog.

Dienstag, 2. Februar 2010

Oracle and Microedition?

Just watched Oracles webcast about the upcoming Java strategy after acquisition of Sun:
http://oracle.com.edgesuite.net/ivt/4000/8104/9236/12630/lobby_external_flash_clean_480x360/default.htm
Best news for Java mobile developers: the plan is to merge ME and SE!
Best news of the day for me. 2 years ago at RIMs annual developer conference the head of Java development for BlackBerry said in a session this would never happen for their platform, so we'll see. Now there is a big player involved as well ;-)

It will obviously take a while but Google showed how to build a modern platform with Android based on Java SE. It will be interesting to see what will happen next.
Interesting: JavaFX and Netbeans are both part of the mobile strategy. It will be a thrilling year for mobile java world.


Here's the ME slide:

(c) Oracle 2010

Dienstag, 19. Januar 2010

Getting redirected

I just ran into a problem with HTTP redirects.

As a BlackBerry developer I don't have to deal with those 30X responses as long as the BIS or BES is doing the HttpConnection. Those services follow every redirect automatically and the clientside call to HttpConnection.getResponseCode() will get only return the final result. The application will not know, that it was redirected at all.
Actually I saw a lot of implementations (example Symbian) where this is simple handled by HTTP API itself. On ME devices some implementations also do this.

But when you start with SSL Connections (https) this will fall back on you. Same for APN based connections where no proxy is inbetween.

But my code was prepared and checked for:
HttpConnection.HTTP_MOVED_PERM
and
HttpConnection.HTTP_MOVED_TEMP
which I knew for a long time where the redirect values (as integers these are 301 and 302).

But yesterday this code broke! Why? Because I got a different result: 307!
After some google I found out that the specification of HTTP 1.1 changed the default value for moved temporarily. They now called it "redirect temporarily" with the new value 307. The old moved 302 is not simply called "found".

But as always I just should have looked into the JavaDoc more closely, its already there:
HttpConnection.HTTP_TEMP_REDIRECT

So alway check for both: HTTP_MOVED_TEMP and HTTP_TEMP_REDIRECT!

see also http://developers.sun.com/mobility/reference/techart/design_guidelines/http_redirection.html

Dienstag, 5. Januar 2010

Google utilities

A happy new year!

it doesn't always has to be Apache/Jacarta libraries when you need some utilities.
Check out what google has to offer:
http://code.google.com/p/guava-libraries/
It's Apache licenced too and contains Googles new Collection Library 1.0

It's for Java5 only, therefore currently only mobile developers for Android can benefit of it

Sonntag, 6. Dezember 2009

Hard reset your BlackBerry

Ever find yourself in the position where you want to hard reset your Blackberry without pulling out the battery? There are some apps in AppWorld that can do exactly this. Every wondered how they do this? There is no API for it.

I just found a great post in the BlackBerry Support forums which explains how to do the magic:
The only situation where the BlackBerry wants to restart is after installation/deinstallation of running modules. And that's exaclty the solution: just do it. :-)

(from http://supportforums.blackberry.com/t5/Java-Development/How-can-I-programmatically-reset-a-blackberry/td-p/116854)

1. Create a stub app who's main function simply creates the app instance and calls enterEventDispatcher on it. Include the stub cod as a resource in your app and remove the .cod extension.

2. Load the stub module into a byte array. The byte array can be obtained by calling getResourceAsStream with the cod file as your resource and then reading the bytes.

3. Create a new module with createNewModule( int, byte[], int ).

4. Call CodeModuleManager.saveNewModule( int, boolean ) where the int argument is the handle obtained from createNewModule and the boolean is true for forceOverwrite.

5. Obtain the application descriptors for your new module by calling CodeModuleManager.getApplicationDescriptors( int ). There should only be 1 descriptor in the resulting ApplicationDescriptor array at index 0.

6. Call ApplicationManager.getApplicationManager().runApplication( descriptor, false ), where descriptor is the application descriptor obtained in 5 and false means do not grab foreground. This will launch the module you just loaded.

7. Call CodeModuleManager.deleteModuleEx( int, boolean ) where the int is your module handle and the boolean is set to true for force delete even if the application is running. This is the real trick to this, because if you delete an application while it is running, a restart will be required.

8. Call CodeModuleManager.promptForResetIfRequired()

9. Presto

Donnerstag, 3. Dezember 2009

Midlet Installation Problems

Do you know the depressing moments when your JME application doesn't start? Or can not be installed although everything was fine on simulator or even on the different device?

The system is normally not much help at all so you spent hours guessing and trying: software development at it's worst.

Often it's simple a system check of properties in some of the files (often much too strict if you ask me). This could be a version number that contains a wrong formated build-number (Midlets need major.minor.build instead of major.minor.build.revision) or signature hashes written by your build tools into the manifest file.

Next time when you don't have a clue this document could help as a checklist (thanks to my colleague Yousuf who found this document):
Why Doesn't My MIDlet Run?

Donnerstag, 26. November 2009

Praise the EventLog

I am developing BlackBerry applications with pure Eclipse without RIM's eJDE. I hope at some point in the future the plugin will be better but currently I can use libraries and unit testing much better without.
But this also can get you into lot of troubles: when building against a normal JRE it can happen that methods will be used that are not available on the device. This is because the rapc compiler does not check jar-files as strictly as source files. There is the preverification process for jar files. I can detect illegal classes but if a normal class uses methods of a system class let's say from i.e. java.lang.String which are not available in ME (a good example ist "split") this will not cause any errors. And this could cause you a lot of headaches.

So today I found myself in a situation where my application did not start on the BlackBerry simulator. It was an auto start library but it looked as it was never started.

1st look is normally into the eventlog!
(tip: simulator a connected USB cable via the simulator app menu and download it directly with javaloader, much better for reading and searching).

It shows me multiple entries of:
app:System data:Linker error: 'VerifyError' for MyModuleX
This normally can be translated as: you are using something which is not allowed!
I can also see the complete loading procedure of my module if I look more closer and so I found the detail I wanted to know:
System data:VM:LINK MyModuleX
System data:VM:UNDF de.preusslerpark.mytest.MyClass
System data:Symbol 'Vector.get' not found.
This tells me exactly what I want to know: the class MyClass uses Vector.get which in unknown in CLDC environments (UNDeFined). It wasn't even my code (and the developer was not in the office today). But I found the source and replaced the call with elementAt. Next tip: search for every occurence of this call (great that "open call hierarchy" works on every method call and not only method declararions). Normally there are more then one and you don't want to find yourself in the same position once more after building multiple libraries, your app and the simulator boot process.

Sometimes I did not see the exact class where the problem layed and in very few cases it did not tell me at all which method was used.

But look into the eventlog and look closely, most of the time you will find the problems there!

And maybe someday someone should write a better preverify.exe ;-)