[katesbb]

If you want your app to run 24/7 in the background - only to then u need blackberry permission. Because it will affect battery life on your phone, they are being super super selective of this right now because it was a huge Os5/6/7 problem.

But aren't we already leaving apps running 24/7? I leave BeBuzz, third-party twitter apps, Weather, etc. open all the time. They apparently continue to run, update their Active Frame, provide notifications, etc., all without draining my battery or slowing down my system.

So why do they need to be split into UI and Process components?

It seems to me most problems would be solved if we users could just "Favorite" an app to:

1) Run at phone startup

2) Be immune to being closed by the OS if a 9th app is opened

And if you want to get fancy, manually closing a Favorite app might close the Active Frame, but keep running while marking the App icon somehow as Shao suggested.

I get why Android has to split an app into UIs and Processes, since I believe Android pauses/caches an app that moves into the background. But if the wow cool! thing about BB10 is how apps multitask and (can) keep running even when not in the foreground, isn't all this UI/Process splitting solving a problem that doesn't exist?

[MarsupilamiX]

Because as Kermed brought up along with his other points, how old are the other platforms? BlackBerry 10 is still an infant really, how quickly do you expect BlackBerry devs to move? They are already working their @sses off and that should be apparent to say the least :/

Comparing BlackBerry to say Apple or Android right now is comparing apples to oranges (not to be ironic).. One of the OS's is like 10 years old and has had ages to iron out all of the little nuances, while the other is a brand new platform that is improving by the day. Cut them some slack, everyone knew what they were getting themselves into being an early adopter of a new OS, you can't expect the kind of refinement that the competition currently has, it's as simple as that.

BlackBerry learned from Legacy what a mess background running apps really can be, so they are taking a more secure route this time around and I applaud them for that. They are learning from their mistakes and making the platform really built strong for the future, can ya blame them?

- Developer of 'Web Design Cheat Sheet' for BB10 (Posted via CB10)

They are slow.
Very slow. I was shocked that headless apps weren't in 10.0, to say the truth.

I get your point, but for me, right now, I just think that everything is taking too much time.

And no, I won't cut them some slack anymore. They got... 3 years to implement headless apps intelligently.
And the first thing I read about it, is that it's not as it should be.

Even if we dismiss Shao as a source, and apparently he is not the best to comment on the whole thing, even Kermed calls it a fancy beta version of the feature.

After 3 years of time, with the PlayBook as their public BB10 beta and having 2 role models to follow for headless apps, I am rather disappointed to see BlackBerry moving so slow.
I am not expecting refinement. I am expecting a basic feature to work correctly.

Posted via CB10

[dkonigs]

I get why Android has to split an app into UIs and Processes, since I believe Android pauses/caches an app that moves into the background. But if the wow cool! thing about BB10 is how apps multitask and (can) keep running even when not in the foreground, isn't all this UI/Process splitting solving a problem that doesn't exist?

Running all that UI code actually uses a lot of memory, and a process that runs without loading a UI will use far less system resources. Then you have the problem that users tend to instinctively close active frames, which will keep the associated apps from doing anything. Having correctly written background services sitting around (the real name for what's been branded as a "headless apps") is far nicer on the system than needing a dozen full UI apps with minimized active frames.

Yes, this requires developers to know what they're doing. Yes, this requires developers to understand various facets of software architecture. No, this isn't beginner friendly and I don't see this as a problem. In the whole "app craze" everyone has gotten caught up with, people keep forgetting that writing "smartphone apps" is actually still real software development that is often done by real software developers. Many real software developers didn't just learn how to code 6 months ago to get into that "app thing," but were coding long before (and will be coding long after) the current round of mobile platforms.

[dannyd86]

He doesn't really know what he's talking about.

Headless apps are very easy to work with. He gets confused because he isn't... how do I put this politely, someone well versed in coding practices

In reality they work very well and very robust as an extension of push. There a hundreds of ways to start incorporating headless as it is today. The SMS handler itself makes it a great resource.

Most of what he complained about is stuff that is good to have there. It protects you from malware and fly by night coders who don't understand push and headless from burning up your device.

It has a ways to go but it's on an infancy release - where it hasn't even been released yet - and it's exactly where we need it right now, exposed just enough to see if it will be abused. In headless apps im able to react to an SMS message and have the phone respond with GPS coordinates.

Or using SMS we can now build an email - to - SMS app on the phone. Or check actual device restarts and log it for reference. Or even use third party push messages to send notifications to users when an update is available by dropping a notification in the hub.

There is so much we can do,and it works very well. He just doesn't know what he's doing and people flock to him because he has a dozen timer and flashlight apps..

As for what you can do - right now my phone can be triggered to do amazing things over SMS messages for the last few days. It's limited only by the minds building for it. And it's only going to get better. Geolocation (turn on blue tooth devices automatically at a location),etc etc

Edit: FYI, just to be super clear for folks. You do not need to write to separate apps for headless. It has different entry points, kind like doors to a house. You don't want to use the same door for both because one has no UI and needs to assume settings. This is a good thing.

Posted via CB from my LE

Dude make me a security find my phone app that is activated by a SMS or email. I'll pay top dollar!

Posted via CB10

[BCITMike]

Dude make me a security find my phone app that is activated by a SMS or email. I'll pay top dollar!

Posted via CB10

Talk to this guy.
http://forums.crackberry.com/blackbe...ywhere-846146/

[mikeo007]

The current implementation is barely functional and looks like they just threw it into 10.2 to say "there, have your 'headless' apps!".

To be fair, I do think their implementation using triggers is the ONLY method that headless apps should be allowed to use on a mobile device. So they're on the right track there, but the number of triggers is laughably small. There are FOUR out of the thousands of events that happen on your phone which can trigger a headless app. They've given the usual response of "much more coming soon" but realistically, this feature was just not ready for primetime.

Just think about that type of apps people want to run headless. Look at what was most popular on the older BB platform. LED apps were extremely popular, and they are unfeasible with the current trigger setup. Then there were time-based apps like wallpaper changers, again not possible with the current implementation.

This feature has been tacked on as an afterthought, and it shows. Headless apps should have been an OS feature from the start, like so many others that were missing from legacy. The fact that they are even offering long-running headless capabilities to 3rd party apps also shows that they're still having trouble grasping the mobile device ecosystem and its users. People WILL blame Blackberry when they download an app that drains their battery. They will complain even if it's their own fault. So why even make it an option? You're just digging a deeper hole for yourself.

[dannyd86]

Nice!!

Posted via CB10

[KermEd]

Regarding apps running in the background

You don't realize this, but you have a very clear limit. If you start running more than 6 active frames - apps will die and close. That's expected as the phone runs out of resources and chooses to kill apps instead of the OS.

Active frames work well, you still have that option. But it is not the same thing as a headless app.

The long term goal of headless apps means being able to have 50+ apps trigger when you get a message without slowing down your phone or using extra battery. That's a much better long term goal.

Compare that to Android, where even 5 apps in the background impact performance.

Developers should not run apps 24/7 on your phone. I love event driven background apps. And as we are proving that headless apps work, they are going to add more events. There is no reason an app needs to run 24/7 if all the events were available, unless you want an active frame - which is different. Remember, an event could even be a timer event (i.e. Runs once every 30 minutes)

Posted via CB from my LE