Come and talk to us:
nerdy blackberry talk with beer or lemonade at tuesday 29 this month:
http://www.facebook.com/event.php?eid=123601887675677&ref=mf
Donnerstag, 10. Juni 2010
Freitag, 4. Juni 2010
Uncaught Exceptions and the BlackBerry Whitescreen
Most BlackBerry developer experiences an uncaught excecption at some point.
Very oftens it's a RuntimeException the developer did not expect.
What's the best way to find it?
The default behaviour is to choose "continue" and search for the problem in the code.
This could be done by looking into the EventLog where uncaught exception will be logged with full stack trace (see also
But did you ever scroll through all the options?
There is "attach debugger" which is the easiest way to find the problem when this happens in the simulator.
Simply connect your Eclipse via "Debug As" -> "Remote Java application" to default port 8000. Afterwards(!) click "attach debugger" on the simulator.
Voilà! :)
You will be directly sent to the codeline where the exception occurs with full stack trace available, you can check all the variables. Finding an exception was never easier
Very oftens it's a RuntimeException the developer did not expect.
What's the best way to find it?
The default behaviour is to choose "continue" and search for the problem in the code.
This could be done by looking into the EventLog where uncaught exception will be logged with full stack trace (see also
But did you ever scroll through all the options?
There is "attach debugger" which is the easiest way to find the problem when this happens in the simulator.
Simply connect your Eclipse via "Debug As" -> "Remote Java application" to default port 8000. Afterwards(!) click "attach debugger" on the simulator.
Voilà! :)
You will be directly sent to the codeline where the exception occurs with full stack trace available, you can check all the variables. Finding an exception was never easier
Montag, 17. Mai 2010
BlackBerry Developer Group Berlin founded
We just launched to offical BlackBerry Developer Group for the region of Berlin.
We start with a facebook group but we will expand it:
http://www.facebook.com/pages/Berlin-BlackBerry-Developers/
We are planning regular meetings to talk about BlackBerry development.
Join us now! :)
We start with a facebook group but we will expand it:
http://www.facebook.com/pages/Berlin-BlackBerry-Developers/
We are planning regular meetings to talk about BlackBerry development.
Join us now! :)
Mittwoch, 5. Mai 2010
WES is over. What's left?
No big news.
Some ui polish called 6.0
Some device polish (they made a big deal out of a white Bold).
BESExpress and the mobile voice system where the biggest topics.
From a developer perspective they announced some APIs, no big deals either. The most interesting payment API is still far away.
SuperApp was the big program they try to force developers into. My understanding of the idea is: show us apps that won't be possible with iPhone (always one, deeply integrated with native apps...).
For their development tools they still don't have Windows7 support but keep talking about MacOS. They seem so busy with themselves there seems to be no big plans for real platform changes: hot topics from devcon like shared libraries, unit testing or even language changes aren't there anymore or just too far away to even talk about it.
In addition: With HP announcing the aquisition of Palm just one day after having a keynote presentation with RIM must have been quite embarissing for BlackBerry.
My 5th WES was the most disappointing one. It's kinda scary: I'm flighing home and they did not convince me that Blackberry is the coolest, best device on earth.
Some ui polish called 6.0
Some device polish (they made a big deal out of a white Bold).
BESExpress and the mobile voice system where the biggest topics.
From a developer perspective they announced some APIs, no big deals either. The most interesting payment API is still far away.
SuperApp was the big program they try to force developers into. My understanding of the idea is: show us apps that won't be possible with iPhone (always one, deeply integrated with native apps...).
For their development tools they still don't have Windows7 support but keep talking about MacOS. They seem so busy with themselves there seems to be no big plans for real platform changes: hot topics from devcon like shared libraries, unit testing or even language changes aren't there anymore or just too far away to even talk about it.
In addition: With HP announcing the aquisition of Palm just one day after having a keynote presentation with RIM must have been quite embarissing for BlackBerry.
My 5th WES was the most disappointing one. It's kinda scary: I'm flighing home and they did not convince me that Blackberry is the coolest, best device on earth.
Mittwoch, 28. April 2010
Any WES news? none
Yesterday at teir annual WES conference RIM announced their new Operating System 6.0 which will be soon available (next quarter). For me it looks disappointing. On most screens it was actually hard to tell what was new in there. It's a little nicer but I can't see any major chances by know.
They announced some new devices but also it's nothing new: a Bold and a new Pearl.
RIM is still number one but with so little effort it's hard to tell how long they will stay on top....
They announced some new devices but also it's nothing new: a Bold and a new Pearl.
RIM is still number one but with so little effort it's hard to tell how long they will stay on top....
Freitag, 19. Februar 2010
Print stracktrace to BlackBerry eventlog
The BlackBerry Eventlog (accessable via ALT-LGLG on most devices) is great.
An application can log everything it wants starting from errors up to debug information. And: for uncaught exceptions a full stacktrace is written! Every wanted to use this in your app as well?
It isn't possible to access the stacktrace of an exception. ME does not know "getStackTrace()" there is only "printStackTrace()" which write to console only available for the exception classes. Also ME does not allow to redirect System.err or System.out to get to this information.
The only chance to see the stacktrace of a caught exception is to use printStackTrace() while in attached debugging mode.
But there is a nice trick to print the stacktrace directly to the eventlog: catch Throwable:
try
{
return instance.doAction();
}
catch(Throwable exc)
{
return false;
}
If an exceptions in doAction() occurs (as our best friend NullPointerException) it will be written by the system directly to eventlog. This won't happen if you catch Exception or RuntimeExcepion or more specific one.
An application can log everything it wants starting from errors up to debug information. And: for uncaught exceptions a full stacktrace is written! Every wanted to use this in your app as well?
It isn't possible to access the stacktrace of an exception. ME does not know "getStackTrace()" there is only "printStackTrace()" which write to console only available for the exception classes. Also ME does not allow to redirect System.err or System.out to get to this information.
The only chance to see the stacktrace of a caught exception is to use printStackTrace() while in attached debugging mode.
But there is a nice trick to print the stacktrace directly to the eventlog: catch Throwable:
try
{
return instance.doAction();
}
catch(Throwable exc)
{
return false;
}
If an exceptions in doAction() occurs (as our best friend NullPointerException) it will be written by the system directly to eventlog. This won't happen if you catch Exception or RuntimeExcepion or more specific one.
Freitag, 5. Februar 2010
How to break Mobile Software
In the last days I tested a few apps from colleagues of mine. I found some nice bugs which I often found by doing similar actions, It didn't matter if this was an Android, iPone or Symbian app.
Somem years ago I saw a presentation of James A. Whittaker at a conference in Munich, this guy had so much fun in breaking software. He actually wrote some books about testing:
"How to Break Software" and "Hot to beak Security"
In the last days I had probably the same fun trying to break those mobile apps. Some tipps from the book can be applied also on mobile apps, some other things where different, so maybe it's time for:
"How to break Mobile Software"
Here are some things that worked for me:
(Mis)Use Copy and Paste
Most smartphone supports copy and paste nowadays. And with this nice feature you can start attacking all kinds of ui elements. Assume there is an input field with some limitation, this could be the lenght of characters allowed or characters that are forbidden to type. Try to paste illegal stuff into it. This often works and is a well known test-strategy on desktop applications. It's time for bringing it to mobile phones!
(Mis)use Multitouch
Since iPhone Multitouch is the next big thing for user interaction. But it's even better for an evil tester. Try hitting 2 elements at the same time, whether it 2 listeelements or 2 icons. Most applications are not designed to be protected against this. There is no deselect between the events so the app gets out of sync. Often a thread is started for an action and there is no synchronization that could stop this. Chances are high that you create strange effects on the app. And if the app get's into a strange situation for example overlapping menus: don't stop! This is your chance, now you have good chances to crash it and win by knock out.
(Mis)use Softkeyboard
Since the iPhone started a huge amount of devices came without any keyboard. They have so called soft keyboards that appears where needed on the screen. Try to get the keyboard at a point where it is not needed and use it. Maybe you can confuse the app.
(Mis)use Orientation changes
Accelerometers are more than a nice toy. But writing orientation aware apps isn't easy. Ever saw text falling out of it's boundary dialog? Try to rotate the device in the middle of an action, maybe you have the luck to find such a problem.
Somem years ago I saw a presentation of James A. Whittaker at a conference in Munich, this guy had so much fun in breaking software. He actually wrote some books about testing:
"How to Break Software" and "Hot to beak Security"
In the last days I had probably the same fun trying to break those mobile apps. Some tipps from the book can be applied also on mobile apps, some other things where different, so maybe it's time for:
"How to break Mobile Software"
Here are some things that worked for me:
(Mis)Use Copy and Paste
Most smartphone supports copy and paste nowadays. And with this nice feature you can start attacking all kinds of ui elements. Assume there is an input field with some limitation, this could be the lenght of characters allowed or characters that are forbidden to type. Try to paste illegal stuff into it. This often works and is a well known test-strategy on desktop applications. It's time for bringing it to mobile phones!
(Mis)use Multitouch
Since iPhone Multitouch is the next big thing for user interaction. But it's even better for an evil tester. Try hitting 2 elements at the same time, whether it 2 listeelements or 2 icons. Most applications are not designed to be protected against this. There is no deselect between the events so the app gets out of sync. Often a thread is started for an action and there is no synchronization that could stop this. Chances are high that you create strange effects on the app. And if the app get's into a strange situation for example overlapping menus: don't stop! This is your chance, now you have good chances to crash it and win by knock out.
(Mis)use Softkeyboard
Since the iPhone started a huge amount of devices came without any keyboard. They have so called soft keyboards that appears where needed on the screen. Try to get the keyboard at a point where it is not needed and use it. Maybe you can confuse the app.
(Mis)use Orientation changes
Accelerometers are more than a nice toy. But writing orientation aware apps isn't easy. Ever saw text falling out of it's boundary dialog? Try to rotate the device in the middle of an action, maybe you have the luck to find such a problem.
Abonnieren
Posts (Atom)
Posts
