Java Development

[chaimkut]

Hi

I don't fully understand the idea of the net.rim.device.api.notification.Consequence interface. If you perform a NotificationsManager.registerSource then the device will create an entry for the application in the list of configurable applications for each Profile. Let's say then a person performs a NotificationsManager.registerConsequence using a Class implementing the Consequence interface. When an event is triggered by NotificationsManager.triggerImmediateEvent,  the system then calls the startNotification method in the class implementing the Consequence interface. Inside the startNotification method we can then programmatically cause the LED to blink, phone to vibrate, etc.

But isn't this confusing for the user? The user has just configured their settings for the application in the Profiles configurations (i.e. blink twice, vibrate once, etc.) and now the application simply chooses to do whatever it likes in its startNotification method. Am I understanding this correctly? Thanks.

[simon_hain]

you can play a tune, start the buzzer or control the LED regardless of the profile settings anyhow.
i am not sure though how the consequence interface is interacting with profiles though, maybe somebody von RIM can shed some light.

[RexDoug]

You trigger the BB Profile (as set by the user) when you call NotificationsManager.triggerImmediateEvent()

[chaimkut]

Many people ask whether the current Profile can be detected (which of course it can't be directly). Couldn't this be a means of doing just that? You create a configuration Object for each profile (Consequence.newConfiguration passes a Profile bit corresponding to Loud, Quiet, etc.). Then whenever you want to know the current Profile, you perform a NotificationsManager.triggerImmediateEvent() (and an immediate NotificationsManager.cancelImmediateEvent() so it doesn't affect the user) which will cause a configuration Object corresponding to the phone's current Profile to be passed to Consequence.startNotification. You will then know what the current Profile is based on the configuration Object. Does this sound like a reasonable (if not tricky) solution?

[chaimkut]

As a follow up to this question, I can confirm that this in fact works as a solution to the issue of detecting the phone's current Profile. The only 'messy' part as hinted to earlier is the fact that registering an application as a Source automatically places the application in the list of Profile-configurable applications. If under Profile 'Loud' the user silences Notifications from your application and nevertheless you still make noise, then it'll probably be confusing for the user. But this is an inherent problem with the implementation of Consequence and not an issue with this particular Solution.

[chaimkut]

A further follow up to my prior comment -- I erred when stating that the application is forced to be listed in the Profile-configurable list of applications (due to the need for calling NotificationsManager.registerSource). In fact, performing a NotificationsManager.hideSource prevents the Application from being listed inside the Profile configuration screen. It seems that the API's intention is that regular, immediate Notifications should be registered and thereby allowing the user to configure those Notification settings. Separately, an application which wants to control its own Notifications and doesn't want to allow the user to adjust such settings, should implement the Consequence interface and additionally perform a NotificationsManager.hideSource . It seems that the API was NOT intended for a Consequence implementor to also be configurable in the Profiles settings screen (since in the end the Consequence implementor would perform its own Notification actions aside from the user's settings which is not desirable).

[GautamBisht]

Hi chaimkut,

I used the NotificationsManager.hideSource() Api but it doesn't work. I am working on BB os 5.0.

Is there a other way to remove the app entry from the Profile-configurable list of applications?

Regards,

Gautam