Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Manage UI interactions

by Retired ‎05-12-2010 12:53 PM - edited ‎09-16-2010 03:41 PM (8,387 Views)

Summary

 

This article applies to the following:

 

  • BlackBerry smartphones based on Java technology

Description

 

Managing Screens


When managing your application screens on the user interface (UI) stack, do not mismatch the pushScreen() and popScreen(). When the BlackBerry smartphone user finishes interacting with the screens, pop screens off the UI stack; otherwise, the display stack continues to grow until the BlackBerry smartphone runs out of memory. You should not use more than a few modal screens at one time, because each screen uses a thread, and you should pop the screen only once.

 

Handling Threads


When you try to update the UI of your application from a background thread, you may encounter the following exception:

 

java.lang.illegalStateException: UI engine access without holding the event lock

 

An application can access the UI either on the event thread or with the event lock held. Only one thread at a time (usually the event-dispatching thread) can gain access to an interface component. There are two ways for background threads to access the UI from outside the main event-handling or UI drawing code:

 

  • acquire and hold the event lock
  • use invokeLater() or invokeAndWait() to run on the event dispatch thread

Holding the Event Lock


The event dispatcher sets a lock on the event thread while it processes a message. Background threads (non-event dispatch threads) can access the UI by acquiring this lock for a short time, without interfering with processing by the event dispatcher. A worker thread can call Application.getEventLock() to retrieve the event lock and then synchronize this object to allow serialized access to the UI. You should only hold this lock for short periods of time because the event dispatcher is paused. An application should never call notify() or wait() on this object.

 

For example, in a timer task, you could write code in the following method:

 

 

class MyTimerTask extends TimerTask {
public void run() {
synchronized(Application.getEventLock()) {
_label.setText("new text " + System.currentTimeMillis());
}
}
}

 

In most cases, this is the most efficient way to access the UI.

 

Running on the Event Dispatch Thread


In some cases, holding the event lock is not appropriate, particularly if the application has its own locking operations to manage. In this case, you must create a class that implements the Runnable interface. You can then invoke its run() method on the event dispatch thread using one of these three methods:

 

  • Use invokeAndWait(Runnable runnable) to have run() called on the event dispatch thread immediately; the call blocks until the run() method is completed

  • Use the invokeLater(Runnable runnable) to have run() called on the event dispatch thread after all pending events are processed

  • Use invokeLater(Runnable runnable, long time, Boolean repeat) to have run() called on the event dispatch thread after a specified amount of time, where time specifies the number of milliseconds to wait before adding Runnable to the event queue; if repeat is true, the Runnable is added to the event queue every milliseconds.  For more information, see Update a screen on the Main Event Thread .

 

Using activate()


The system calls the activate() method when it brings an application to the foreground. For most applications, you should not override activate(). Perform any initialization, including any required pushScreen() calls in the application's constructor. If you must override activate(), verify that you call super.activate() from within the overridden method; otherwise, your application does not repaint correctly.

Because activate() can be called multiple times for the same application, it is not appropriate to perform a one-time initialization with this method. For example, you should not perform actions, such as call pushScreen() from within activate(), unless you verify that you have done so already.

 

Exiting Applications


When the BlackBerry smartphone user closes an application (for example, by selecting the Close menu option), most applications should shut down using System.exit() before returning the BlackBerry smartphone user to the BlackBerry smartphone Home screen. This conserves space on the BlackBerry smartphone.

Contributors
Users Online
Currently online: 22 members 729 guests
Please welcome our newest community members: