[compgen25]

Let me start off by saying I have debating writing this due to the fact that this is a hot debated topic on mobile OS's and I know people will give me reasons against what I say below. However I wanted to write the differences on how QNX is better than the "Others" implementation of Multi-Tasking. Also just as a note I'm not expert just a free-lance developer that works in an enterprise IT world. Also of another note this is not my opinion I am stating here these are facts. You can look them up anywhere.

To begin I want to give the limitations:

QNX:
None that I am aware of. As long as the device is in Showcase Mode all apps run in the background.

iOS:
All apps get 5 seconds after hitting the Home button to finish tasks before being suspended. An app can request longer if it has a long running process. However it only gets 10 minutes before iOS forcibly suspends the application. If a larger app is then launched and needs a lot of memory suspended apps will be closed. By default only the following 5 kind of apps can run indefinately in the background:
1. Apps that play audio
2. Apps that track location via GPS
3. Apps that listen for VOIP (such as Skype)
4. Newsstand Apps that download new content
5. Apps using an external accessory that is getting updates from it (such as an external GPS antenna)

NOTE: Suspended means resident in memory still so that when you open it again it is where you left off.
Closed apps are no longer in memory and will launch fresh when opened again.

Now on to the reasoning of my title. I will look at it from both the Consumer and Enterprise point of views.

Consumer:
From a consumer point of view apps that are backgrounded and not multi-tasking probably isn't a huge deal. You open a web page and background it. When you come back it just finishes or refreshes. No big deal here. Being able to watch a video and do other things at the same time is probably not a big deal for consumers either. So from a consumer stand point the iOS implementation of multi-tasking is just fine and not a big deal. It works and serves their purpose.

Enterprise:
Now lets look at this from an enterprise point of view.

Lets say I have an app in the business world such as Remedy. (For those non-IT people this is an application that is used for client problems to log tickets). So let's say I have a Remedy client on my phone/tablet that constantly receives updates from a web service. On the QNX platform if the client is backgrounded and a new ticket comes in the client will receive it and it enabled I will get notified of the new ticket. On iOS because it does not fit into the list of 5 apps allowed to remain functional while backgrounded I will not get notified until I launch the app again. In the enterprise world this is bad. We need to be notified immediately of new tickets. This is just 1 application as an example but in the enterprise world I would bet a lot of mobile applications will utilize a web service to get its data which means in iOS it wouldn't get it's updates while backgrounded. Again this can be a major problem as in the enterprise world data is constantly changing and people need notified when changes are made.


To sum things up:
To a consumer I can see how multi-tasking implemented in the iOS fashion is not an issue. But in the enterprise world it is a huge problem.

NOTE****** THIS IS MY OPINION BELOW
In my opinion iPads/iPhones are making it into businesses because executives like those devices personally so they are requesting to be able to use them in the business. If they are allowed why stop everyone else. If it were looked at from a productivity standpoint however I don't think these devices would make it into the enterprise world because in their current implementation of the OS they just can't do the work that a QNX device can do now. Now this may change in the future but as of right now from a productivity standpoint QNX has a much better implementation of Multi-tasking. You can't dispute facts here people.

Now I know I am going to get other points of view which is OK and I expect that however facts are facts and you can't dispute that QNX has a better implementation of Multi-tasking when you look at it from an Enterprise point of view.

[deebo550]

In my opinion iPads/iPhones are making it into businesses because executives like those devices personally so they are requesting to be able to use them in the business. If they are allowed why stop everyone else.

This is what happened here at my work. We used to be all blackberry phones and then the right people wanted iphones so then everyone got them instead.

[compgen25]

This is what happened here at my work. We used to be all blackberry phones and then the right people wanted iphones so then everyone got them instead.

Yea my work is starting to implement bring your own phone and our IT is going to have to support every phone device out there. From a supportability standpoint that is a nightmare. From what I have read online though companies that have tried to implement bring your own phone end up going back to Blackberries anyway due to the ease of management and supportabiltiy. I mean who wants to support over 100 different phone models??? That is just absurd to ask your IT department to do that. I think in time companies will realize the the ease of support and security they get with Blackberry and move back.

[app_Developer]

For the Remedy case, it's not true that the user can't be notified of a new/updated ticket on iOS. The user can be notified via push notifications. Haven't you ever played a game on an iPhone or iPad and been notified that it's your turn? Or notified that someone mentioned you on twitter or sent you a message in LinkedIn? That's how these apps work.

