[grumpyaeroguy]

OK, it's been a (brief) while now. I am NOT minimizing the development effort that goes into making an app headless what so ever.

I have done some software development myself in my day, so I appreciate that this is not simply "plug and play", necessarily.

All of this being said, what are the prospects of getting updates for some of the apps, such as be-buzz, HUB LED ++, and so forth, making them headless.

Any "buzz" out there? Is it imminent? Was the API suffucent to accomplish this? Is it on the horizon?

[StokApps]

You're right it's not that difficult to make an app headless, although certain types need to be approved by BlackBerry.

Have you written to the developers asking for this feature?

Personally I welcome feedback from users of my apps.

[grumpyaeroguy]

You're right it's not that difficult to make an app headless, although certain types need to be approved by BlackBerry.

Have you written to the developers asking for this feature?

Personally I welcome feedback from users of my apps.

No, as all of the apps I am referring to have the dialog box that pops up when you close them indicating that the app must remain open to function, and that as soon as the sdk is available that a headless update is "in the future".

Just curious how all of that is going.

[StokApps]

Okay well each of the developers should have a way to contact them, look on their App page in BBW for how and ping them asking how long.

[StokApps]

One thing I would mention is that developers will usually wait for an OS version to be widely available before releasing an update targeted at that version. Since headless needs 10.2 and 10.2 is not officially out yet they may be waiting for that reason.

[Shao128]

You're right it's not that difficult to make an app headless

That's completely inaccurate. It is VERY difficult to take an existing app such as BeBuzz, Hub++ and make it headless.

[StokApps]

That's completely inaccurate. It is VERY difficult to take an existing app such as BeBuzz, Hub++ and make it headless.

I wasn't trying to start an argument, I'm not the developer of these apps and so was not judging, there may well be extenuating circumstances that does indeed make it difficult for particular apps. As a developer and one who has written several example apps using the headless mechanism I found it fairly trivial to implement. This was all I meant.

Are you one of the developers?

[1magine]

Has any BB10/ Cascades (not port) 3rd party application gone headless yet? I don't think I've heard of one since the SDK went Gold.

It seems odd to me. Heck, even the weather application won't run headless, or push weather alerts to the Hub.

Maybe I'm expecting too much. Maybe BB's implementation of QNX is so flawed that some of the things we'd like to see happen, just won't.

[StokApps]

I can assure you that I know of lots of developers working on making their apps headless some already completed.
The fact still remains though that headless only works on 10.2 and 10.2 isn't out yet officially.

@1magine are you on 10.2?

[Morten]

All of this being said, what are the prospects of getting updates for some of the apps, such as be-buzz, HUB LED ++, and so forth, making them headless.

It's not quite easy task to do for most "already made" apps, and the developers also have to apply to BlackBerry for each app to allow them going headless. There are several criteria that has to be met. On top of that, the initial headless support in 10.2 does not support everything we hoped, missing quite a few triggers.

I can understand the hesitation of just letting it free - we should in no way get back into the same nonsense we had on BBOS, where all apps wanted to always run... draining resources and battery - and having no control over what is going on.

BlackBerry's approach by slowly crawling into opening up this, would also allow them for better tuning of the OS - so the user experience can be kept on a high level, and gradually opening up more and more along the road...

Good things to come

[Shao128]

I can assure you that I know of lots of developers working on making their apps headless some already completed.
The fact still remains though that headless only works on 10.2 and 10.2 isn't out yet officially.

@1magine are you on 10.2?

I assume you mean trigger based headless which is severely limiting due to only 4 triggers, which should just be called invocation, but anyways trigger based won't help apps like bebuzz and hub++ since triggered apps only run for 20 seconds. Long run headless don't even currently work, nor is there any documentation or samples on it that I've seen. Most of the apps people are concerned about require long run - not trigger based. Not to mention as far as I'm aware BB hasn't even started approving long run apps.

Im not sayning there aren't uses for trigger based, but by far the devs I know all need long run.

[1magine]

First - to question above: Yes. I am on 10.2.0.14XX on my ATT Z10 as my firm is beta testing the OS.

On my Verizon, Z10 no. But I will soon be.

Second - Shao, it sounds like all that BB has implemented is headless triggers. That may work for a weather alert being pushed to the Hub. But how would, if at all, that work for say the wallpaper changer or superbar? Unless starting the app or the device is considered a trigger?

And if not, then BB has not implemented headless apps at all.

EDIT:
Just noticed what you said about BeBuzz. So hub alerts (phone calls, SMS, E-mails) are not triggers? I guess that means a full screen caller ID app is not coming soon either.

[StokApps]

