Uploaded image for project: 'GPII - Global Public Inclusive Infrastructure'
  1. GPII - Global Public Inclusive Infrastructure
  2. GPII-3958

Implement new API and core function to allow reread of settings during session

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      A new use case has emerged from HyperAspect's current work implementing the volume control button for GPII-3881. It is necessary to make reasonable efforts to ensure that the state of the button - the volume setting and mute status, do not get significantly out of step with the operating system's current values. It was determined at this week's Morphic meeting that the QuickStrip/GPII app would issue a read for these values whenever the volume dialog was opened.
      This requires additions to the bus (historically named "PSPChannel") that is used to communicate between the core and the GPII app, as well as a new LifecycleManager action type to represent and implement the query.
      Suggested draft API:
      The app sends a message of the form:

      {
          type: "pullModel",
          value: {
              "settingControls": {
                  "http://registry.gpii.net/common/volume": {
                      value: true
                   }
               }
          }
      }
      

      The LifecycleManager will push this through inverse matchMaking in the usual way, determine which SettingsHandlers need to be queried, update its session values which will then naturally cause the standard "modelChanged" message to be emitted back out via the PSPChannel.

      We should take this opportunity to standardise the incoming PSPChannel API so that it uses the standard "sendTypedMessage" format that the incoming one does, and also remove the strange hack that is operated by "gpii.pspChannel.adjustPreferenceMessage" in PSPChannel.js . This means that the incoming messages that are currently received will take the form of "modelChanged" messages directed against the PSPChannel's session, just as the outgoing ones are, leaving room for the new "pullModel" messages to be distinguished by the new type field.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              cli@ocad.ca Cindy Qi Li
              Reporter:
              amb26 Antranig Basman
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated: