- I am not sure what you mean by overriding the device's behavior settings. But in Android, you get a third party app's (e.g. IM) notifications "integrated" into the OS itself (just like AppWorld notifications) and the app will be running in the background when the window is actually closed and will usually use very little of the processing power and RAM.
I think the question about "tiny executables" should be addresses to a different poster. I never mentioned anything about executables.
So not only is it not possible to control our own app's behaviour to the extent that we would like, neither can we wake up other sleeping services to do our bidding.
This may change some day (we hope). With bluetooth API (also not yet available) and a notification API, we could build apps that work like Poynt on the PlayBook.kennyliu likes this.01-06-12 01:29 PMLike 1 -
Nobody was talking about multitasking per se. But for what it's worth background services/notification only aid multitasking. I hope we'll see this implemented on the Playbook some day. As Peter explained, I really don't want the UI window of, say, Facebook, Skype (if we ever get it), or a third party calendar/to-do list app to be constantly up and running. Of course, there should be an option to set the defaults for background services of apps that require them.app_Developer likes this.01-06-12 01:33 PMLike 1 -
On iOS, for example, VoIP and music streaming apps do get cycles in the background. And apps that use internet services can request up to 600 seconds to complete uploads or transactions, etc. Navigation apps and run trackers can get plenty of cycles to update their location.
And on Android, you can write services that continue to work in the background. But you have to be careful, as @omniusovermind points out, that as a developer you don't end up interfering with your user's other work over the course of the day.
This may not be obvious yet to RIM. But eventually people will get apps that remind them to pick up the laundry as they walk by the service, or "remind me to call Mom when I get at home", etc. When users restart their device or something, they don't want to remember which of those apps they want running and then manually go and restart them as needed. Do I really want to remember to start the app that is supposed to remember something for me?? And then remember which ones they want to quit when they want to run some other big app.
There's a whole set of decisions and rules that got worked out over a few years. When you have lots of apps from lots of developers, these things come into play.Last edited by app_Developer; 01-06-12 at 01:43 PM.
VerryBestr likes this.01-06-12 01:34 PMLike 1 - Sorry for my mistake. There are currently no notifications from the system like the ones that we have on BB smartphones. For example it is quite impossible to write an app that monitors email activity and allows my app to do something with the notification. Even if there were such notifications right now, the chances are very good that my app would be asleep and could not respond. Same applies to opening or waking an external app and sending a message to it. We can't, for example, give an external app a location and tell it to display a map.
So not only is it not possible to control our own app's behaviour to the extent that we would like, neither can we wake up other sleeping services to do our bidding.
This may change some day (we hope). With bluetooth API (also not yet available) and a notification API, we could build apps that work like Poynt on the PlayBook.
Do you know if developers have been pushing RIM to release the APIs? Is it possible that RIM are deliberately not releasing the APIs for some reason?
I really want to know this because I love the OS but this is one of the features (along with native email) I am missing so much.01-06-12 01:41 PMLike 0 - Background services of certain apps in Android are not paused. They keep running.
Nobody was talking about multitasking per se. But for what it's worth background services/notification only aid multitasking. I hope we'll see this implemented on the Playbook some day. As Peter explained, I really don't want the UI window of, say, Facebook, Skype (if we ever get it), or a third party calendar/to-do list app to be constantly up and running. Of course, there should be an option to set the defaults for background services of apps that require them.
Services do not need to "aid" multitasking, if the app is fully functional. They are NOT a substitute for a fully running app. Yes a service has important functionality in the case of the apps that you mention - that really are idle most of the time, but don't confuse or blur the lines of distinction between a fully functional running app with a crippled version of it.
Running a service for an app in the background is NOT true multitasking. It only gives the user that perception. Thank you for this thread it makes me appreciate the Playbook and QNX even more as I learn how android does things.
Agreed - the ability for an app to spawn a service would be nice and a lack of functionality, but it certainly is possible to do this and I expect it in the future of Playbook's evolution.
.
.Last edited by blackjack93117; 01-06-12 at 01:50 PM.
01-06-12 01:41 PMLike 0 - Yes exactly what I said - background "services" not background apps. I am talking about apps, you are talking about services. - Your thread title says apps. I think you are intentionally avoiding my point. You seem like an intelligent guy that by now has grasped the difference between a fully running app and a service at this point in the thread.
Services aid multitasking but they are NOT a substitute for a fully running app. Yes a service has important functionality in the case of the apps that you mention - that really are idle most of the time, but don't confuse a fully functional running app with a crippled version of it.
.
In any case, some people here understood me quite well and gave me some of the answers I needed without knit picking words. As if the wording would change anything about the missing functionality.
Mods, can you, please, change the word 'apps' to 'services'? Otherwise, it bothers certain folks here more than it should. They are concerned that the word "app" in the title somehow threatens the "true multitasking" ability of the Playbook.Last edited by kennyliu; 01-06-12 at 02:02 PM.
01-06-12 01:53 PMLike 0 - I already apologized for the bad choice of words and am not going to do it again. Speaking of fully functioning apps, who needs a video in the background? :-)
In any case, some people here understood me quite well and gave me some of the answers I needed without cherry picking words. As if the wording would change anything about the missing functionality.
Mods, can you, please, change the word 'apps' to 'services'? Otherwise, it bothers certain folks here more than it should.
I am not meaning to sound hostile, just keeping the facts straight. I concede that not having services is a missing functionality, and I appreciate the thread and the discussion I have learned a lot.
Playbook has been damaged enough already with misinformation going around. It is an important distinction.
Thanks for your permission I will PM a mod.
.Last edited by blackjack93117; 01-06-12 at 02:05 PM.
kennyliu likes this.01-06-12 02:01 PMLike 1 - Thank you so much for the detailed answer. I somehow thought that the APIs would be part of the NDK that was released by RIM a couple of months ago.
Do you know if developers have been pushing RIM to release the APIs? Is it possible that RIM are deliberately not releasing the APIs for some reason?
I really want to know this because I love the OS but this is one of the features (along with native email) I am missing so much.
There are different types of multitasking - both are necessary to give the impression that everything is running at once. Preemptive multitasking is when the OS arbitrarily parcels out time slices to each "running" app. Cooperative multitasking occurs when the apps' runtime system and also the programmers themselves have a bit of say in how much time the OS should provide for their own selfish purposes. Right now it appears that apps that come with the OS have the ability to engage in both types of multitasking. But third-party apps do not have the API's they need to engage in cooperative multitasking.
The current behaviour settings, together with notifications to apps about what the OS has decided to do preemptively, are a rather crude stop gap methods to provide cooperative multitasking. In my opinion this is a worse flaw that some "missing" features like native email and such, but I would get some argument about that. This is why I think that we have to wait a bit before we boast that PB has "true" multitasking.01-06-12 02:20 PMLike 3 - I wish that people wouldn't get so hung up on the word "multitasking". Multitasking is always an illusion - no matter what platform you are talking about each it can only do one thing at a time. Processes are being paused and activated all the time. In a "perfect" system this swapping happens completely transparently so that the average user never notices it. I think this whole discussion is about how much you notice inefficiencies in whatever multitasking scheme has been implemented. In my opinion PB is closer to "perfection" than Android or iOS but there is lots more work required before we can declare victory.
There are different types of multitasking - both are necessary to give the impression that everything is running at once. Preemptive multitasking is when the OS arbitrarily parcels out time slices to each "running" app. Cooperative multitasking occurs when the apps' runtime system and also the programmers themselves have a bit of say in how much time the OS should provide for their own selfish purposes. Right now it appears that apps that come with the OS have the ability to engage in both types of multitasking. But third-party apps do not have the API's they need to engage in cooperative multitasking.
The current behaviour settings, together with notifications to apps about what the OS has decided to do preemptively, are a rather crude stop gap methods to provide cooperative multitasking. In my opinion this is a worse flaw that some "missing" features like native email and such, but I would get some argument about that. This is why I think that we have to wait a bit before we boast that PB has "true" multitasking.
Valid point, it is always switching between tasks, but it is still considered true multitasking if the full functionality is not crippled, paused or perceptibly handicapped for any of the current tasks by this switching.
Multitasking means just that - handling several tasks at a rate that is fast enough to preserve full functionality. Of course it always means switching between them, the question is can do that at a rate fast enough to keep up with the requirements of the system, and all of the open tasks. If the switching is left to the user, then chances are this wont happen.
Agreed cooperative multitasking would be better for more efficient use of resources. Lets hope this improves.
.
.Last edited by blackjack93117; 01-06-12 at 02:56 PM.
01-06-12 02:29 PMLike 0 - The current behaviour settings, together with notifications to apps about what the OS has decided to do preemptively, are a rather crude stop gap methods to provide cooperative multitasking. In my opinion this is a worse flaw that some "missing" features like native email and such, but I would get some argument about that. This is why I think that we have to wait a bit before we boast that PB has "true" multitasking.
But I think people (not you!) misunderstand something here . Microsoft, Apple and Google all attract really fantastic engineers and computer scientists from all over the world. That is a fact. Some of them have 30+ years of personal experience building operating systems at various scales.
These guys understand what multitasking is. And all 3 of their mobile operating systems are built on kernels that multitask at small and large scale every single day. And yet all three teams chose to limit, organize, and funnel the activities of background tasks on mobile devices in different ways because all three engineering teams felt that was the right engineering decision on these kinds of devices.
Nobody at Microsoft or Google or Apple looked that the Playbook and its "true multitasking" and slapped themselves on the forehead and said "Oh my God, why didn't we think of that?! Go find out about this 'multitasking' thing!". They all thought this through very well and the result is what you see (in different flavors) on WP7, iOS and Android.
We'll see how this all works out with PB OS and BB10. Obviously, they will need to build some way for apps to post notifications for users, and for services to push notifications down. And they will need some more ways to do things like consume system services (maybe even third party) and content providers. I'm sure all of that is coming as they figure this all out and get feedback from developers.
Just look at how much iOS and Android have grown in the past 3 years.Last edited by app_Developer; 01-06-12 at 02:56 PM.
01-06-12 02:51 PMLike 3 - Valid point, it is always switching between tasks, but it is still considered true multitasking if the full functionality is not crippled, paused or perceptibly handicapped for any of the current tasks by this switching.
Multitasking means just that - handling several tasks at a rate that is fast enough to preserve full functionality. Of course it always means switching between them, the question is can do that at a rate fast enough to keep up with the requirements of the system, and all of the open tasks. If the switching is left to the user, then chances are this wont happen.
.
.
RIM has implemented a fine framework for "true" multitasking but so far, I can't get access to that framework when I am writing my app. My app pauses and activates on a whim and I have no control over the matter. EDIT: I can't tell the processor that I want my app to wait patiently in the background and then wake up again when something interesting has happened elsewhere. Until RIM fixes the problems, my app can't do certain things that users think it should be capable of doing. The result, of course, is that people will be inclined to start threads like this one.
It's really not worth getting worked up about. The OPs question has been asked and I think it has been answered. If we had claimed that there isn't a problem because PB has "true" multitasking, then we would have accomplished nothing.Last edited by BuzzStarField; 01-06-12 at 03:21 PM.
01-06-12 03:13 PMLike 3 -
***
By the way, I was out today but managed to skim all the posts earlier. I noticed that the term "background" was causing some concern, and people should note that this term, as with many, is ambiguous or "overloaded". That is, it can be used in several senses, and the use of two different forms of it seems to have led to a bit of argument.
"Background" merely means "not in the foreground", and "foreground" would generally mean something like "allows the user to interact with it". (I've also seen it used to mean "the active thread" in a multitasking system, where the other threads are "in the background", I guess because they're sort of lurking there waiting to run again.) In the case of the PlayBook, you've got at least two things you could call foreground: apps which have windows open (allowing the user to interact), or the one and only app which is currently full-screen. Depending on which you mean, we've either already got "background apps" (just enable Showcase mode), or you're talking about what I called "services" earlier, which implies a process without a conventional window (and which the user doesn't interact with directly).
Lastly: note that Showcase mode isn't even required to make apps run in the "background" (in the non-service sense). Both my apps actually work basically the same way regardless of how you've set your Application Behaviour setting. (In the case of White Noise, it actually disables some cosmetic animations if it's not fullscreen and you don't have Showcase mode on, but the audio portion works the same regardless.) Originally we didn't have all the APIs to do this perfectly well, but it's all there now if a developer chooses to use it.Last edited by peter9477; 01-06-12 at 04:22 PM.
01-06-12 03:18 PMLike 5 -
I just can't find the API. I must be looking in the wrong place. Are you talking about the badge on the window frame itself?
Here is where I'm looking. A pointer in the right direction would be most appreciated! And I think the OP can send the same back to the developer of his app as well.
https://bdsc.webapps.blackberry.com/..._overview.html01-06-12 05:19 PMLike 0 - OK, that's great. That would solve the OP's issue also, right?
I just can't find the API. I must be looking in the wrong place. Are you talking about the badge on the window frame itself?
Here is where I'm looking. A pointer in the right direction would be most appreciated! And I think the OP can send the same back to the developer of his app as well.
https://bdsc.webapps.blackberry.com/..._overview.html01-06-12 05:44 PMLike 0 - I was wondering about this too. In cases where timer events and screen updates are important, it is small consolation that sounds work regardless of the behaviour setting. In my AIR app, everything is fine in showcase mode. But whenever a user decides to switch app focus in the other modes, I must I must respond to a reactivation notice so that the state can be updated to reflect current date/time. There does not appear to be a workaround at this time. I am not surprised that some "new" PB developers miss out on the subtle differences between the various behaviour modes. Testing an app can be quite difficult under these circumstances.
Am I missing a better source?01-06-12 05:47 PMLike 0 -
With the tools shown there, in an AIR app, you can give your app pretty much any sort of behaviour, whether in Showcase, Default, Paused, or even Standby, and with window fullscreen, minimized, or hidden.01-06-12 05:55 PMLike 0 -
Sorry to throw you off: it is in there and largely usable, but obviously not finished either.
(Edit: see extracted docs for the Python version here, which shows some sample code buried in the docs as well.)Last edited by peter9477; 01-06-12 at 06:09 PM. Reason: edit: add link to some more unreleased docs
app_Developer likes this.01-06-12 06:07 PMLike 1 - Hmm... I seem to be talking about something that actually hasn't been finished and published yet. Some people have figured it out and are actively using it in AIR apps, and I was able to get it working in my BBX-Python demo app (see notifications.py or just install the .bar file and observe). I don't see anything listed for it in the NDK docs, as you noticed, so anyone doing it there is connecting to the notification service via PPS and doing it "manually".
Am I looking at the best available public source for documentation right now? That website?
Sorry to throw you off: it is in there and largely usable, but obviously not finished either.
(Edit: see extracted docs for the Python version here, which shows some sample code buried in the docs as well.)
Thanks!spike12 likes this.01-06-12 06:12 PMLike 1 -
Python interpreter is sweet, and my fingers are still crossed they'll keep it all available in 2.0 release. For now, if it wasn't obvious: 2.0 beta only. It's not in 1.0.8.
If you're wondering why I've done nothing more with it yet: waiting for Cascades. If it has the Python wrapper available that I'm hoping it does, this would become yet another full-fledged environment for apps.
(See also Community Project on Python on the PlayBook | Open BB News )app_Developer likes this.01-06-12 06:22 PMLike 1 - I'm with the OP on this one, an app is running or it isn't. In this regards the PB is very iOS like.
Perhaps my favorite Android app is Tasker. The "app" itself is in fact just a GUI for the background service. This app allows conditional dependent activites, for example you can have the app do thing like turn on BT when a power cord is connected, or change your NSFW background to sfw background if you get within a certain location on a work day. The power is really unlimited and is really like a user program language for the operation of your device.
What I dont understand is that the Android player runs "Android" apps in the background (like Android does) in the background of QNX. Although by pointing out this I hope I havn't now convinced RIM to stop this.01-06-12 06:26 PMLike 0 - For NDK that would get you to https://bdsc.webapps.blackberry.com/native/ or whatever you find under the Documentation or API reference pages (or the others) in the top menu.
If you're wondering why I've done nothing more with it yet: waiting for Cascades.
If it has the Python wrapper available that I'm hoping it does, this would become yet another full-fledged environment for apps.
(See also Community Project on Python on the PlayBook | Open BB News )
Cool!Last edited by app_Developer; 01-06-12 at 06:32 PM.
spike12 likes this.01-06-12 06:29 PMLike 1 -
I really really really really hope that the 2.0 release lets us disable the Android player, or have a mode where it starts only on-demand and not like it is now. In the beta, it starts at boot time, quietly, secretly, surreptitiously and greedily stealing 200MB of precious RAM and other resources.
I doubt I'll ever use it and, if I do, I'd very much prefer that it stay completely out of my way until I actually try using an Android app. For others who are all over Android, I'm sure it will be nice to have launch at startup, so this should be user selectable in the Settings.
Fingers crossed tightly...app_Developer and kbz1960 like this.01-06-12 06:32 PMLike 2 -
- That's merely because the Android Player is itself much like a service and, for now, always running. That makes it a bit of a "cheat" that the Android stuff can do services, since it manages it by never actually quitting the Android player "app".
I really really really really hope that the 2.0 release lets us disable the Android player, or have a mode where it starts only on-demand and not like it is now. In the beta, it starts at boot time, quietly, secretly, surreptitiously and greedily stealing 200MB of precious RAM and other resources.
I doubt I'll ever use it and, if I do, I'd very much prefer that it stay completely out of my way until I actually try using an Android app. For others who are all over Android, I'm sure it will be nice to have launch at startup, so this should be user selectable in the Settings.
Fingers crossed tightly...
Good thread.01-06-12 06:56 PMLike 0
- Forum
- BlackBerry PlayBook Forums
- BlackBerry PlayBook
Why Can't Services Run in the Background?
LINK TO POST COPIED TO CLIPBOARD