Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Web and WebWorks Development

Reply
Developer
Posts: 161
Registered: ‎02-08-2012
My Device: PlayBook
My Carrier: None yet

problems / bugs with webkitNotifications API

I don't know where we're supposed to officially report things like this, so I'm just going to start here. If anyone knows of answers or workarounds for these problems, please let me know. The webkitNotifications API could be great. Unfortunately, at the moment, it's pretty poor. - Every time your app restarts, you must call webkitNotifications.requestPermission() and the user must authorize the app again - it does not remember the authorization. - When closing the app, notifications stay hanging around, however will immediately close the moment you attempt to display them (the spec says they should hang around until closed - a good alternative if that's not possible would be force closing all the closed apps notifications when the app is closed, so that they aren't briefly visible on the notification bar) - The notification "onclick" event is fired when clicking on the 'x" button to close it - The notification "onclose", "ondisplay" and apparently "onerror" events are never fired - The "iconUrl" parameter for the createNotification call is apparently ignored Additionally, there is no alert sound played when calling the HTML alert functions, so the only indicator is this weird little tiny red outline on the upper left hand corner of the device. Of course, I suppose one could play their own sounds here, but it'd be nice to be able to actually supply one directly to the API. My guess is we can probably build our own HTMLNotification and use that to significantly improve on some of these things. It'd be really nice to have it in the OS itself though. Further suggestions to enhance the usability of notifications in the OS as a whole: Do not play a notification sound for -every email received-. I deleted all my email accounts from the device after putting up with that for about 5 minutes. Move the close button to the left hand side of the notification, so that you can get rid of it with only one hand on the device When opening the OS status bar using the upper-left-hand-corner-swipe-in, if there are new notifications, open them automatically. It shouldn't take 2 motions to get to the notifications, and then have an additional tap for each one to get rid of it. On that note, add a button to clear all seen notifications. One thumb slide, glance, tap clear, all the ones that were visible are gone. Remove the 8-notification limit. I had been looking qutie forward to getting the PlayBook in my hands, to see what the people who took mobile email and messaging from the sad state it was in a decade ago to a whole new artform had been up to.. but unfortunately, the notification system and email apps are in a pretty sorry state.
Developer
Posts: 817
Registered: ‎11-19-2009
My Device: Z10, Q10, 9900, 9790, PlayBook,
My Carrier: T-Mobile UK, Three, O2, Orange, Sunrise, Swisscom

Re: problems / bugs with webkitNotifications API

I think it would be great if you could open a few feature requests or bug reports in the tracker. It will help get RIM's devs attention.

--
Olivier - interfaSys ltd
Developing for BlackBerry 10 devices using the Sencha Touch framework.
Developer
Posts: 161
Registered: ‎02-08-2012
My Device: PlayBook
My Carrier: None yet

Re: problems / bugs with webkitNotifications API

ffs, when I wrote that it was nicely formatted. what the hell happened? let me try again.

so,w here is this tracker?
Developer
Posts: 161
Registered: ‎02-08-2012
My Device: PlayBook
My Carrier: None yet

Re: problems / bugs with webkitNotifications API

[ Edited ]

Hopefully this is much more readable:

 

I don't know where we're supposed to officially report things like this, so I'm just going to start here.

 

If anyone knows of answers or workarounds for these problems, please let me know.

 

The webkitNotifications API could be great. Unfortunately, at the moment, it's pretty poor.

 

- Every time your app restarts, you must call webkitNotifications.requestPermission() and the user must authorize the app again - it does not remember the authorization.

 

- When closing the app, notifications stay hanging around, however will immediately close the moment you attempt to display them (the spec says they should hang around until closed - a good alternative if that's not possible would be force closing all the closed apps notifications when the app is closed, so that they aren't briefly visible on the notification bar)

 

- The notification "onclick" event is fired when clicking on the 'x" button to close it

 

- The notification "onclose", "ondisplay" and apparently "onerror" events are never fired

 

- The "iconUrl" parameter for the createNotification call is apparently ignored Additionally, there is no alert sound played when calling the HTML alert functions, so the only indicator is this weird little tiny red outline on the upper left hand corner of the device. Of course, I suppose one could play their own sounds here, but it'd be nice to be able to actually supply one directly to the API.

 

