google
Android notifications: Multiple notifications piled up from ESM queries
We have an experiment which includes a schedule "Random sampling (ESM), 6 times per day" with an action "Create notification to participate" (no custom scripts or web form), and one participant using an Android phone reported that notifications for multiple ESM pings would pile up on their device.
Should prior Paco notifications be cleared when a new notification is sent by default? If this isn't the desired default behavior, can this be an option that is added to the web interface?
For more information, do the windows for the times overlap? Is this in multiple groups or a single group with a single schedule?
The default behavior should be for the same schedule and action it will remove the previous entry if a new one is signaled, but, if there are multiple schedules or groups they might overlap.
Thanks, Bob
On Jan 24, 2017, at 9:05 AM, mdgilbert [email protected] wrote:
We have an experiment which includes a schedule "Random sampling (ESM), 6 times per day" with an action "Create notification to participate" (no custom scripts or web form), and one participant using an Android phone reported that notifications for multiple ESM pings would pile up on their device.
Should prior Paco notifications be cleared when a new notification is sent by default? If this isn't the desired default behavior, can this be an option that is added to the web interface?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
I'm not sure exactly how the random times are selected, but for this experiment the start and end times are from 9am to 8pm, so 11 hours with a minimum of 90 minutes between pings (and a 30 minute timeout on the pings), with a frequency of 6 times per day. The only notifications that are triggered for this experiment are for this single experiment group - there are two additional experiment groups, but those are for app logging and location logging and shouldn't trigger any notifications.
On Tue, Jan 24, 2017 at 9:11 AM, Bob Evans [email protected] wrote:
For more information, do the windows for the times overlap? Is this in multiple groups or a single group with a single schedule?
The default behavior should be for the same schedule and action it will remove the previous entry if a new one is signaled, but, if there are multiple schedules or groups they might overlap.
Thanks, Bob
On Jan 24, 2017, at 9:05 AM, mdgilbert [email protected] wrote:
We have an experiment which includes a schedule "Random sampling (ESM), 6 times per day" with an action "Create notification to participate" (no custom scripts or web form), and one participant using an Android phone reported that notifications for multiple ESM pings would pile up on their device.
Should prior Paco notifications be cleared when a new notification is sent by default? If this isn't the desired default behavior, can this be an option that is added to the web interface?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/paco/issues/1534#issuecomment-274870326, or mute the thread https://github.com/notifications/unsubscribe-auth/ACO7YVJcAiI50iIl4Wrh3KpefZT2lZTgks5rVjC1gaJpZM4LshsM .
OK, thanks for the extra information.
Could you possibly share a copy of the experiment with me directly?
Also, what model of phone and what version of Android was it?
The random times are picked from the day uniformly but it leaves minimum buffer time around the times so that they do not overlap with each other. If the schedule is too constrained, i.e., not enough hours for the number of signals + minimum buffer it may have to drop signal count. In the case you describe, there should be sufficient time. Also, the notifications should timeout and be removed from the tray before the next notification would be triggered. It would be great if you could email me directly a troubleshooting report for the phone that had the error.
Thanks, Bob
On Jan 24, 2017, at 10:15 AM, mdgilbert [email protected] wrote:
I'm not sure exactly how the random times are selected, but for this experiment the start and end times are from 9am to 8pm, so 11 hours with a minimum of 90 minutes between pings (and a 30 minute timeout on the pings), with a frequency of 6 times per day. The only notifications that are triggered for this experiment are for this single experiment group - there are two additional experiment groups, but those are for app logging and location logging and shouldn't trigger any notifications.
On Tue, Jan 24, 2017 at 9:11 AM, Bob Evans [email protected] wrote:
For more information, do the windows for the times overlap? Is this in multiple groups or a single group with a single schedule?
The default behavior should be for the same schedule and action it will remove the previous entry if a new one is signaled, but, if there are multiple schedules or groups they might overlap.
Thanks, Bob
On Jan 24, 2017, at 9:05 AM, mdgilbert [email protected] wrote:
We have an experiment which includes a schedule "Random sampling (ESM), 6 times per day" with an action "Create notification to participate" (no custom scripts or web form), and one participant using an Android phone reported that notifications for multiple ESM pings would pile up on their device.
Should prior Paco notifications be cleared when a new notification is sent by default? If this isn't the desired default behavior, can this be an option that is added to the web interface?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/paco/issues/1534#issuecomment-274870326, or mute the thread https://github.com/notifications/unsubscribe-auth/ACO7YVJcAiI50iIl4Wrh3KpefZT2lZTgks5rVjC1gaJpZM4LshsM .
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.