千丝海阁

今天无意中发现一个关于BB UI设计的tips，拿来分享一下。
《User Interface Coding Tips 》
– Scott Wahl, Manager, Software Documentation, RIM

Three Tips for Managing Screens

1. Pop screens off the UI stack when the user finishes interacting with them to avoid memory problems as the display stack grows.

2. Never pop the same screen more than once. Excess popping can lead to problems with the keyboard and thumb wheel.

3. Avoid using more than a few modal screens at one time because each screen uses a thread.

Handling Threads

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:

1. Acquire and hold the event lock
2. 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 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 ensure 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:

1. invokeAndWait(Runnable runnable)
Immediately calls run() on the event dispatch thread. The call blocks until the run() method is completed

2. invokeLater(Runnable runnable)
Calls run() on the event dispatch thread after all pending events are processed.

3. invokeLater(Runnable runnable, long time, Boolean repeat)
Calls run() 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, Runnable is added to the event queue every time milliseconds.

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(), ensure 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 user closes an application (for example, by selecting the Close menu option), most applications should shut down using System.exit() before returning the user to the Home screen. This conserves space on the handheld.

---