Instead of having n different apps on the device polling for results at n different frequencies, the push notification service allows the OS to turn the radios off for a better percentage of time.

If it's really, really an issue and you just can't find a way to push notifications rather than poll for them, you could just declare your enterprise app as a VoIP app and then you do get full background cycles. Enterprise apps don't have to be approved by Apple, so in reality you can set whatever background mode you want.

But in my experience, the push notifications work better anyway, versus having thousands of devices polling all day long. And you can use the same strategy on Android, which Google also recommends for efficiency on both ends.

[compgen25]

For the Remedy case, it's not true that the user can't be notified of a new/updated ticket on iOS. The user can be notified via push notifications.

Instead of having n different apps on the device polling for results at n different frequencies, the push notification service allows the OS to turn the radios off for a better percentage of time.

If it's really, really an issue and you just can't find a way to push notifications rather than poll for them, you could just declare your enterprise app as a VoIP app and then you do get full background cycles. Enterprise apps don't have to be approved by Apple, so in reality you can set whatever background mode you want.

But in my experience, the push notifications work better anyway, versus having thousands of devices polling all day long. And you can use the same strategy on Android, which Google also recommends for efficiency on both ends.

I completely understand your point but my point it that unless the developer follows different standards for different OS's that this method is a pain to manage. I don't want to have to write code for each individual OS just because of limitations that I have to overcome. I would rather have 1 code base that works for everything. I shouldn't have to work around it because some Manufacturer says I should. Multi-tasking should be just that and work regardless for everything not just what "they" want it to work for. Now I understand these are mobile devices and you have to have limitations due to data usage and power usage however the iOS limitations go way beyond that. For major application that already exist in the enterprise world they more than likely already have a web service that can be polled for data. Writing a client for that is easy. However to use push notifications would require a re-write of how the web service works and enterprise apps may not want to do that initially. Over time that may happen but until that does you write the client for what exists. Taken that I shouldn't have to "lie" about what my app is or does just so I can use background multi-tasking. iOS forces developers to get more creative than they need to be. Again my points are for enterprise and not consumer.

[app_Developer]

I mean who wants to support over 100 different phone models??? That is just absurd to ask your IT department to do that.

You might consider a middle ground here. Have a short list of approved devices and use Fusion or Good to manage them. Why must it be one extreme (thou shalt use BB) or the other (free love)?

[erodenero]

compgen,
very informed post, i applaud you for being so detail oriented.
let the enterprise know what they are missing...

[compgen25]

You might consider a middle ground here. Have a short list of approved devices and use Fusion or Good to manage them. Why must it be one extreme (thou shalt use BB) or the other (free love)?

I am thinking of it from a security standpoint mainly. We already know the security issues on Android. May not be many on iPhone but Blackberries is very few if any. I know that using BB Fusion you can manage all of them which is great but just like a workstation support team doesn't want to support 100 different pc models I wouldn't want to support all those phone models either. Just my opinion on that. Using 1 manufacturer of a phone makes the supportability and reliability better again IMO.

[app_Developer]

I completely understand your point but my point it that unless the developer follows different standards for different OS's that this method is a pain to manage. I don't want to have to write code for each individual OS just because of limitations that I have to overcome. I would rather have 1 code base that works for everything. I shouldn't have to work around it because some Manufacturer says I should. Multi-tasking should be just that and work regardless for everything not just what "they" want it to work for. Now I understand these are mobile devices and you have to have limitations due to data usage and power usage however the iOS limitations go way beyond that. For major application that already exist in the enterprise world they more than likely already have a web service that can be polled for data. Writing a client for that is easy. However to use push notifications would require a re-write of how the web service works and enterprise apps may not want to do that initially. Over time that may happen but until that does you write the client for what exists. Taken that I shouldn't have to "lie" about what my app is or does just so I can use background multi-tasking. iOS forces developers to get more creative than they need to be. Again my points are for enterprise and not consumer.

Huh?

Every cross platform developer kit I've used supports push notifications. We do that now with Android and iOS apps off the same push service.

And if you're writing pure native code, then you don't really have one codebase, do you?

Again, if your enterprise app wants full background cycles on iOS, you just check that box. It's just one checkbox, if you really want to do it that way in your enterprise. Apple doesnt prevent this. But it's still very poor practice on *any* battery powered device. Why do you think BES is so efficient? Because the last hop to the device is a push.

If a developer wrote me a Remedy app that pinged the server all day long, I'd fire him or make him go work the help desk for a while.

[compgen25]

Huh?

Every cross platform developer kit I've used supports push notifications. We do that now with Android and iOS apps off the same push service.

And if you're writing pure native code, then you don't really have one codebase, do you?

Again, if your enterprise app wants full background cycles on iOS, you just check that box. It's just one checkbox, if you really want to do it that way in your enterprise. Apple doesnt prevent this.

I mispoke on that part.. yes you only need 1 codebase unless pure native. However to utilize push notifications the backend end must support it which was my point in the previous post that the backend app would have to include support for it which I would bet most do not now.

[compgen25]

Anyway to avoid getting off track this post wasn't for debating how to get around limitations or how applications work. I wrote this to just inform others that there are limitations and that most consumers don't mind them but the enterprise world will.

[app_Developer]

I mispoke on that part.. yes you only need 1 codebase unless pure native. However to utilize push notifications the backend end must support it which was my point in the previous post that the backend app would have to include support for it which I would bet most do not now.

Well, then you do exactly what Blackberry did when they wrote BES: you write services that are better suited for mobile use. Otherwise, it's "hey my battery is drained. Oops, that's right I forgot to kill the remedy app again. Damn."

The engineering teams at Microsoft, Palm, Nokia, Google and Apple all independently found that "free for all" multitasking doesn't work well on mobile devices. That's why WP7, iOS, WebOS and Android all have models to restrict and control background tasks. Believe it or not, these teams kind of knew what they were doing.

Anyone designing or thinking about enterprise apps should be aware of what all five of these companies found.