I assume you mean trigger based headless which is severely limiting due to only 4 triggers, which should just be called invocation, but anyways trigger based won't help apps like bebuzz and hub++ since triggered apps only run for 20 seconds. Long run headless don't even currently work, nor is there any documentation or samples on it that I've seen. Most of the apps people are concerned about require long run - not trigger based. Not to mention as far as I'm aware BB hasn't even started approving long run apps.

Im not sayning there aren't uses for trigger based, but by far the devs I know all need long run.

I can understand your position on not calling trigger based headless.

But there are samples, one here XandOs (trigger based)...

Sample apps - BlackBerry Native

[pkcable]

Shao is too modest to post this BUT he JUST did a blog on this topic....

The rise and fall of the headless apps | CrackBerry.com

[kbz1960]

So how long will it be before they are on par with other OSes? Soon isn't an answer either.

[howarmat]

So how long will it be before they are on par with other OSes? Soon isn't an answer either.

i leaning towards maybe never after reading the article...

[StokApps]

Shao is too modest to post this BUT he JUST did a blog on this topic....

The rise and fall of the headless apps | CrackBerry.com

Sneaky, that explains the aggressive response then. Nice article.

[ljfong]

For me, the part that says a headless app can only run for 20 seconds max, in other words, can only stay resident in the memory for 20 seconds max is senseless. So a headless app that runs as a server listening on requests has to be essentially unloaded from the memory, save its context to some durable storage, and reloaded periodically in 20-second increments. The set ups and tear downs is going to chew down battery fast. Also, using network socket to communicate in out of process style between UI task and non-UI task is silly. Typically UI and non-UI tasks run in process but on separate threads, not separate processes due to communication overhead that adds up very quickly if the non-UI running task needs to tell the UI task to update screen widgets in short bursts. I cannot think of any good technical justifications why it is the way it is.

BlackBerry certainly can do better than this.

[pfluger]

I think this is again a case of BlackBerry not executing well. We had been in contact in BlackBerry about headless support during BlackBerry Live this year and it was clear that they do not like having long running processes in the background. It actually even sounded to me like they would not offer that option at all. I guess this is why they made implementing this as tough as possible.

This would actually be fine. Most use cases for headless apps usually come down to some event driven model that doesn't really need to run constantly in the background. We even discussed the specific use case of BeBuzz with BlackBerry.

Apps like BeBuzz don't need to run constantly IF (and this is the important part) you offer developers all the triggers we need. For BeBuzz this would be things like new e-mail notifications, new SMS notifications etc.

In addition (and this was specifically for BeBuzz) we asked for an improvement of the LED functions to bring them back to where they were on BBOS. In BBOS we could set even a complex LED pattern once and have it flash automatically. With BB10 every step of an LED pattern has to be triggered manually by the app in the background.

I am 100% sure BlackBerry got enough feedback from other developers also to know what we, the developers, needed.

And now this is what we got. Two event triggers that nearly no one needs (we already had push before). Personally I think these two were either added because BlackBerry has some big partner who needs them or BlackBerry wanting to influence what kind of apps come to the platform by shaping their APIs accordingly.

And we got the option of continuously running processes in the background, that we now have to use as crutches to work around another half baked API. I have to admit the way they implemented it it is actually the 'correct' way to do background processes (only have a lean service running in the background without any UI overhead loaded) but it is a pain to implement if you have an existing code base. And unnecessary if they had given us a more complete API.

This in itself wouldn't even be such a big problem, we all love coding and solving the unsolvable challenges on BlackBerry, don't we? I just fear that in the current state of uncertainty many developers might not want or be able to take the risk to invest that much time and money to completely redo their apps from scratch to add headless support. The last thing BlackBerry should want at this time is making it harder to support their ecosystem.

Deep integration into the OS (including background tasks) was one of the main differentiators of BBOS, and with BB10 they are crippling it to a me-too implementation that you get on any other platform these days.

Enough ranting for today, back to work :-)

[AfterHoursWelds]

It'd be nice to be able to control where the apps end up while opened.

If we could push the battery monitor apps and other ones that don't need to be seen to the second page of our home screen everything would be great.

I rarely have more than 4 apps open, it just gets too messy.

If blackberry added the ability to control the home screen then developers wouldn't have to worry about jumping through hoops to hid their apps.

Posted via CB10

[grumpyaeroguy]

I think this is again a case of BlackBerry not executing well. We had been in contact in BlackBerry about headless support during BlackBerry Live this year and it was clear that they do not like having long running processes in the background. It actually even sounded to me like they would not offer that option at all. I guess this is why they made implementing this as tough as possible.

This would actually be fine. Most use cases for headless apps usually come down to some event driven model that doesn't really need to run constantly in the background. We even discussed the specific use case of BeBuzz with BlackBerry.

