Adobe AIR Development

[jtegen]

BB is looking into providing "headless" apps in the future (apps without a GUI).  Consider them background apps, but BB does not want these apps to run all the time if they do not need to (wasting resources and providing the user with a less of a positive experience).  The idea is to have these headless apps be triggered by invocation, do their task and then exit when done.  BB is looking for a list of use cases and trigger events that anyone can think of would occur for current or planned apps.  Triggers like:

• change in WiFi state
• phone call received
• email received (or sent)
• contact added (modified or deleted)
• BBM status change

Please add you triggers that you would like to see that would allow an app (real or headless) to be invoked.

[CMY]

Don't know which or if any of these are already implemented:

• Calendar appointment (Added, removed, modified, occurence)
• Change in time/timezone
• Any hub message notification (sent,received,etc)
• Device locked/unlocked

[UberschallSamsara]

Also not sure what is already implemented, but:

• GPS location is/is not in a particular radius or speed is/is not above a threshold (e.g. location based reminders, location based phone silencing, GPS speed based autorespond to SMS/BBM - say if user is on freeway at speed the phone autoresponds but if they then hit a traffic jam the phone notifies normally).
• GPS location transitions into/out of radius of a location (e.g. on home->work commute, phone detects user is en route and VIKI starts reading off work related info, and on work->home commute she starts reading off home related info - useful for folks w/flex schedules)
• Time of day (e.g. change wallpaper, notification profile (i.e. silence the phone), etc based on time of day).
• Allow an app (e.g. meditation timer) to silence the phone w/user permission.
• Allow an app to auto-respond to SMS/BBM etc ("Got your message; busy; will respond later") if user is in a long duration focused task (e.g.  gym/yoga/meditation/on a long drive etc).  "Keep moving" should not mean constantly hyper-interruptible.  There are times when hyper multitasking is counterproductive.
• Calendar appointment based phone silencing

[jtegen]

In regards to GPS speed thresholds, I think it might need to be an average speed for some time threshold. For example, > 30m/s for 30 seconds. If not, you will be getting apps starting pretty violently because of erratic GPS updates and driver behavior. I would also have the operation less then and greater then as well. This might be true for all similar operations (above, below or on) some value. Then you have to deal with how often these kind of events get triggered. The driver is at 10m/s for 30 seconds, get a trigger. They continue to drive at 10m/s, does the system send another trigger? They fall to 9m/s and then back up to 11m/s a minute later; another trigger? How much of this is the underlying OS responsibility and how much is it the apps responsibility??

[UberschallSamsara]

---

jtegen wrote:
In regards to GPS speed thresholds, I think it might need to be an average speed for some time threshold. For example, > 30m/s for 30 seconds. If not, you will be getting apps starting pretty violently because of erratic GPS updates and driver behavior.

---

Totally agree ... things like GPS and accelerometer data need to filtered appropriately per the application.

Sounds like you're talking about making a hysteresis curve for the raw datafeed; makes sense for thermostats, and makes sense for this application.

[Innovatology]

Limiting headless apps to predefined use-cases like this probably will stiffle innovation. Look how limited background apps on IOS are, and the stick that Apple has had for it...

But it's a start, I guess. I'll add:

• device started
• app installed
• app about to be uninstalled
• app data backed up
• filesystem changes to files/folders specified by the app
• Q10 keyboard shortcuts
• changes in cellular status
• clipboard operations
• changes to the music library
• changes to the picture & video thumbnail library
• deltas from cloud providers
• battery/charger status/threshold changes
• holster, dock, USB
• changes in BlueTooth state, pairing, device availability
• now playing changed
• account changes
• "any" PPS channel post

Apps should also have the ability to enable/disable/pause/resume/configure these notifications via an API, not just statically in their manifest file.

[jtegen]

Hooks and triggers to prevent a person from texting, surfing, etc., when driving. This really should be a OS level feature that can be activated by the carrier via parental controls. So the ability to prevent things from being invoked or used when another condition occurs.