Java Development

[jaywhy13]

I've been trying to avoid the IllegalStateExceptions.. as a n00b I've been getting them quite often. I realized trying to do something to a screen the user popped (bad user, bad!) often gives an Illegal State. I tried writing a method to detect if the screen is the top most on the stack so I check that first before doing anything to the screen, so If I do anything in a thread and have to come back later I check if the screen is active first.

public boolean isActive() {
return UiApplication.getUiApplication().getActiveScreen() == this;
}

I realized a few issues/questions with this approach.

• If the user has the menu open.... this code considers the screen to be IN-active, so my code will do nothing while the menu is open
• Would I get an Illegal State if I try to touch the screen below the menu when the user has the menu open? If so, does this mean I'd have to sit and wait until the screen goes active before I run the code after I come back from the thread?
• Would I be better of copying the invokeLater model, queuing up runnables and then running then when the screen is active? As in, implement ScreenUiEngineAttachedListener and then try something like this below...

protected void invokeWhenActive(Runnable r){

 // store the runnable

} 

public void onScreenUiEngineAttached(Screen screen, boolean attached) {

 if(attached){

  // check if we have pending runnables...

 UiApplication.getUiApplication().invokeLater(runnable);

}

}

What best practices can I keep in mind for updating screens? To give a concrete example. Users select a category of points of interests (e.g. police station, hospital) from one screen then I push the result listing screen which starts by displaying a loading animation. Then it updates when I get the info. 

[peter_strange · Accepted solution]

IllegalStateException can actually happen for a variety of reasons.  But that said, I am not aware of any that are a result of a screen not being the active screen.  So I suspect your presumption that this is the cause is not correct, I think there is something else that goes one as well as the screen being popped that is creating your problem.

I generally print out the exception (<exception>.toString()) to find out exactly why I have got it.  As examples of the sort of thing you will find

a) you can get this by setting focus on a field that is not actually on the screen - I think the message will say something about "not parented" or "not on Screen" (note that you can set Focus on a Field for a screen that is NOT on the top of the stack)

b) adding a Field to a Manager when the Field is already added to a Manager, I think the message will say "already parented".

So unless you print out the detail message, you won't be able to resolve your problem. 

With respect to you issue about updating screen, remember that when you are updating a screen, you must have the Event Lock - this is simply a lock that makes sure only one thing is updating the UI at once.  Now all the event handlers (key, menu etc.) run on the Event Thread, which means they all have the lock.  You can take advantage of this too.  You can schedule a Runnable t be run on the Event Thread, when it will have the Event lock.  You do this using this 'incantation':

UiApplication.getUiApplication(),invokeLater(new Runnable() {

public void run() {

// your UI updating code

}

});

So you should use this sort of process when you get the information back that you want.  So push the 'loading screen, start your Download Thread, have the Download Thread use this incantation to pop the loading screen and update the UI. 

Hope this answers the questions:

See more here:

http://supportforums.blackberry.com/t5/Java-Development/What-is-the-Event-Thread/ta-p/446865

http://supportforums.blackberry.com/t5/Java-Development/Blocking-operation-not-permitted-on-event-di...

[jaywhy13]

Lemme just say thanks... it does seem that my initial derivation was wrong. I need to do some more thanks but thanks just the same in the mean time!