[kennyliu]

I have purchased quite a few apps but all of them have one annoying feature - they don't run in the background.

IM+, for example, is pretty much useless as it doesn't run when closed and does not give you any notifications. Without the ability to run in the background, it's a waste of $8 as you can simply get the same functionality from the web-based instant messaging services.

Again, it's not only IM+ but pretty much all apps (at least those I have bought).

I was wondering what prevents developers from including the background operation functionality. I actually read here and there that it's the "lack of API" (?), but I absolutely don't know what this means.

Furthermore, do you, folks, expect that the OS 2.0 will change the situation (e.g. RIM releases everything needed to the developers along with the update)?

Thanks.

[caquito07]

I have purchased quite a few apps but all of them have one annoying feature - they don't run in the background.

IM+, for example, is pretty much useless as it doesn't run when closed and does not give you any notifications. Without the ability to run in the background, it's a waste of $8 as you can simply get the same functionality from the web-based instant messaging services.

Again, it's not only IM+ but pretty much all apps (at least those I have bought).

I was wondering what prevents developers from including the background operation functionality. I actually read here and there that it's the "lack of API" (?), but I absolutely don't know what this means.

Furthermore, do you, folks, expect that the OS 2.0 will change the situation (e.g. RIM releases everything needed to the developers along with the update)?

Thanks.

TRy changing the setting for Application Behavoir, go to Settings, click on General, change Applicaiton Behavior from Default to Showcase

[blackjack93117]

Yep - put it in showcase mode. Why this isn't the default who knows.

[kennyliu]

TRy changing the setting for Application Behavoir, go to Settings, click on General, change Applicaiton Behavior from Default to Showcase

Thanks but I am talking about a different "background operation" functionality. For instance, on my android phone, I simply close Facebook, Skype, IM+, and many other apps and they still get me notifications (only present in the notification bar/slider). That is, the apps are "closed" and are retrieved only when needed.

Furthermore, the notification system is integrated into the OS and you get all sorts of notifications (vibrate, LED, sound, screen flashing, etc.).

And in the Playbook, the app window should be open for the app to be alive. I.e. I have a feeling that each app is kind of "sandboxed".

[blackjack93117]

Thanks but I am talking about a different "background operation" functionality. For instance, on my android phone, I simply close Facebook, Skype, IM+, and many other apps and they still get me notifications (only present in the notification bar/slider). That is, the apps are "closed" and are retrieved only when needed.

Furthermore, the notification system is integrated into the OS and you get all sorts of notifications (vibrate, LED, sound, screen flashing, etc.).

And in the Playbook, the app window should be open for the app to be alive. I.e. I have a feeling that each app is kind of "sandboxed".

If the apps are closed and retrieved only when needed - that is not multitasking - it is app switching. You are talking about notifications - which are not really the same thing. Apps can run in a minimized state and perform minimal functionality like this - but not be running completely functionally as playbook apps do. If the app needs to be open to be alive that is not multitasking. They ARE running in the background at all times in showcase mode.

The answer to your question is that apps can and do run in the background on playbook. In fact you can see them running when minimized. Open a few in showcase mode - perhaps youtube and something else with activity in the screen - the Vevo app, a download with a progress bar. Minimize them and you can watch what they are doing simultaneously - or listen to the audio. they are NOT sandboxed or suspended, and they DO run in the background.

Anything else?

[kennyliu]

If the apps are closed and retrieved only when needed - that is not multitasking - it is app switching. You are talking about notifications - which are not really the same thing. Apps can run in a minimized state and perform minimal functionality like this - but not be running completely functionally as playbook apps do. If the app needs to be open to be alive that is not multitasking. They ARE running in the background at all times in showcase mode.

The answer to your question is that apps can and do run in the background on playbook. In fact you can see them running when minimized. Open a few in showcase mode - perhaps youtube and something else with activity in the screen - the Vevo app, a download with a progress bar. Minimize them and you can watch what they are doing simultaneously - or listen to the audio. they are NOT sandboxed or suspended, and they DO run in the background.

Anything else?

