Notifications (not sure if bug or not!)

[Kevin]

I am seeing more and more complaints about notifications in my app causing the phone to vibrate and/or play sounds every time I show or update a notification in my app. This only happens on certain devices though!

The only devices I know of this to happen on are a Droid Charge and LG Marquee. I have only been in 2-way contact with one person and after sending him a test app using different options found in Barx's awesome Custom Custom Notification library (now known as Advanced Notification Library™), he told me that it made no difference! The thing is, this person also told me that a competing app which essentially does the same thing with notifications does NOT do this on his phone. I can only conclude that something is different about the way B4A does notifications.

Erel, if you haven't already seen these earlier posts and done this already, would it be possible to look into the way B4A handles notifications (particularly sounds and vibrations) and see if something could be wrong or could be done differently there?

I imagine this has got to be an extremely annoying experience for people using my app on phones that are affected by this. Honestly, if it were doing that on my phone I'd uninstall the app within minutes.


For more background see these:
http://www.b4x.com/forum/basic4android-updates-questions/17632-customers-phone-vibrates-no-reason-2.html#post102546

http://www.b4x.com/forum/additional-libraries-classes-official-updates/16950-custom-notification-library-barx-6.html#post104858

UPDATED THOUGHT:
Is it possible that certain properties for the object (pertaining to sound & vibration) need to be set in a certain order in order for them to take effect correctly? Just grasping at straws here.

 

[barx]

I don't think anything is done differently. One thing that does happpen both in the b4a object and both my libs is that when the object is initialized a set of 'default' options are set. As part of this sound and vibration are on. But, vibration is turned off with your code before any notification is issued. It is all done basically by setting a line of flags to 0 or 1. Each bit in the line for a different option. Other than that I cannot think of anything. If you like I could create you a version of lib that doesn't do this.

There are a couple of numbers used within the b4a object which I don't understand their use, and so just copied them. Can't see them being the issue but if erel could explain their use it would clear it up either way.

Sent from my HTC Desire Z

 

[Kevin]

Barx: I've posted in the library thread.

Erel: Any thoughts on this?

 

[Erel]

Basic4android uses the standard notification system. As barx wrote, by default all the the flags are set. If you are able to reproduce it then we will be able to test different kinds of combinations and see if it changes the behavior.

 

[Kevin]

I'll post an update if I get any feedback on the latest version of my app. Barx's new test library now initially sets the sound and vibration to off.

 

[barx]

Do you set .AlertOnce = true?

This make a notification sound / vibrate once, once issued. So even, if nothing fixes the phantom vibrations, at least they should only happen once

 

[Kevin]

Yes, I use the AlertOnce flag for the same reason you cited. However, I only permit the notification to display when my app is on a specific screen, so as the user moves around in the app, the notification comes and goes (as does the vibration and sound for those affected).