Java Development

[simon_hain]

i don't know about all listeners, the only ones where i checked it were the phone and folderlistener.

the implementation provides many problems, for example a sleep(x) in the phone listener can crash the phone application.
MSohm is always telling people not to use sleep in the phone listener - but without offering an explanation.

[mgontar]

Hi Simon,

I'm using Bold 9000 simulator

When I use Ui.getUiEngine().getActiveScreen() in UiApplication, it returns the current screen of my own application, even if I go background:

public class UseActiveScr extends UiApplication {
	public UseActiveScr() {
		pushScreen(new MainScreen());
		requestBackground();
		Screen screen = Ui.getUiEngine().getActiveScreen();
		Menu menu = screen.getMenu(0);
		for (int i = 0, cnt = menu.getSize(); i < cnt; i++)
			System.out.println(menu.getItem(i).toString());

	}

	public static void main(String[] args) {
		UseActiveScr app = new UseActiveScr();
		app.enterEventDispatcher();
	}
}

console output:

Starting SOUseActiveScr
Started SOUseActiveScr(163)
Foreground SOUseActiveScr(163)
FocusHistory: Focus lost; App Home Screen; Component net.rim.device.apps.internal.ribbon.launcher.RibbonIconField
Close

  If I use Ui.getUiEngine().getActiveScreen() in Application (background app) it will simply throw null ref exception: 

public class UseActiveScr extends Application {
	public UseActiveScr() {
		Screen screen = Ui.getUiEngine().getActiveScreen();
		Menu menu = screen.getMenu(0);
		for (int i = 0, cnt = menu.getSize(); i < cnt; i++)
			System.out.println(menu.getItem(i).toString());

	}

	public static void main(String[] args) {
		UseActiveScr app = new UseActiveScr();
		app.enterEventDispatcher();
	}
}

 So how should use Ui.getUiEngine().getActiveScreen() to get phone app screen?

[klyubin]

simon_hain meant that, if you call UiApplication.getUiAppication().getActiveScreen INSIDE your PhoneListener, you'll get the Phone application's topmost screen.

[simon_hain]

indeed.

we had this thematic up on our lunch.
if RIM would use a weak reference from the native app to the listener you would not be able to add an anonymous listener.
Phone.addPhoneListener(new PhoneListenerImpl()) would just offer the PhoneListenerImpl to the garbace collector.

If, on the other hand, the listener would have a strong reference to your app AND the native app would have a strong reference to the listener the System.exit of your app would either do nothing or kill the native rim app (i am not sure about this part)

It would make things a lot easier if a listener would de-register itself in case the application exits. This is not the case, you have to de-register all listeners yourself.

[klyubin]

System.exit, on BlackBerry, terminates the process in which it is invoked. If a listener has a hard reference to the Application that was running inside that process, nothing bad happens (the application process still terminates). The listener can always query the Application instance to see whether it's still running (Application.isAlive()). The listener, every time it is invoked, could check whether the Application instance is still running. If not, the listener can deregister itself thus making the Application instance no longer reachable via hard references (becoming a candidate for garbage collection). The catch here is that, until the listener is invoked, the Application instance will remain reachable and won't be garbage-collected (and that instance usually hard-references lots of other stuff).

A slightly improved solution would be for the listener to keep a weak reference to the Application instance. Thus, even without invoking the listener the Application instance could be garbage-collected after the application it represents terminates.

[simon_hain]

this is the current implementation.
native app has a strong reference to the listener (to prevent it being GCed when no reference is stored on the application)
listener has a weak reference to the application

what exactly happens: no clue. but previously registered listeners of terminated application instances are still doing their job when you restart the application. you get all actions executed multiple times. maybe they query the isAlive on a process name?

[klyubin]

I suspect (don't have access to a JDE or a BlackBerry at the moment) the listeners you see (using a Debugger I presume) inside the native applications are wrappers around the actual listeners that are provided by third-party applications. What's puzzling is why would they have a reference to the third-party Applications at all if the listeners' callback code is invoked inside the native application process (e.g., Phone)? May the reference is there for future use...

What I meant with auto-unregistration, is that a listener registered from a third-party app (i.e., our code which we have control over) can keep its own (weak) reference to the Application that registered it and then self-unregister once the application is no longer running or once the weak reference is no longer there.

[simon_hain]

good question.

to switch the context you have to provide your application instance as a reference.
most of the time i just use invokelater on the application object and initialize a new thread if i want to do I/O

[mgontar]

Thanks, now it works great!