Thanks for the response. Semantics aside, CLOSING apps on the Playbook, terminates the app itself. Closing some apps in Android only sends them to the background where they still keep running.

In other words, on the Playbook, you have to keep all needed apps OPEN/MINIMIZED in order for them to "run" in the "background".

Maybe I am not explaining this too well, but, again, the same IM+ runs absolutely differently on the Playbook and on Android. On the Playbook, you have to have the window open/minimized, whereas in Android, you just "close" it. It's no longer visible (except for the little icon in the notification bar) but it's still there running in the background.

OK, that's just UI implementation. The biggest annoyance, however, is that there is no integration of notifications in QNX. All notifications are within the app and only if the latter is open/minimized.

Those who have used Android for some time will probably understand what I mean. Same goes for desktop OSs. For instance, you can CLOSE windows for certain apps but the apps continue running and can be retrieved from the notification area.

I just remember Peter (the developer of Battery Guru) said something about the lack of APIs when he explained why Battery Guru should be open to log the readings, so I thought developers could explain this in a greater detail.

[Megacharge]

Thanks for the response. Semantics aside, CLOSING apps on the Playbook, terminates the app itself. Closing some apps in Android only sends them to the background where they still keep running.

In other words, on the Playbook, you have to keep all needed apps OPEN/MINIMIZED in order for them to "run" in the "background".

Maybe I am not explaining this too well, but, again, the same IM+ runs absolutely differently on the Playbook and on Android. On the Playbook, you have to have the window open/minimized, whereas in Android, you just "close" it. It's no longer visible but it's still there running in the background.

OK, that's just UI implementation. The biggest annoyance, however, is that there is no integration of notifications in QNX. All notifications are within the app and only if the latter is open/minimized.

Those who have used Android for some time will probably understand what I mean.

I just remember Peter (the developer of Battery Guru) said something about the lack of APIs when he explained why Battery Guru should be open to log the readings, so I though developers could explain this in a greater detail.

I have an Android phone, and I understand what you are saying. For me this is a flaw/negative of Android. When I close an app, I closed it because I wanted it closed. It makes me angry when I have to bring up the task manager to close apps that I recently closed, and it bothers me big time that Android doesn't have an "active app" tray like the windows on the Playbook.

I love Android, but I can't stand how it handles multitasking, it's almost as bad as iOS in that regard.

[kennyliu]

I have an Android phone, and I understand what you are saying. For me this is a flaw/negative of Android. When I close an app, I closed it because I wanted it closed. It makes me angry when I have to bring up the task manager to close apps that I recently closed, and it bothers me big time that Android doesn't have an "active app" tray like the windows on the Playbook.

I love Android, but I can't stand how it handles multitasking, it's almost as bad as iOS in that regard.

Yes, for some apps it's a con, but most of the time there are settings to disable such behavior.

On the other hand, running certain apps in the background is what those apps were actually meant to do. For example, I really want instant messaging apps to constantly run in the background to notify me of messages so that I read them once they arrive. Of course, I can sign out (terminate the app) or become "invisible" any time, if I don't want to be bothered. But still, I believe certain apps have to have that ability to run in the background (and it should be up to you whether you want them in the background or not). Unfortunately, on the Playbook you don't get to choose. So I am hoping someone can answer why and whether this will change any time soon.

[Superfly_FR]

Yes, for some apps it's a con, but most of the time there are settings to disable such behavior.

On the other hand, running certain apps in the background is what those apps were actually meant to do. For example, I really want instant messaging apps to constantly run in the background to notify me of messages so that I read them once they arrive. Of course, I can sign out (terminate the app) or become "invisible" any time, if I don't want to be bothered. But still, I believe certain apps have to have that ability to run in the background (and it should be up to you whether you want them in the background or not). Unfortunately, on the Playbook you don't get to choose. So I am hoping someone can answer why and whether this will change any time soon.

I think what you"re talking about is more related to a "service" running app mode (as in windows) than a multitasking problem. Maybe next generation of apps and QNX (OS10/PB2.0 OS) will allow such implementations (as they are, for instance on our BB Phones for Facebook app). At this point I couldn't say that the PB development platform(s) allow such notifications/ services, but maybe a dev could ?