Apps like BeBuzz don't need to run constantly IF (and this is the important part) you offer developers all the triggers we need. For BeBuzz this would be things like new e-mail notifications, new SMS notifications etc.

In addition (and this was specifically for BeBuzz) we asked for an improvement of the LED functions to bring them back to where they were on BBOS. In BBOS we could set even a complex LED pattern once and have it flash automatically. With BB10 every step of an LED pattern has to be triggered manually by the app in the background.

I am 100% sure BlackBerry got enough feedback from other developers also to know what we, the developers, needed.

And now this is what we got. Two event triggers that nearly no one needs (we already had push before). Personally I think these two were either added because BlackBerry has some big partner who needs them or BlackBerry wanting to influence what kind of apps come to the platform by shaping their APIs accordingly.

And we got the option of continuously running processes in the background, that we now have to use as crutches to work around another half baked API. I have to admit the way they implemented it it is actually the 'correct' way to do background processes (only have a lean service running in the background without any UI overhead loaded) but it is a pain to implement if you have an existing code base. And unnecessary if they had given us a more complete API.

This in itself wouldn't even be such a big problem, we all love coding and solving the unsolvable challenges on BlackBerry, don't we? I just fear that in the current state of uncertainty many developers might not want or be able to take the risk to invest that much time and money to completely redo their apps from scratch to add headless support. The last thing BlackBerry should want at this time is making it harder to support their ecosystem.

Deep integration into the OS (including background tasks) was one of the main differentiatiors of BBOS, and with BB10 they are crippling it to a me-too implementation that you get on any other platform these days.

Enough ranting for today, back to work :-)

Wow, thank you so much for taking the time to explain. again, I was trying hard in my OP NOT to imply that this is trivial, as I have some OOP experience.

Well, that explains it. Too Bad. I think I may have all of the bellshare apps, if not most of them. In my opinion, they represent a very high standard and, IMO, are "top of the mark".

I very much look forward to the day you have the tools and ability via a "good" SDK and APIs to maximize already great apps via headless running.

Thanks you for responding. (vielen Dank)

[ljfong]

Nice to see a response from BellShare, love the apps, BlackBerry should make it easy for developers to harness their creativity on the platform. Microsoft stack may not be the hippest platform but they do know how to treat the developers well as Ballmer chanted "Developer! Developer! Developer!" getting sweaty on the stage.

Posted via CB10

[grumpyaeroguy]

Nice to see a response from BellShare, love the apps, BlackBerry should make it easy for developers to harness their creativity on the platform. Microsoft stack may not be the hippest platform but they do know how to treat the developers well as Ballmer chanted "Developer! Developer! Developer!" getting sweaty on the stage.

Posted via CB10

well, gotta agree there. I teach Visual Studio.Net at a local community college, and the support I receive from MS for future developers, and those learning, is tops. Gotta hand it to them there. I have access to very expensive developer tools and software just because I teach... to the point that it makes me feel guilty sometimes.

their response: "don't feel that way, your teaching our companies future"... hard to argue with that logic.

Helllllllo Canada....... anyone listening/learning??????

[mikeo007]

Some great replies. I made the following post (modified slightly) in another thread, but it will make for better discussion here:

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.

I was disturbed when they started talking about always-on 3rd party apps. I was relieved when they started to talk about system triggers. Then I facepalmed when I saw the actual implementation.

My idea of how headless apps SHOULD have been implemented (again, from the start, not as an afterthought) would be to allow apps to register for at least hundreds of system triggers. Add a control panel pane that shows users all triggers that have 3rd party apps registered for them. Allow the user to choose which app if there are multiple ones registered, or allow them to disable the trigger altogether. By implementing this from the start, they could have avoided the current (or future) situation where developers will need to perform a major overhaul to support headless triggers.

It's just another example of a very poor lack of foresight IMO, which has plagued RIM/BB for years now.

Any iOS devs around who have tried some of the new headless features that Apple recently added? JIT updates for example, or push invocation? They are ridiculously easy to implement into existing applications because they already had the groundwork in place.

[pfluger]

(...)
And now this is what we got. Two event triggers that nearly no one needs (we already had push before). Personally I think these two were either added because BlackBerry has some big partner who needs them or BlackBerry wanting to influence what kind of apps come to the platform by shaping their APIs accordingly.
(...)

Inside BlackBerry Developers Blog
Headless Apps Explained �BlackBerry Developer Blog

(...)
We also realized that we needed to be cautious and limit the first set of triggers as we continue to monitor the impact of headless applications on our operating system. The triggers chosen were ones where we had concrete use cases with key partners and carriers to put the system through its paces.
(...)

q.e.d.