And they should be aware that even RIM prefers push for efficiency, which is how BES works, and why previous BB Phones were so battery and network efficient (hint: they don't poll)

[compgen25]

Well, then you do exactly what Blackberry did when they wrote BES: you write services that are better suited for mobile use. Otherwise, it's "hey my battery is drained. Oops, that's right I forgot to kill the remedy app again. Damn."

The engineering teams at Microsoft, Palm, Nokia, Google and Apple all independently found that "free for all" multitasking doesn't work well on mobile devices. That's why WP7, iOS, WebOS and Android all have models to restrict and control background tasks. Believe it or not, these teams kind of knew what they were doing.

Anyone designing or thinking about enterprise apps should be aware of what all five of these companies found.

And they should be aware that even RIM prefers push for efficiency, which is how BES works, and why previous BB Phones were so battery and network efficient (hint: they don't poll)

We are getting away from my point. I used "polling" as just 1 example of what was limited. There are other things that a mobile app might want to do that gets limited. Again yes you could get around that by marking your app as VOIP or something else but that just bypasses my point. My point that I was making is that apps become limited on what you are allowed to do on iOS compared to what you can do on QNX. You may see the need for doing this or a way to get around it and that is fine. But again my point is that you are limited and that is not always the choice people want.

This is something that has been debated probably a million times and you will see it all over the internet. I was just using iOS as an example because they are the most limiting not just on what can background but everything. They like control and again that is fine but not everyone wants that. But that is a whole nother topic that I don't want to discuss here.


Let's try to keep on point here of how there are limitations. I understand that not everyone thinks limits are good or bad. And that QNX is not just on mobile devices hence the reason for "free for all" multi-tasking...

[parps]

wouldn't using notification services for the Remedy app be better than leaving the app open the whole time? iOS has notifications right??

[compgen25]

wouldn't using notification services for the Remedy app be better than leaving the app open the whole time? iOS has notifications right??

Yes you could and yes that would work. My point is that this was just 1 example not the rule here.

[Innovatology]

My main concern here is that Apple have decided for us what use cases require a background service. And only with those use cases can you continue to run in the background. This stifles innovation.

A background process should not have to have a visible UI at all times. An example might be a reminder ("time to take your pills"), or a service that tracks the PlayBook if it is stolen, or an sync task that keeps your documents in sync or an indexing service that periodically scans your documents for search terms. If and when the service decides it's time to notify the user or pop open an app, it should be able to do so.

The thing is: until such an app is conceived, we don't know and nor does Apple/RIM/Google. I may have a fabulous idea for a groudbreaking app or game, but it will never happen because it doesn't follow pre-conceived guidelines. Innovation thwarted.

There should be some technical but no functional restrictions on these features.

Currently the PlayBook OS also doesn't support UI-less background services. The app can continue to run IF the user is in Showcase mode and IF the user leaves the app running. In some cases it is relevant to continue to run in the background even if the user closes the app. Or perhaps a background service that starts at boot time is required (after permission is granted, of course, and only as long as the service behaves). Lets hope such an API will be opened up soon.

[rrrebo]

I'd just like to point out that BMC Remedy/ITSM/ARS uses email notifications, so you wouldn't need the app to be open to be notified of a new incident. You'd just need to have your email notifications configured correctly. This is, of course, all dependent on your company's implementation of BMC Remedy.

As for PlayBook notifications, currently only native apps have access to launch from the notification icon. 3rd-party apps would need to be open to receive notifications, anyway. This may be changing soon. Notifications will be evolving, and they've even removed some of them from OS 2 in preparation for these changes.

[compgen25]

My main concern here is that Apple have decided for us what use cases require a background service. And only with those use cases can you continue to run in the background. This stifles innovation.

A background process should not have to have a visible UI at all times. An example might be a reminder ("time to take your pills"), or a service that tracks the PlayBook if it is stolen, or an sync task that keeps your documents in sync or an indexing service that periodically scans your documents for search terms. If and when the service decides it's time to notify the user or pop open an app, it should be able to do so.

The thing is: until such an app is conceived, we don't know and nor does Apple/RIM/Google. I may have a fabulous idea for a groudbreaking app or game, but it will never happen because it doesn't follow pre-conceived guidelines. Innovation thwarted.

There should be some technical but no functional restrictions on these features.

Currently the PlayBook OS also doesn't support UI-less background services. The app can continue to run IF the user is in Showcase mode and IF the user leaves the app running. In some cases it is relevant to continue to run in the background even if the user closes the app. Or perhaps a background service that starts at boot time is required (after permission is granted, of course, and only as long as the service behaves). Lets hope such an API will be opened up soon.

I didn't say it this way but this is exactly what I mean. I don't like to be told what I can and can't do with the device. Let me decide that.

[apengue1]

So anyway, cold hard facts also cease to quiet down the masses. The OP gave ONE example of a situation, and he is right. Multi-tasking is better on qnx and that is also fact. The thing is that some may have found work-arounds for the remedy app, but there are just so many examples one could choose to make. Truth is that its fact that qnx is a superior multitasker and that your argument will LOSE at some point, because its just inferior at multitasking, so quit whining

[missing_K-W]

Technical analysis aside....All one has to do is pick a PB up and see for there own eyes how PB's multi-tasking is much more fluid and highly advanced. Eyes and user experience don't lie.

Most who tend to debate this issue on this forum are those who frequent the forums, and have an Android or iOS device and have never used a PB or have just played with one in the store for a few mins.

Hands down...PB's utilization is much more efficient, effective and by design(OS architecture) more capable and advanced.....

As more API's and QNX's transparent distriputed multiprocessing come online for the QNX BB platform, RIM will become light years ahead of the competition in terms of multitasking...including Microsoft....

QNX is a micro-kernel...only utilizing what is required(NEEDED) resource wise on the hardware end....Monolithic kernels are lumping to many unnecessary resources together and not utilizing the hardware remotely close to being efficient relative to QNX.

[kennyliu]

One limitation of PBOS in its current state is that it does NOT allow third-party apps to run services in the background.

[apengue1]

[sf49ers]

another classic example I can think of is OS OTA update, I can continue doing what I am doing while the system updates it's firmware in the back ground.

the non-ui background services(third party) is a mute point because it will be addressed in either OS 2.0 or the BB10. The QNX as a whole is a multi-tasking gem.

[missing_K-W]

another classic example I can think of is OS OTA update, I can continue doing what I am doing while the system updates it's firmware in the back ground.

the non-ui background services(third party) is a mute point because it will be addressed in either OS 2.0 or the BB10. The QNX as a whole is a multi-tasking gem.

"True multi-tasking" is founded at the architecture of the OS in QNX

QNX "true multi-tasking" based on OS design/architecture allows for an X-factor....an abundance of variables to deploying

iOS,Android& WP7 based on OS architecture renders the X-factor Non applicable. There are architectural restraints.

I so agree that the service API's are a mute point as they will come...Most likely ties into the greater BB10 picture.

[sgt_snacks-64]

I was going to go off on a rant about BYOD, for some reason (on this thread :\)

But no, I love the Multi-tasking on QNX/Playbook, and anyone I show is always "WOW"'ed