Hi folks,
the discussions around how we should re-engage the user (aka notify the user) started taking place in github.
Here is the issue to track it:
Also for those ones that want to know a sneak peak of the first discussion, this was the output by @wilsonpage:
Myself and @arcturus had a discussion offline I’ll attempt to summarise the outcomes:
Ideally we should not make any data/fetch requests during background
scanning to conserve battery. We can still display 'N items discovered’
and fetch only when the app is launched.We’re not yet sure if there’s a way background scanning logic can live in JS or must be written for each platform.We need to design a heuristic for when we should notify this will be based on:
Has this tile been seen before?Has this tile been dismissed?
Android
We should have a background service that is spawned periodically to scan for content, populating a ‘history’ database.We should not ping or buzz the user, but use a ‘subtle’ notification that appears in the tray without interrupting the user.If possible we’d also like the notification to appear on the lockscreen.
iOS
Notifications are quite different to Android, falling into the categories above.We can use the app icon ‘badge’ (see above) to indicate the number of beacons nearby.We’ll have to periodically wake the app using ‘App Background Refresh’ to perform a scan.Notifications can’t be amended/retracted once sent, so every
notification creates a new item in the notification tray. Although we
hear this will change in iOS 10.As iOS notification are more intrusive, we need smarter heuristics for when to show themWe can prevent a sound being played with our notifications.We aren’t able to prevent the ‘toast’ overlay that is shown, this is
something the user must change in the Settings App -> Notifications
panel.
