[BuzzStarField]

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.

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.

[kennyliu]

That's the point - if it's in a paused state - it isn't really running in the background - this is not multitasking.

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.

[app_Developer]

That's the point - if it's in a paused state, or minimized state ( a service) - it isn't really "running in the background" - this is not true multitasking.

Of course it isn't (always). That's by design on both Android and iOS. Darwin/Mach and Linux are perfectly capable of "true" multitasking. Both kernels run with full multitasking on everything from old 68040s to nx6-core Xeons in SMP. But the engineers at Apple and Google made decisions there that I think make a lot of sense, marketing notwithstanding.

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.

[kennyliu]

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.

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.

[blackjack93117]

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.

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 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.
.
.

[kennyliu]

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.
.

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 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.

[blackjack93117]

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 need videos running in the background when I need to check my email and want to continue listening to the audio, and when I return I don't want to have to mess with restarting etc or whatever problems may have occurred with buffering etc. Or when I have the movie piped out to a large screen and want to browse at the same time.

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.
.

[BuzzStarField]

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.

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.

[blackjack93117]

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.
.
.

[app_Developer]

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.

And these are all things that will get worked out. Again, this is a brand new operating system and these guys have not dealt with the volume of third party apps that Microsoft, Apple and Google all have. And it is always hard when marketing ("True Multitasking!!!") gets a little ahead of engineering (we've all been there before!)

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.

[BuzzStarField]

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.
.
.

The term "true multitasking" has no real meaning. The best OS will be extremely proficient in parceling out available time so that all all the work being done by all open apps will get done as quickly as possible. An OS needs both processing power and efficient time-sharing routines to get things done in a way that pleases users. If proper attention is not given to cooperative multitasking it doesn't matter how fast the OS can switch tasks. It will be be acting arbitrarily and user will notice problems.

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.

[peter9477]

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

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

I don't expect we'll see this with 2.0, at least not officially. It may be something available to developers in an experimental form by then, but we've heard effectively nothing about it so I'm speculating.

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

I think you missed this, as there is a notifications API available, which apps which are running can use to produce notifications in the upper left, much the same as how the Bridge apps and others do it. The latest version of Blaq, for example, makes use of it.

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'm fairly sure RIM is not "deliberately" holding this stuff back, other than in the sense that they are choosing not to release something they simply haven't completed. They surely have a prioritized list of features to implement, and this one (rightly so, I'm sure) didn't make the cut for 2.0.

***

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.

[sf49ers]

may be I am reading too much in to the leaked BB10 picture but the option to minimize the app might be possible as shown in the picture

[app_Developer]

I think you missed this, as there is a notifications API available, which apps which are running can use to produce notifications in the upper left, much the same as how the Bridge apps and others do it. The latest version of Blaq, for example, makes use of it.

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.html

[BuzzStarField]

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.html

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.

[app_Developer]

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.

Well, I'm definitely new to the platform myself. So in general, is this website at https://bdsc.webapps.blackberry.com/...beta/reference pretty up to date as far as documentation? That's what I've been using in my playing around with this so far.

Am I missing a better source?

[peter9477]

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.

Buzz, are you overlooking this page on Power Management - Application and System States ?

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.

[peter9477]

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?

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".

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.)

[app_Developer]

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".

Ah, ok, I can hold off on getting those reading glasses then. My eyesight is still holding up.

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.

Oh, no, no. This is fantastic information. I'm really grateful for it.

(Edit: see extracted docs for the Python version here, which shows some sample code buried in the docs as well.)

Brilliant! I had no idea about the Python interpreter and packager either. That's cool! I shall go play now...

Thanks!

[peter9477]

Am I looking at the best available public source for documentation right now? That website?

Brilliant! I had no idea about the Python interpreter and packager either. That's cool! I shall go play now...

For all docs, start at BlackBerry - Tablet OS - Calling All Apps for the BlackBerry Tablet OS and drill down. 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.

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 )

[Snoman002]

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.

[app_Developer]

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.

Yes, this is where I have been reading. So I guess that's the best for now.

If you're wondering why I've done nothing more with it yet: waiting for Cascades.

Yep! I am waiting patiently for that as well. Can't get my company to commit to PB, but I will put some personal time into this definitely.

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 )

RIM should talk about this. I know a lot of developers who would love to do native Python development on a mobile device. Can't do that this easily on iOS or Android. That's a cool feature actually, especially like you say if we can put wrappers together (not exactly difficult, and I would contribute to this).

Cool!

[peter9477]

What I dont understand is that the Android player runs "Android" apps in the background (like Android does) in the background of QNX.

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...

[RCCollins]

The term "true multitasking" has no real meaning.

???????????????????????????


The issue of poor multitasking on the Playbook has to do with the development tools, and their lack of maturity. Any AIR app you can forget about, and that is practically all of them.

[Snoman002]

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 way to put it stating that right now Android is a service in the background, a sergice that it itself allows other service to run within it. I can understand the point of turning off this service but I REALLY hope it is an option and not shut down by RIM, to be honest if it is I will be getting rid of my new Playbook. Some might complain about me saying this but it comes down to it I dont want my mobile device to only be useful when I'm interacting with it. For example perhaps I want a better alarm on my Playbook (the stock one is horrible), now an app can do this for me, but i don't want to have to start my alarm app before I go to bed, or worse leave it running all the time, just to have my alarm go off in the morning.

Good thread.