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)
Sonntag, 6. Dezember 2009
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?
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:
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:
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 ;-)
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 MyModuleXThis 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 MyModuleXThis 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.
System data:VM:UNDF de.preusslerpark.mytest.MyClass
System data:Symbol 'Vector.get' not found.
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.
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.
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
The content handler may modify the URL, type, action, or arguments before invoking
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:
But this could just be the beginning. We could create a different way of reusage of components and services via CHAPI.
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:
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.
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
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?
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 :-)
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 :-)
Donnerstag, 29. Oktober 2009
Devoted to our tools?
Can we still live without all the development tools? I just saw a developer generating getter methods even if he needed more time customizing them afterwards as without. As I started developing I was glad if had syntax highlighting in the editor. Could we still program that way? Would the code would be so much worse?
And also: sometimes we should remember ourselfs to aks why something happened instead of simply follow the tools. Some weeks ago I changed a method signature (I have to admit without refactoring tool) and did not realize that this methods was overwritten by a subclass. Some days later a tool (UCDetector) detected the leftover method, it seemed to be unused, so I removed it via QuickFix (another tool) .
At the end I found myself with a bug report because of missing functionality.
Now one could demand: I should have used a tool for the refactoring as well!? But then: are we really still need to code at all? (and I know there are people yelling NO right now).
I want to believe: use the tools but use them sagely. I should have asked myself: why is this method not used anymore? What did it do and why not anymore?
And also: sometimes we should remember ourselfs to aks why something happened instead of simply follow the tools. Some weeks ago I changed a method signature (I have to admit without refactoring tool) and did not realize that this methods was overwritten by a subclass. Some days later a tool (UCDetector) detected the leftover method, it seemed to be unused, so I removed it via QuickFix (another tool) .
At the end I found myself with a bug report because of missing functionality.
Now one could demand: I should have used a tool for the refactoring as well!? But then: are we really still need to code at all? (and I know there are people yelling NO right now).
I want to believe: use the tools but use them sagely. I should have asked myself: why is this method not used anymore? What did it do and why not anymore?
Mittwoch, 28. Oktober 2009
busy android bees
I have to admit, I did not take much time yet for looking into the Android SDK and environment. But with every device that reaches the market, with every SDK that gets released, I'm getting more and more curious. It seems Android is here and won't go away. I as many other whas a little disappointed about the Google phone after launch. And even today after looking at 2 HTC devices, the Samsung Galaxy and the T-Mobile Pulse, they all look the same. When I was start looking at the menus they reminded me at Windows Mobile, which isn't a good thing at all ;)
Then non Java SDK where announced, Google announced Chrome OS and new devices where delayed.
But look ahead now: a huge wave of devices is definetely coming. The Moto Droid comes out next week and looks pretty cool.
2.0 is installed and the seems to be worth a major: from bluetooth SDK, Exchange connectivity: the remaining gaps are beeing filled quicklier then we all expected.
There are non-phone devices out there or announced: netbooks, internet-/multimedia tablets, ebook reader: Android definetely came to stay.
Looking forward to start my 1st real look at the community next week at DroidCon here in Berlin.
Then non Java SDK where announced, Google announced Chrome OS and new devices where delayed.
But look ahead now: a huge wave of devices is definetely coming. The Moto Droid comes out next week and looks pretty cool.
2.0 is installed and the seems to be worth a major: from bluetooth SDK, Exchange connectivity: the remaining gaps are beeing filled quicklier then we all expected.
There are non-phone devices out there or announced: netbooks, internet-/multimedia tablets, ebook reader: Android definetely came to stay.
Looking forward to start my 1st real look at the community next week at DroidCon here in Berlin.
Sonntag, 18. Oktober 2009
Want to know more?
This week I tried a new Eclipse plugin to find unused code or code fragments with wrong visiblity (http://www.ucdetector.org/) and my project changed from 90 warnings (mostly deprecations) to 1300! But the problems view only shows me the first 100 of it (mostly the ones I already knew). Although I was used to Eclipse I couldn't find the setting for it, therefore this will be my 1st post here.
The settings is directly within the problems view, watch out for the small triangle on the right side:
and there it is:
And if your compiler stops after 100 warnings have a look here:
The settings is directly within the problems view, watch out for the small triangle on the right side:
and there it is:
And if your compiler stops after 100 warnings have a look here:
http://www.anujgakhar.com/2009/08/26/how-to-get-eclipse-to-show-more-than-100-errorswarnings/
Abonnieren
Posts (Atom)
Posts