[collapsed]

Gosh..Just like facebook on your BB smartphone. You get notifications even if you close the app. You have to keep it open on the playbook and it looks a bit weird..since i usually close everything before putting it in stand-by

[thymaster]

The PB does support notification API. Look at AppWorld when there is an app that requires an update, AppWorld runs in the background and sends a notification icon (exclamation mark) in the right corner.

Apps that doesn't completely close in the background is not a flaw but a BAD idea. Apps like Messenger and Appworld are ok to run in the background waiting for the server to talk back. However most apps on Android and iOS that isn't closed properly are still stored in RAM which can build up and causes the OS to congest. The average consumers don't know how to terminate these apps properly and don't care so they get pissed off because their device keeps freezing on them. I love how the PB OS was design to terminate these apps properly and easily.

[kennyliu]

The PB does support notification API. Look at AppWorld when there is an app that requires an update, AppWorld runs in the background and sends a notification icon (exclamation mark) in the right corner.

Yes, I agree on this. Notifications work with the native apps (AppWorld, alarm clock, hopefully email). But I haven't seen any third-party app using notifications.

Apps that doesn't completely close in the background is not a flaw but a BAD idea. .... However most apps on Android and iOS that isn't closed properly are still stored in RAM which can build up and causes the OS to congest. The average consumers don't know how to terminate these apps properly and don't care so they get pissed off because their device keeps freezing on them.

Not entirely true. Android handles the congestion by terminating inactive apps itself.

I love how the PB OS was design to terminate these apps properly and easily.

I love this design too, but...

Apps like Messenger and Appworld are ok to run in the background waiting for the server to talk back.

certain apps as those you mentioned (mostly PIM - email, calendars, instant messaging, social networking, etc.) should be able to run in the background. Otherwise, they have no benefit over web-based apps or websites.

[peter9477]

