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 ;-)

Montag, 23. November 2009

Weak RuntimeStore?

The BlackBerry RuntimeStore is a great mechanism to support Interprocess Communication: You can store any Object and retrieve it from a different process, even a different application.
It is normally used for communication between a listener (i.e. PushListener) and a running application. But it also could be used for implementing system wide Singletons.

But using the RuntimeStore can be dangerous because it is a typical cause for memory leaks.
Let's assume an application put's in a reference to an object. The application exists (normally or abnormal) without removing that object. The Garbage Collector can not decide if that instance can be deleted. It remains in the RuntimeStore till it will be removed or the device reboots and so will every instance that is referenced from that object which can be a lot of "garbage".

Quite unknown is the BlackBerry (actually it's part of JME) implementation of WeakReferences. If the only remaining references to an objects are WeakReferences, the object will be removed by the garbage collector.

A colleague of mine had the idea to combine this with the RuntimeStore and according to a guy from RIM I asked at DevCon this should work:

Put it a WeakReference instead of a normal object to the store and if you application exists without removing the instance it should be garbage collected.

I did not try this myself but it should be worth a try.

Donnerstag, 19. November 2009

Closures Attack!

When everyone least expect it anymore closures came back again. They will make it into Java7 after they where declines after years of discussion!
The strange thing: it's non of the 3 discussed versions: CICE and BGGA or FCM (see http://www.jroller.com/scolebourne/entry/java_7_comparing_closure_proposals for an overview about the original language discussion).
Out came a "lite" version that will now make it into Java. You can see the proposal here: http://www.javac.info/closures-v06a.html
Java7 will therefore (and for some more smaller language changes) still take a while but I think that Closures is a good news. Although none of us mobile developers will see Java7 language features for some years I still see myself as a Java developer and therefore I like to see Java evolving.

Montag, 16. November 2009

CHAPI as BlackBerry Intents

At developer day of BlackBerry developer conference we had a disussion about supporting something like Android intents on BlackBerry. Cassidy Gentle from RIMs java team compared it to CHAPI and if yout think about it, it's definetely comparable:

An intent has an action and a URL, which is exactly the same as CHAPI has.
My 1st idea was that CHAPI does not support the returning of values as Intents do. But actually it does, as the finish method describes:

The content handler may modify the URL, type, action, or arguments before invoking finish. If the method Invocation.getResponseRequired returns true, then the modified values MUST be returned to the invoking application.

So all we have to do is collect and document CHAPI handlers implemented by 3rd party vendors and describe them as OpenIntents do for intent receiver on android.

There is already a lot of things you can do with CHAPI:
  • view and edit office files via Docs2Go with URL to file and ACTION_OPEN
  • open AppWorld with ID “net.rim.bb.appworld.Content” and ACTION_OPEN
  • print any file with Cortado free printing solution via URL to fiile and ACTION_PRINT
  • and much more
But this could just be the beginning. We could create a different way of reusage of components and services via CHAPI.

Mittwoch, 11. November 2009

BlackBerry Developer Conference Days 2+3

3 conference days lay behind. Some interesting session, some disappointing ones.
Best news seems to be that RIM understood that all the new 5.0 APIs won't help most of the projects out there. We develop for 4.6, 4.5 even 4.2
So it was good to hear about ideas of libraries and kb articles for older devices.
What else?
The unit testing session about RIMUnit was disappointing. They seems to have good ideas but currently it seemed they wasted a lot of time building something that is out there in varouis flavors: a simulator based unit-testing framework with a lot of manual work.

Looking forward for the roundtables tomorrow.

Montag, 9. November 2009

BlackBerry Developer Conference Day 1

A long day is going to an end. This morning we had a much too long keynote but with some news: RIM announced a lot of new APIs and tools.
On API-side: an Advertisement API and In-App-Payment API. On the toolside: a new version of the Eclipse plugin and finally a GUI builder. Sadly it seems that the GUI builder still is very far away and was more like an alpha-version. As always it's the small things that makes us developers happy: hot swapping of code in the simulator. Although after some talks to RIM employees it seems, this is still quite limited but a good way. I'm desperatly waiting for the day where I can change my code and updating the simulator without having time for another coffee before seeing the results. The 2nd: you can now also develop completely on MacOS, which seems to be a great hit in the community.
5.0 was still the major topic, so there was a lot of talks about BlackBerry Widgets today (although it seems people are already waiting much more for webkit). The new network API looks very good, I hoped that would be available earlier.
Also Cortado started a competition about the best idea of bringing printing to BlackBerry apps using CHAPI: www.cortado.com/win
Looking forward for day 2

Montag, 2. November 2009

MIDP3.0

MIDP 3.0 is still a draft an in discussion.... still...

If you start looking at it, as a BlackBerry developer it's sounds disappointing. We know about libraries and auto-run applications, that's our daily work. But I think having this standardized is always a good news.

But there is more: Sun just published a new article about a Midp 3.0 feature: inter process communication
http://java.sun.com/developer/technicalArticles/javame/midp3_enhance/
You can use Connector.open to another midlet and you can wait for incoming events as a listener.

But another time:
as a BlackBerry developer there is nothing new. We have a lot of possiblities for IPC: the RuntimeStore , global messages (I have to admit I heard about them just weeks ago, never used it).
But even without RIM APIs there is JSR 211: CHAPI (see the blog entry yesterday, seems this is the CHAPI month ;)).
Do we really need MIDP 3.0 IPC and events?
I can send custom data to another app via CHAPI. This could be based on custom mimetypes or directly via using the handler ID.

For me: another time I do not see the any need for MIDP 3.0
RIM probably will introduce MIDP 3.0 at some point. A good thing or a waste of development time?

Sonntag, 1. November 2009

CHAPI pitfalls, part I

Some week ago I went mad implementing a CHAPI based solution.
CHAPI is the Content Handling API (JSR 211), a very powerful API for interprocess communication. It allows communication between Midlets and native apps. It allows the use but also offering of services on a mobile device.
Altough CHAPI is a quite easy API, the devil lies in the details. I spent the same time searching for problems then implementing it.
One problem is: The RIM samples for CHAPI are very simple: CHAPI caller and content handler are in the same class and are equal to the application instance itself.
But when starting to build more complex solutions, you will suddenly run into strange problems.

My first tipp: enable "device security" in the simulator!
For testing CHAPI use the device security option in the simulator. With this the device is much more strict in checking security issues: the application must be signed for using protected APIs as on the real device, firewall prompts are appearing and so on.
When using CHAPI there are checks for given classnames that does not occur in normal simulator but would appear on the real device.
The error will be an exception with "Classname does not exist in the current application package". Switch on device security for seeing it as early as possible.
The cause is documented in a KB article:
http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800332/800429/Support_-_Classname_does_not_exist_in_the_current_application_package.html?nodeid=1518602&vernum=0

When calling Registry.getRegistry() you have to give in the classname (incl. package) of the current application. This sounds simple but is easily breaks if you have for example a library with the code that is used from different applications. Example: a menu item and a CDLC application that resists in different COD files.
Therefore the 2nd tipp: you should use:
Application.getApplication().getClass().getName()
instead of hard coded application names.


more in the next part :-)