My guess is we can probably build our own HTMLNotification and use that to significantly improve on some of these things. It'd be really nice to have it in the OS itself though.

 

Further suggestions to enhance the usability of notifications in the OS as a whole:

 

Do not play a notification sound for -every email received-. I deleted all my email accounts from the device after putting up with that for about 5 minutes.

 

Move the close button to the left hand side of the notification, so that you can get rid of it with only one hand on the device

 

When opening the OS status bar using the upper-left-hand-corner-swipe-in, if there are new notifications, open them automatically. It shouldn't take 2 motions to get to the notifications, and then have an additional tap for each one to get rid of it.

 

On that note, add a button to clear all seen notifications. One thumb slide, glance, tap clear, all the ones that were visible are gone.

 

Remove the 8-notification limit.

 

I had been looking qutie forward to getting the PlayBook in my hands, to see what the people who took mobile email and messaging from the sad state it was in a decade ago to a whole new artform had been up to.. but unfortunately, the notification system and email apps are in a pretty sorry state.

Developer
Posts: 817
Registered: ‎11-19-2009
My Device: Z10, Q10, 9900, 9790, PlayBook,
My Carrier: T-Mobile UK, Three, O2, Orange, Sunrise, Swisscom

Re: problems / bugs with webkitNotifications API

You can find it from the BlackBerry Jam dashboard. Here is a direct link:

https://www.blackberry.com/jira/secure/Dashboard.jspa

--
Olivier - interfaSys ltd
Developing for BlackBerry 10 devices using the Sencha Touch framework.
Developer
Posts: 161
Registered: ‎02-08-2012
My Device: PlayBook
My Carrier: None yet

Re: problems / bugs with webkitNotifications API

[ Edited ]

Seriously? More junk to register for and sign into? How frustrating.

 

The Developer Zone, the Developer Portal, the Developer Forums, the Developer something else that I also had to sign up for .. anyone ever hear of "single sign-on"?

 

 

Developer
Posts: 161
Registered: ‎02-08-2012
My Device: PlayBook
My Carrier: None yet

Re: problems / bugs with webkitNotifications API

Also jsut discovered that createHTMLNotification does not work, it is merely an alias for createNotification(undefined, msg)
Developer
Posts: 137
Registered: ‎10-26-2010
My Device: Bold 9900 + PlayBook
My Carrier: Rogers

Re: problems / bugs with webkitNotifications API

[ Edited ]

Many of these issues are not WebWorks specific, but rather reflect the overall state of the PlayBook notification system. I'm guessing from what you said you're not a BBOS user, but it's how to do a notification system. Apps register notification types with a default sounds/volume/vibrate length/repeat/etc. You can even set different behaviour in case vs out of case. Users then have multiple notification profiles they can switch between, and for each profile you can fully customize each notification type. For example I've got separate vibrate, phone only, silent, normal profiles.

I am pretty sure the PlayBook is a case of not implemented yet. Rather than doing things like removing the sound for every email (which most BlackBerry users expect, it's always been the default), they just need to implement a proper notification system. Given how good RIM's current system is I'm sure this is on the roadmap somewhere.

--------
Taylor Byrnes
Developer
Posts: 161
Registered: ‎02-08-2012
My Device: PlayBook
My Carrier: None yet

Re: problems / bugs with webkitNotifications API

... and the bug tracker has no functions for dealing with PlayBook OS. What a mess.
Developer
Posts: 161
Registered: ‎02-08-2012
My Device: PlayBook
My Carrier: None yet

Re: problems / bugs with webkitNotifications API

Yeah, the first 5 points were about the WebWorks implementation specifically, the rest were about the rest of the system.

If I didn't receive literally hundreds of emails in a day across my accounts, I'd be OK with that. I'd even expect it to alert every time it received emails in a single transmission. I don't expect an alert for every message received, especially in an initial download. After 5 minutes, I couldn't take it, and deleted the accounts. During that 5 minutes, my experience with the new email program was "it's really fast, has several great options that are apparently not actually implemented yet, but overall is possibly the worst experience I've had with email in a decade".