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

Reply
Developer
Posts: 304
Registered: ‎04-30-2008
My Device: Not Specified
Accepted Solution

listener/notification behaviour questions

I have a few questions surrounding the behaviour of listeners/notifications that I was hoping someone had the answer to.  The end result is I am trying to configure the system so that the daily prompts I have coded (popup global modal screen) don't pile up if the device has been off or ignored for a series of days.  I would like a single prompt waiting for the user when they get around to looking.

 

I have gone with the model whereby this autostart application is always running (thanks peter_strange, your posts on that subject simplified my life) but just backgrounded instead of closed.  The listener I am interested in is a RealtimeClockListener although I do have a push listener running as well.

 


1. I have seen it somewhere here that some listeners don't require the app to stay running.  Does this mean the system instantiates an object of the registered type?  Does the realtime need the app to remain running? (mine will be so this is more for interest sake)

 

2.  I assume if the listener requires the app to still be running it calls back to the same object that registered it rather than a new instance of the object so it would seem safe to use some sort of instance member to track if I already have a popup pushed.  Is this a correct assumption? 

 

3. I have seen it written somewhere on this forum that when a device has a regular power down (as opposed to a battery pull) it is effectively still on and some processes are still running.  Does anyone know if the realtime listener is still going and the application being notified and responding each minute?


Thank you for any input or corrections.

 

Tim

Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: listener/notification behaviour questions

1.  This is correct  For example email Listeners will run even if the App that added them is not running.  But this does not mean that they don't run without an app, it means that they run in their host app, so for Email listeners, this means in the email processing.  I always think this is a dangerous thing to t do.  Last thing I want my code to do is to take down the email processing.  Users will forgive a bug in my processing but will not forgive my processing stopping them receiving emails.  So I always try to move the processing into my application as soon as I can, using something like a Global Event. 

 

Your clock listener needs an app so in your case, this is a moot point. 

 

2.  All the Listeners I have ever used have done a call back to the Object they were given, not a new instance of it. 

 

I think in your design, you should completely separate the processing of collecting the data to be displayed and the display (popup).

 

As a suggestion your display (popup) design could be based around a class that provides an 'add' function.  The add function adds the notification to the end of the queue.  If the queue was empty, it displays a popup.  The popup clears entries out of the queue and dismisses itself when the queue is empty. 

 

3.  Good question.  I believe that all Application listeners do remain after a soft power off (certainly SystemListener does), but would need to test RealtimeClockListener to be sure for it  Can we ask you to test this and let us know?

Developer
Posts: 304
Registered: ‎04-30-2008
My Device: Not Specified

Re: listener/notification behaviour questions

Thank you for the response Peter.  Informative as usual.

 

Will continue to do testing as I come to the close of writing the app (finally...) but my preliminary very unscientific test suggests that the app does not respond to the realtime listener during a soft power down although I will qualify that to say that it may be the device notification system (or both) that does not accept events instead.  When I powered up there was no prompt, but since the realtime listener triggers the prompt via notification system I don't know if one or both of these is not active while powered down.  After midnight, which I crossed while powered down, the prompt logic says not to activate again until after 11AM so I never did get it which means that it does not queue up the actions either. 

 

Will clarify and post what I find.

 

 

On the topic of backgrounding the app instead of closing it and having an alternate entry point, which you seem to be a proponent of, this really did simplify my life immensely.  My only regret is that I don't think I can keep the app out of the app switcher list this way, although  if you think of the switcher as a system tray rather than an alt-tab between apps then I suppose it makes sense somewhat.

 

T

 

Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: listener/notification behaviour questions

"the app does not respond to the realtime listener during a soft power down"

 

I would not expect the device to run the RealtimeClockListener while the device is powered down.  The issue for me is if it was in place when the device was powered down, would it still be in place when the device is powered up again. 

 

"I don't think I can keep the app out of the app switcher list this way"

 

You can use acceptsForeground() (return false) to remove your app from the App Switcher.

Developer
Posts: 304
Registered: ‎04-30-2008
My Device: Not Specified

Re: listener/notification behaviour questions

I think I understand what you are interested in.  During a soft power down does the app basically hibernate or does my listener actually stop and then treat the power up as a restart and restart the listener at that time.  In the second circumstance it would have an impact I expect on instance variables possibly causing the a second pop-up to appear.

 

 

I have used acceptsForeground() {return false} to prevent a background autostart app from being switched to but I had thought this would prevent this app, which is a UI app that backgrounds, from coming to the foreground as needed from the ribbon icon.  Perhaps it would be possible to put some logic somewhere that the acceptsForeground can use to determine it can open the app from the ribbon.  I assume activate comes after acceptForeground so that is probably not it but just a thought.

 

 

Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: listener/notification behaviour questions

I don't understand what you are saying with respect to the realTimeClockListener interface.

 

However I have tested it myself.  I started an app with an RTC enabled, then pressed the poweroff.  Then on restart, the RTC listener got bumped for the next minute.  So basically it hibernates.  That is a relief, I would have had to recode a number of apps.....

 

You are right, acceptsForeground is called before activate, so if you want a ribbon icon, it is probably best to put up with the fact that it is visible in the background all the time. 

Highlighted
Developer
Posts: 304
Registered: ‎04-30-2008
My Device: Not Specified

Re: listener/notification behaviour questions

Your test covers off what I was trying to explain, I just suffer from an inability to give concise explanations and get to the point.  I am glad to hear that you had that result on your test, it was on the list of test scenarios that I wanted to cover off but with my deadline looming I am getting a lot of midnight oil burned getting to it all. 

 

On the app switcher topic, the more I think about it the less being in the app switcher bothers me.  The project sponsor sees it as higher visibilty for their application so they don't mind either.

 

 

If this forum had a buy-a-beer button as someone once mentioned I would happily give it a couple of clicks for this response as well as the many other patient and informative answers you and a few of the regulars have supplied for other people that I have benefited from.  I think the authors of the 3 BB dev books I just bought for the rest of my team to use as they play catch-up on BB dev ought to buy you more than just a beer though for the reviews.

 

Cheers!

 

Tim