Java Development

[cristisor]

Hi,

I finished my first application using only the BB API and when I exit the application I use System.exit(0) as the last called method. But when I try to delete the application, sometimes, it says that it's still in use and I have to restart the phone. Any ideas why? Thanks.

[mgontar]

BlackBerry Support Community Forums : exited app still reported as 'currently in use'

BlackBerry Support Community Forums : Application never exits.

BlackBerry Support Community Forums : Re: Updating an app using Desktop Manager resets phone

 

What Is - The reason a reset is required when upgrading an application
Article Number: DB-00602
http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800332/800620/What_Is...
How to avoid restarting the simulator to reload an application
http://supportforums.blackberry.com/rim/board/message?board.id=java_dev&message.id=24888

How to avoid BlackBerry's restart tax?
http://supportforums.blackberry.com/rim/board/message?board.id=java_dev&message.id=6808

[cristisor]

Thanks for your answer, now I understand. But one more question, the listeners are removed when using System.exit(0)? I suppose yes, but maybe someone knows for sure.

[simon_hain]

listeners in native apps are not removed when the app exits.
they are weak references, this means that your app does not stay in the memory.

the listeners, are still active. they are running in the context of the native applications (this is proven), but are nonetheless part of your application.

it is getting problematic when you restart your app. in my experience the listeners are called multiple times, that means the remaining listener from the last instance docks with your new instance.

i suggest to use a shutdown method instead of just calling system.exit when employing listeners to native apps (like phonelistener etc).
i use runtimestore to store references to the listeners i register, this way i can't register a listener twice even if the app crashs and is restarted.

[klyubin]

@simon_hain, what do you mean when you say that "[listeners] are weak references"? As far as I know, listeners are implemented via standard (aka hard) Java references. Also, same as any other Java object, the Application instance stays in memory for at least as long as it is reachable via at least one hard reference (e.g., a listener, if the listener transitively references the app instance).

[simon_hain]

if you check listener code in the debugger you see that the listeners are weak references.

[klyubin]

Interesting! If references to listeners are weak rather than hard, how is it guaranteed that listeners aren't discarded by the VM? Or are you saying that references from listeners to Applications are weak references?

[simon_hain]

Listeners are hard referenced by the application they are added to. Figuratively speaking, they become part of the rim application.

If you add a listener to the phone application this listener is executed in the context of the phone app.
You can check this by using Ui.getUiEngine().getActiveScreen() in a listener method. The returned screen is the call screen of the phone application.

I use this to execute commands on phone calls:
- on callInitiated or callConnected i store a reference to the phone screen.
- i call phoneScreen.getMenu(0)

now i want to execute a command:
- i change the locale to "en"
- i iterate through the menu using menu.getSize() and menu.getItem(i)
- i check if menuItem.toString equals my command
- i call menuItem.run()
- and change the locale back (if it was changed)

you can use this to:
mute
unmute
activate speakerphone
view speeddiallist
end the call (only prior to 4.5/4.6, not sure which one)
and many more. just print the available menu items

[simon_hain]

to conclude:

listener:
- has a weak reference to your own app
- is hard referenced by the app it is added to
- is executed in the context of the app it is added to, NOT in the context of your own app!

[klyubin]

I suspect this weak referencing of the Application instance that registered the listener is specific to only certain types of RIM-provided event sources (e.g., some listeners work by posting events into the Application's process behind the scenes, whereas others, as you pointed out, are directly invoked inside some RIM-provided applications/processes). I see no reason why I can't write an event source that doesn't keep track of Application instances that register their listeners.