07-09-2010 10:56 AM
Thanks for consideration my issue.
right now, when my application starts, some time it will throw Application(162) is not response,
processing is terminated...
I have google some great idea. basically,
it is caused by invokelater or invokeandwait
what I am doing right now is once my application starts, it will invoke some http connection to request some data from server, and refresh screen to show data.
building httpconnection have to be implmented by background, and refreshing screen from a background thread have to getEventLock or invokelater or invokeandwait....
is there any best way to avoid this? or if I can check queue, and then I drop some event queue.?
any advise would be great appreciated.
07-09-2010 12:01 PM
I will expect the next artical which is talking about
In the next article, we will extend this code to be able to handle:
a) Status updates from the Background Thread
b) "Time to go" indication
c) Being cancelled by the BlackBerry smartphone user
since lots of customer does not like to use please wait, they like to see some real changing on screen.
07-09-2010 12:14 PM
07-09-2010 01:11 PM
do you have any idea about the con/pro for the following three method:
Application.invokeLater, Application.invokeAndWait, synchronized(Application.getAppEventLock())
by the way, I know you know a lot about device connection.
How many httpconnection can be built simultaneously from device level and application level?
07-09-2010 01:43 PM
Here is the KB article that discusses connection limits:
Regarding your other question, here are my thoughts, but remember I don't work for RIM, I've never looked at this code seriously so the following is just my educated guess and my preferences.
invokelater should be used in preference to the others, so use this wherever you can. However it does put an entry on the Event Queue, so should not be used when you are going to be doing small updates frequently in a short period of time, as this could flood the Event Queue. If you are going to do lots and lots of small updates, include some way of 'pacing' these requests so that you do not flood the Event Queue. The other issue with this is that you have no idea when the update will actually be applied to the Ui. So for example, if you do an invokelater on a popup screen, then, in your invoking Thread, do an Alert to buzz the user, the Alert might happen before the popup screen is actually displayed. So put the Alert in the code that is invoked later.
If you are doing loads of frequent and very small updates, then I would consider the Event Lock, because I understand that its overhead is less than invokeA...... But do not use it where you are going to be holding the lock for a long period of time. Also I think you can get yourself into deadlock troubles doing this frequently in your application, if you are doing other synchronized updates, so use this approach cautiously. Also, as I understand it to, this will not necessarily wait for other things in the Event Queue to be processed, so Fields might not get updated in the right order. Say you updated the same Field with an invokelater and the immediately updated it using the Event Lock, I think there is no guarantee that your invokelater update will have happened before your Event Lock update.
invokeAndWait should only be used where you really need the Ui interaction to be over before you continue.
Hope this helps.