[kennyliu]

OK, that's great. That would solve the OP's issue also, right?

Will the API itself actually solve the problem if an app can't "spawn" a background service?

Peter, Blaq is not among the apps I have downloaded. Does it work in the background (as in a background service that doesn't require a GUI window)?

Thanks so much to everyone for contributing to the discussion. I hope someone will bring this to RIM's attention.

[dejanh]

Will the API itself actually solve the problem if an app can't "spawn" a background service?

Peter, Blaq is not among the apps I have downloaded. Does it work in the background (as in a background service that doesn't require a GUI window)?

Thanks so much to everyone for contributing to the discussion. I hope someone will bring this to RIM's attention.

My god, this thread...just wow...it makes my head hurt...

Look, here is a summary:

1. PB has a very effective multitasking ability
2. PB does not have developer exposed ability to spawn background services such as those polling some source regularly
3. PB does have notification ability, which in practice would allow any running app to display notifications, whether that app is in the background or foreground
4. An app that is not running will not generate events because it cannot dump a background system service that would take care of such a task

Does that summarize it finally?

This is no criticism to you just to be clear, but the whole discussion, "it's multitasking! it's not! it's a service! it's not!" is damn annoying.

Processes, threads, applications, services, events, and notifications are all different things and behave differently. Here's some reading on process vs. thread http://stackoverflow.com/questions/2...s-and-a-thread

Applications and services likewise play different roles. Applications are full features pieces of software, that typically include a GUI or some other user facing aspect that allows interaction. A service is something that runs autonomously and provides information to the user in some form. One cannot interact directly with a service without some application overlay in a true sense. In layman's terms app is smart and complex, service is dumb and simple.

Lastly, events are something that occurs whether internal or external to the system that applications or services would typically subscribe to and when an "event" occurs they would generate a "notification".

[peter9477]

Will the API itself actually solve the problem if an app can't "spawn" a background service?

Peter, Blaq is not among the apps I have downloaded. Does it work in the background (as in a background service that doesn't require a GUI window)?

Thanks so much to everyone for contributing to the discussion. I hope someone will bring this to RIM's attention.

As you suspect, and dejanh makes clear, it doesn't solve the problem if there's no service to let the app use notifications other than when it's running with a UI.

With respect to Blaq, no, it doesn't run in the background as a service, since as we've mentioned this simply isn't possible for non-Android apps on the PlayBook yet, other than those provided by RIM.

No real need to bring the discussion to RIM's attention, since they're well aware of all this. They would be interested in unusual use cases for services, however, and have solicited emailed input on the topic in a thread in the support forums. (Nothing we've discussed above is unusual, however, so emailing them about it would bring no novel use cases to their attention.)

[BuzzStarField]

My god, this thread...just wow...it makes my head hurt...
......

Lastly, events are something that occurs whether internal or external to the system that applications or services would typically subscribe to and when an "event" occurs they would generate a "notification".

If your head is hurting it is because users understand "multitasking" in a very different ways than does a developer. This oft discussed but little understood term popped up in the middle of the conversation which began on a totally different subject. In retrospect though, the OP was in fact asking why PB apps do not allow him to "multitask" - that is have several apps open at the same time and not have to worry about them not working as soon as he puts them in the background. There were many turns in the road but in the end, I think we did a very good job of answering the OP's question which was:

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

[peter9477]

(app_Developer discussing my off-topic Python references)

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!

They've mentioned it casually in several videos from May 5 last year.

The first one mentions Python just after 3:00 as having bindings you can use with Cascades.

The other one, done by Kevin, is interesting if you go to the version on Youtube and watch it fullscreen at 720P. Around 3:30 if you look in the IDE shown, at upper left, you'll see files Accelerometer.py and horizon.py, as well as "PyCascadesSDK" just below it.

Also, that OpenBBNews blog is run by a fellow who behind some of the recent Open Source initiatives at RIM.

Is this worth a thread of its own?

[kennyliu]

My god, this thread...just wow...it makes my head hurt...

Look, here is a summary:

1. PB has a very effective multitasking ability
2. PB does not have developer exposed ability to spawn background services such as those polling some source regularly
3. PB does have notification ability, which in practice would allow any running app to display notifications, whether that app is in the background or foreground
4. An app that is not running will not generate events because it cannot dump a background system service that would take care of such a task

Does that summarize it finally?

This is no criticism to you just to be clear, but the whole discussion, "it's multitasking! it's not! it's a service! it's not!" is damn annoying.

Processes, threads, applications, services, events, and notifications are all different things and behave differently. Here's some reading on process vs. thread multithreading - What is the difference between a process and a thread - Stack Overflow

Applications and services likewise play different roles. Applications are full features pieces of software, that typically include a GUI or some other user facing aspect that allows interaction. A service is something that runs autonomously and provides information to the user in some form. One cannot interact directly with a service without some application overlay in a true sense. In layman's terms app is smart and complex, service is dumb and simple.

Lastly, events are something that occurs whether internal or external to the system that applications or services would typically subscribe to and when an "event" occurs they would generate a "notification".

I actually got the answers to most of my questions in post # 13 on the first page of the thread (thanks to Peter). Then, the thread was hijacked and became an argument thread as to the correct definition of what I meant, although I suppose you, developers, understood what I was asking.

Thanks anyway for the summary and informative input. Once again, I hope QNX continues to evolve and will eventually give developers all they need to develop apps that are "fully functional".

Edit: Peter, if developers actually create something similar to what is shown in the videos you linked, that would be just a killer feature of the Playbook. That alone will differentiate (in a positive way) the Playbook from the crowd. Can't wait.

[BBOttawa]

Interesting discussion, awesome info! As a user rather than a PB programmer I am happy that apps can't leave a stub running that pops up notifications without my consent, while I'm sure most apps would be well behaved and give me the option to turn off such notifications, I'm also sure that some would not. Maybe not allowing them is an acceptable trade off, as you can leave apps running quite easily in the PB OS?

The Blaq Twitter app (Buy Blaq for BlackBerry PlayBook - Best Twitter™ experience - Download Blaq for BlackBerry PlayBook - Best Twitter™ experience - Buy Apps from BlackBerry App World great app btw, pick it up if you use Twitter, definitely worth it!) notifications implementation is nice (if I recall correctly I read they needed some neat coding tricks to make it work at this stage in the OS development), but I turned it off right away, if I want to see my notifications I just swipe over to the app, being interrupted while doing something else is a huge pain point on a leisure device such as a tablet for me, but YMMV of course. I know I also hate it on Windows, so maybe RIM is being careful given the memory constraints on a phone/tablet device. Just an end users perspective.

[shupor]

Funny thing is android apps running on the dev beta have the notification functionality yet 3rd party QNX apps don't.

[six6xis]

Once again, I hope QNX continues to evolve and will eventually give developers all they need to develop apps that are "fully functional".

What you're talking about has nothing to do with an app being "fully-functional". They're fully functional as they are. It sounds like what you want is some extra functionality or hooks into the Playbook OS which would be a great idea. What you are describing (as far as I can tell) is for an app to be started and then be minimized further so that it doesnt necessarily show up in the list of currently running programs when you swipe up on the bezel. The app will still be running as it does today but you just wont see it when switching windows. That's more of a design decision but once again that has nothing to do with the apps functionality, it's more of an organizational thing.

I can see where this would be useful. Say you want notifications from facebook, foursquare and twitter but you also have other apps that you're currently using. What you'd like is to be able to either:

1. Start an app and then "minimize" it so it continues running in the background but doesnt show up in the list of programs in use when you swipe up on the bezel.

2. Give developers an option to hook into the OS notifications or other functions where you can choose apps to run their functionality but use the Playbook functions like notifications without having to even open the app ala Windows Phone 7 and their People Hub. (i'm sure Android and IOS have the equivalent for some of their things)

It would be nice to have either option. If you have 7 different programs running maybe you only want to see three of them in use when switching. Who wants to cycle between a bunch of different cards when you don't have to.

I'm with you all the way on this one and i'm sure that they will continue to develop and tweak the OS to match some of the features found on their current phones.

[kennyliu]

What you're talking about has nothing to do with an app being "fully-functional". They're fully functional as they are. It sounds like what you want is some extra functionality or hooks into the Playbook OS which would be a great idea. What you are describing (as far as I can tell) is for an app to be started and then be minimized further so that it doesnt necessarily show up in the list of currently running programs when you swipe up on the bezel. The app will still be running as it does today but you just wont see it when switching windows. That's more of a design decision but once again that has nothing to do with the apps functionality, it's more of an organizational thing.

I can see where this would be useful. Say you want notifications from facebook, foursquare and twitter but you also have other apps that you're currently using. What you'd like is to be able to either:

1. Start an app and then "minimize" it so it continues running in the background but doesnt show up in the list of programs in use when you swipe up on the bezel.

2. Give developers an option to hook into the OS notifications or other functions where you can choose apps to run their functionality but use the Playbook functions like notifications without having to even open the app ala Windows Phone 7 and their People Hub. (i'm sure Android and IOS have the equivalent for some of their things)

It would be nice to have either option. If you have 7 different programs running maybe you only want to see three of them in use when switching. Who wants to cycle between a bunch of different cards when you don't have to.

I'm with you all the way on this one and i'm sure that they will continue to develop and tweak the OS to match some of the features found on their current phones.

Yes, but actually what I was talking about was services as others correctly pointed out. Services are not the same as running "minimized" (non-visible) apps (please, correct me if I understood you wrong here). One critical distinction is their resource intensiveness compared to fully running apps (low load on the CPU and memory).

And when I said "fully functional" apps I was imagining something like IM+ (or a Facebook, Twitter, etc. app) that is not FULLY functional without the ability to run a service in the background and notifications.

[azrin640]

he3, very long discussion, my eyes almost watered while reading it all.

API is a small programs provided by manufacturer for developer to access the main OS for specific task. eg, blinking led, gps and so on.

in a developer's main program, it can integrate or call the API. API is like a black box, you feed input then you get output. so developers do not need to know how to program for each function. it is already there to use.

As for Pb OS it is relatively new and API is being developed. You can see the difference of numbers between java base API for bbos and playbook below,

bbos RIM Device Java Library
playbook https://bdsc.webapps.blackberry.com/html5/api/

that is why notification in playbook is not yet used by apps. mostly because the api is not there yet.

[azrin640]

you can also check out the difference with ios API

iOS 5.0 Release Notes: iOS SDK Release Notes for iOS 5.0

Take note how different it is.

[robsteve]

Peter, you call that "short" ?!

I will give you short, two symbols, #,&

[robsteve]

I assume the programmers have no shell access to start a background process. Does the API not have shell access to run simple scripts using the basic UNIX tools to see if a process is already running, otherwise start it running as a background process? For example the tools, ps, grep, sed, kill. It has been a while since I looked at my Playbook via a shell, but I thought a lot of these tools were in the OS directories.

[peter9477]

Basically all child processes are killed off when the parent app exits, so we can't get in by the backdoor this way.

Caveat: I don't actually know of many who've experimented with such things, and it's conceivable there's some technique that could be used. If so, for now RIM might consider that a serious security flaw, however, and would patch it in the next release and release a supported API for this when they get around to it.

[robsteve]

The main limitation is probably the lack of root access for security reason, otherwise the developer could just put something in the init scripts to start their notification process.

[missing_K-W]

There seems to be quite the debate in this thread on what can, could, would or should be considered "multi tasking "...and how RIM expresses the term "true multi tasking ".

What we tend to forget is that QNX is a micro-kernel RTOS (real time operating system )...QNX by architecture was designed to "truly multi task"....Regardless of work load it will handle all loads up until hardware limitations in real time.....True multi tasking isn't a gimick or buzz word.....The use of "true multi tasking" is by design....Not by Slogan and branding.

QNX is a micro-kernel OS as opposed to iOS, Android and WP7 which are monolithic OS's...Radicaly different means of interacting with hardware.

As far as services being utilized on the platform due to the nature of the OS, there may be a much different utilization of the way services are handled which would incorporate QNX Real time nature. I don't think it's far to look at the way iOS, Android and WP7 handle services. From an engineering perspective RIM is upping the performance of a mobile device inorder to do MORE, where as the competition is "dumbing down".....then there's BB10 and unification between devices and having sdk's stream lined. RIM is currently in the same position Apple and Google were 5 years ago observing RIM. The tables have turned and RIM has the opportunity to play Apple and one up the competition....I trust all Api's will be made available, however RIM is taking their time to do it better

All IMHO