Why Can't Services Run in the Background?
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)?
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".
Last edited by kennyliu; 01-06-12 at 12:54 AM.
01-06-12, 02:10 AM #5
- 4,157 Posts
- Wooden shoe like to know
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.
Last edited by blackjack93117; 01-06-12 at 02:13 AM.
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.
Last edited by kennyliu; 01-06-12 at 02:36 AM.
- CrackBerry Abuser
01-06-12, 02:33 AM #7
- 302 Posts
I love Android, but I can't stand how it handles multitasking, it's almost as bad as iOS in that regard.
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.
Last edited by kennyliu; 01-06-12 at 02:47 AM.
- 01-06-12, 03:32 AM #9
- 01-06-12, 03:59 AM #10
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
- 01-06-12, 04:34 AM #11
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.
Last edited by kennyliu; 01-06-12 at 04:50 AM.
- 01-06-12, 07:11 AM #13
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...
- CrackBerry Genius
01-06-12, 09:05 AM #15
- 4,059 Posts
@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.
- 01-06-12, 09:08 AM #16
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.
- 01-06-12, 09:15 AM #17
- 01-06-12, 09:17 AM #18
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!)
- 01-06-12, 09:21 AM #19
Again, it's closed and inactive apps that get closed. At least, this is how I understand it.
Last edited by kennyliu; 01-06-12 at 10:14 AM.