Wherigo: handling of asynchronous display requests during play

[eddiemuc]

This issue is to channel discussions about handling of "asynchronous display requests" by a Wherigo cartridge currently in play. Origin of this discussion is here: #16224

The problem at hand: while playing a Wherigo, the cartridge awynchronously requests that dialogs are displayed to the user. This is typically triggered by things like entering/exiting a geofence (Zones), timers and such. At such points in time, the c:geo user might be anywhere in c:geo e.g. on the map, in the search result of an online search, somewhere in his stored lists or cache details or editing an offline log.
Update: at such a point, the user might not even actively use c:geo but might be in another app doing other things.

The following "asynchronous" dialog requests can be made by the cartridge:

• Displaying an informative, multi-page dialog
• Requesting an input from the player (text or single-selection)
• Displaying one of the following types of screens:
  • main-screen (=overview of inventory/zones/tasks/you-see)
  • screen displaying overviews of any of the following: inventory, tasks, "you-see" (called "items" by OpenWIG) and locations (=Zones)
  • screen didplaying details for a "thing" (which may be a Location, Task or other item)
• Displaying an error to the user

(in addition, Wherigo cartridges may trigger the playing of an audio file any time they want, but that's not handled here)

IN order not to disrupt the user's flow too much, as of 20.10.24 EVERY screen above is currently implemented technically as a Dialog which is overlayer over the activity currently in the foreground. With one exception: the "main-screen" is currently only available as Activity.

As requested here I tested this for a situation where the user edits an offline log and Wherigo starts firing requests.
--> Non-duisruptiveness works well for all requests resulting in display of a dialog
--> Non-disruptiveness does NOT work any more when Whergio requests the main screen -> then the actrivity is spawn up

Following movie shows what this means. I tested with cartdige "Wo ist Balthasar" (https://coord.info/GCAEHTP). This cartridge fires a series of dialogs (informative and input) once you enter the Start Zone, then fires a "display main screen" command. I started the cartridge, then opened a "edit log" screen for an unrelated cache, then started filming, then set location to the start zone of the wherigo. As you can see the series of diaplogs is "non-disruptive" (they are just on top of the "edit log screen"), but when the final "display main screen" fires then c:geo is forwarded to the WherigoActivity (and "edit log" activity is closed):

wherigo.mp4

Update: as of now (20.10.24), when cartrdige requests a screen while user is not currently in c:geo (but in another app on her phone), then a notification is displayed to her ("wherigo is waiting for you" - something like that). Upon clicking, user will be lead to WherigoActivity and dialog is shown.

[eddiemuc]

Possible solutions that come to my mind (probably combinable):

• to remain disruptiveness: make a "dialog version" of the main screen which is used here instead of the activity
• for users not wanting to get interrupted: provide a setting that wherigo dialogs are only ever popping up in the wherigoactivity

Related but probably slightly different:

• styling "dialogs" such that they look either "more like dialogs" (eg not full-screen") or "less like dialogs" (eg background color and action bar like activities)

[ztNFny]

Maybe a white/blacklist of Activities that can show dialogs? On map, CacheDetails, main screen, ... the dialogs cause no harm - but some activities (mainly edit one, like log, coordinates, formula) shouldn't be interrupted.
For the later ones c:geo could wait with opening the dialog until the user returns to a "good" activity, (maybe plus show a notification)

[eddiemuc]

Maybe a white/blacklist of Activities that can show dialogs? On map, CacheDetails, main screen, ... the dialogs cause no harm - but some activities (mainly edit one, like log, coordinates, formula) shouldn't be interrupted.

Good idea!

For the later ones c:geo could wait with opening the dialog until the user returns to a "good" activity, (maybe plus show a notification)

Such a "waiting algorithm" is implemented anyway. Eg for the case when the user is not currently in c:geo at all but works in another app. In these cases, currently a notification will be displayed ("Wherigo in c:geo is waiting for you...", something like that) and as soon as user re-enters c:geo (resp: an "allowed activity" where in current implementation all c:geo activities are "allowed") the dialog is displayed