Adobe AIR Development

[shaan_softwaredvlpr]

Hey all , 

Is it possible to open an app at some specific time like alarm?

Thanks

[Innovatology]

No, but I think this is scheduled for BB 10.1 in May.

[shaan_softwaredvlpr]

Thanks.. Do we have any alternative to do so?

[jtegen · Accepted solution]

I dont think that will be in 10.1. It was just in the planning phase a few weeks ago. Best you can do is to send a push message to the app at the time you want it opened. If the time is user specific, then you will have to store that information on your server and run a cron job to send a push message to specific devices at the desired time.

[shaan_softwaredvlpr]

Can we done this by creating ANE using Native SDK ? I read we can export as ANE for using in AIR app , start at some specific time should be possible in native.

[jtegen]

There is not the feature in BB10 to run a cronjob or background job to perform some action (e.g. invocation) at a later time. BB is designing something for later on this year.

[UberschallSamsara]

I'm glad that this is on the roadmap but I'm a bit puzzled why it was not there for launch, given the hyperconnected, hyper-multitasking, "keep moving" sales pitch of BB10.  In the year 2013, having backround services seems like table stakes to me.  Even webOS supported 3rd party services, a *long* time ago.  The 8 active frame limit is also puzzling, considering the pedigree and sales pitch of QNX.  It's not hard to hit that limit and cause some app that you might want to have always open get closed by the OS; without services, the 8 app limit seals the deal on not being able to count on having long running background tasks.  Unless I'm missing something here.

Nearly two years ago, the small but mighty HP Veer was capable of opening 34 apps before it choked.

[jtegen]

The capability is there in the OS, it is a question of how to expose that to developers.  Since it will depend on invocation, invocation had to get in place first.  BB mentioned that under BBOS, there were a lot of apps that forced themselves into the background and made the UX poor because of all the apps that were running that probably did not need to or need to all the time.  BB wanted to get this "right" and not allow the wild west of background apps that sucked the performance and battery out of the device.

So the current "plan" would be to trigger/invocate backbround/headless apps when certain activities occurred.  For example, phone call received, app removed from hoster, etc.  The app(s) would be invoked, they would do their business and then shutdown again.  Some apps would have to be up more often, so there will be certain policies in place for those apps to make certain the device is not being abused.

Nothing is worse then getting a new device and have it snappy when you first get it, to be frustrated 3 months later for it being so slow.

[osus]

I've been using the push solution and works really fine, there is no difference from starting locally with an alarm.

[Innovatology]

---

osus wrote:

I've been using the push solution and works really fine, there is no difference from starting locally with an alarm. 

---

It's a good temporary solution, but ...

• push needs network connectivity
• and thus is bound to use more battery than a simple alarm
• push needs one or more servers
• push will fail if those servers go down
• push uses up the users data plan
• push requires _sys_use_consumer_push permission