Short answer (I'm rushing out the door): the term "API" refers to Application Programming Interface (or, no doubt, variations thereof) and basically means that the operating system has to provide an interface to allow apps to create "services" (the generic term for "things that run in the background") or you can't do it.

Right now, although the OS itself obviously supports services (it's got dozens running for its own purposes), it's not yet possible for apps to create them.

We need RIM to define an API that allows that... simple as that.

Notifications are fine, but an app can't trigger them when it's not running. If an app can "spawn" a service, that service can continue to run, using very little memory (think tens of kilobytes of RAM, possibly, instead of tens of megabytes) and almost no CPU, but doing whatever it is that it needs to do in the background (i.e. without a UI showing). It could signal the user via notifications when it's ready for interaction, such as with (say) a Twitter app which does a periodic search of recent tweets and tells you when "something interesting" has occurred. You'd tap on the notification and that would launch the UI for the app again, which would then interact with the service to find out what had been going on while it was not running.

There are a half dozen things that need to be in place before all this can work, and it hasn't been at the top of RIM's list of priorities but they are working on it.

Some people may not be too familiar with this idea of services, but no modern operating system would look like much if they weren't littered with them...

[Innovatology]

Peter, you call that "short" ?!

[app_Developer]

@peter9477, do you think we'll get this with OS2? Or do you think that will be something later?

How about just a notifications API (push or local) at least? Or did I miss that?

Sorry to bug you, but you've been more forthcoming and credible with this stuff than anyone else I've spoken to at RIM so far.

Cheers.

[kbz1960]

It's a baby OS these things will come in time. I haven't used IM+ but have used the web interface and ran imo.im android app when I was on the beta. I never tried them on wifi but imo.im would not work at all over bridge and the web based ones all seem to time out when they are not the focus. I'm not sure how they act on wifi as I use my playbook when away from wifi.

[omniusovermind]

Not entirely true. Android handles the congestion by terminating inactive apps itself.

Not sure how well the tablet android OS`s are handling this (although I`m not hearing much improvement) but I know on my phone running gingerbread, android is allowing a lot of RAM-sucking to happen in the background before it starts closing inactive apps down, which leads to slightly laggier performance as well as increased battery drain. Good concept in theory but I`m not a fan of it in practice due to those reasons. I much prefer the QNX style of giving me total control of my multi-tasking

[StikiGreenZ]

Another example of an app that should run is BlackBerry news. On the smartphone version, it updates the news constantly depending on the frequency you ask for. On the PlayBook, it doesn't update til the app is launched. Me personally, I'm on the subway when I need it, and I don't have reception at that point. It would be nice for the app to be able to update silently in the background as it does on smartphones. I'm forced to do a workaround (open the app when I wake up in the morning, which I tend to forget 4/5 days of the week!)

[Rickroller]

I have an Android phone, and I understand what you are saying. For me this is a flaw/negative of Android. When I close an app, I closed it because I wanted it closed. It makes me angry when I have to bring up the task manager to close apps that I recently closed, and it bothers me big time that Android doesn't have an "active app" tray like the windows on the Playbook.

I love Android, but I can't stand how it handles multitasking, it's almost as bad as iOS in that regard.

You don't need to go into task manager to close apps. That's how Android is designed to run..the system itself will manage it's own memory and close things as its needed. And if this really does bother you..you should look into CyanogenMod roms. They have a setting to long press the back button to "kill" the application completely.

[omniusovermind]

You don't need to go into task manager to close apps. That's how Android is designed to run..the system itself will manage it's own memory and close things as its needed. And if this really does bother you..you should look into CyanogenMod roms. They have a setting to long press the back button to "kill" the application completely.

But as I said 2 posts up...
Also, I`m not sure having to suggest rooting a device in order to get this functionality is a positive.

[kbz1960]

You don't need to go into task manager to close apps. That's how Android is designed to run..the system itself will manage it's own memory and close things as its needed. And if this really does bother you..you should look into CyanogenMod roms. They have a setting to long press the back button to "kill" the application completely.

Does it just close whatever it feels like closing? What if you want an app to stay and android closes it on you? Wouldn't that pee you off a little or be annoying as heck?

[kennyliu]

Short answer (I'm rushing out the door): the term "API" refers to Application Programming Interface (or, no doubt, variations thereof) and basically means that the operating system has to provide an interface to allow apps to create "services" (the generic term for "things that run in the background") or you can't do it.

Right now, although the OS itself obviously supports services (it's got dozens running for its own purposes), it's not yet possible for apps to create them.

We need RIM to define an API that allows that... simple as that.

Notifications are fine, but an app can't trigger them when it's not running. If an app can "spawn" a service, that service can continue to run, using very little memory (think tens of kilobytes of RAM, possibly, instead of tens of megabytes) and almost no CPU, but doing whatever it is that it needs to do in the background (i.e. without a UI showing). It could signal the user via notifications when it's ready for interaction, such as with (say) a Twitter app which does a periodic search of recent tweets and tells you when "something interesting" has occurred. You'd tap on the notification and that would launch the UI for the app again, which would then interact with the service to find out what had been going on while it was not running.

There are a half dozen things that need to be in place before all this can work, and it hasn't been at the top of RIM's list of priorities but they are working on it.

Some people may not be too familiar with this idea of services, but no modern operating system would look like much if they weren't littered with them...

Finally, an answer from a developer. Thanks a lot, Peter.

Any word on how soon developers can expect the background services for third party apps to be implemented?

[kennyliu]

Does it just close whatever it feels like closing? What if you want an app to stay and android closes it on you? Wouldn't that pee you off a little or be annoying as heck?

IIRC Android will close only inactive apps on a FIFO basis.

If you have 1mb of RAM, memory is generally not a problem in Android.

[kbz1960]

IIRC Android will close only inactive apps on a FIFO basis.

If you have 1mb of RAM, memory is generally not a problem in Android.

So if I opened an IM app first, then opened several other apps it would start by closing the IM app I want to stay open?

[kennyliu]

So if I opened an IM app first, then opened several other apps it would start by closing the IM app I want to stay open?

No, if IM is still running in the background, it won't be closed. That's what's great about apps/services/processes running in the background. Besides, background services eat up a negligible amount of RAM.

Again, it's closed and inactive apps that get closed. At least, this is how I understand it.