wait maybe a more simple way to think about it - is that Hub can collect notifications sent to it by system, hub cannot collect notifications directly from apps.
This runs contrary to the behavior privberry is reporting. He states several times that when he turns off system notifications, the hub still registers a spark. If what you are saying is true how is the hub able to display a spark when the system notifications are off? It must somehow know the app received a message, and your saying the app itself can't tell it, and if the system didn't send it then how? Magic?
If this is an OS issue as opposed to a Hub issue, it will probably won't be fixed until Marshmallow and then you have to hope your carrier rolls that out.
If this is an OS issue as opposed to a Hub issue, it will probably won't be fixed until Marshmallow and then you have to hope your carrier rolls that out.
Posted via CB10
Well we know what 6.0 says about app permissions and notifications - read that, the easiest (?) way they would have to do it is to replace the stock notification system (which is actually allowed) completely.
It seems like it would be an easy fix. Just intercept all notifications and fork them to both the stock notification system and also to the HUB. Then, have the ability to selectively enable or disable either fork.
This runs contrary to the behavior privberry is reporting. He states several times that when he turns off system notifications, the hub still registers a spark. If what you are saying is true how is the hub able to display a spark when the system notifications are off? It must somehow know the app received a message, and your saying the app itself can't tell it, and if the system didn't send it then how? Magic?
Posted via CB10
I think what privberry is saying about the spark would be the bb notification star from the red dot
It seems like it would be an easy fix. Just intercept all notifications and fork them to both the stock notification system and also to the HUB. Then, have the ability to selectively enable or disable either fork.
Posted via CB10
You could be right - Playing around with snowball, the answer seems to be to turn Hub into a notification system and have a separate email app. That would allow for notification access of the sort you are talking about (although snowball needs you to give it access to a gmail account so I'm not sure where that fits in).
Just update all of the Apps after first set up and a lot of these odd problems will disappear. It has been confirmed that all Blackberry apps have out of the box updates.
Well I think it's not finished in that they should be able to add more services but I don't think any of that will change that its an app not baked into the OS. Remember as well, BBRY need to account for the fact that a sizable amount of people will either never use Hub or just use it for email - so there is the resource question.
I agree that it would be very hard to have a hub that works under the skin of the OS, especially since Google is making efforts to lock down the OS with each upgrade.
This runs contrary to the behavior privberry is reporting. He states several times that when he turns off system notifications, the hub still registers a spark. If what you are saying is true how is the hub able to display a spark when the system notifications are off? It must somehow know the app received a message, and your saying the app itself can't tell it, and if the system didn't send it then how? Magic?
Posted via CB10
Good point. May be some of the android specialists can explain better since they know how Google's agreement work.
If this proves to be true and the issue persists this would definitely be a deal-breaker for me. I use the hub to be quick and efficient in message interchange, so if I have to do everything twice due redundant message reception, there's no point in it.