API Proposal - Connect to the Clarius probe without user interaction #1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This draft proposes new client commands and server events to allow an API user to connect to the Clarius probe, without the user having to open the Clarius app explicitly. In summary, it would allow a 3rd party app to implement the scanner selection dropdown itself.
Rationale
This is important to lower any friction for existing Clarius and/ or ThinkSono users for adoption. A user does not expect to have to switch to the Clarius app and manually need to start a scan to enable imaging in a 3rd party app. This lead to user frustration in our testing. Even though there is the 3rd party integration option via
MSG_3P_PACKAGE, the task for the user is not entirely clear without manual explanation. Also, in situations where the connection to the probe is dropped, manual intervention by the user is required. Ideally, a 3rd party app could attempt to reconnect to the probe automatically.We believe that this change can greatly enhance the UX of any user who want to try 3rd party application with the Clarius scanner.
Proposal
The code diff shows the proposal of API specification. The text below gives more context on the envisioned functionality.
The API should allow to manually query a list of available probes for the currently logged in Clarius user (
MSG_LIST_PROBES). A return event will deliver a parcelable with the probe information (MSG_RETURN_PROBES). In this draft, I designed it as a list of a newProbeclass, provided in the return bundle. Alternatively, we could reuse the existingProbeInfoparcelable. For each probe, we want to know all data points to potentially reimplement the scanner selection dropdown, i.e:The
MSG_RETURN_STATUScan be used to check if the request succeeded, i.e. if the user is not logged in, the list request should fail with status0.The API should allow to explicitly connect to an available scanner with a client command (
MSG_SELECT_PROBE). The probe is selected by providing the serial number and the application name (i.e.vascular). The request to connect to the probe may fail, i.e. when trying to connect to a probe that is not available or no license is granted or the application for the selected probe does not exist or the application for a virtual scanner is not downloaded. TheMSG_RETURN_STATUSreturns0in that case.In order to check whether the probe is actually available for connection an explicit
MSG_PROBE_STATUS_CHANGEDserver event is introduced with the following states:If a connection attempt failed (i.e
MSG_RETURN_STATUS0) theMSG_SELECT_PROBEneeds to be initiated again. The MobileAPI does not retry a failed attempt automatically.This draft does not support to query available applications for each scanner. This may be solvable by providing a specification, i.e. which set of applications is supported for which scanner/ model/ version combination. Otherwise, the list of available applications could also be returned as part of the
MSG_RETURN_PROBESserver event.As a side note: The
MSG_LICENSE_CHANGEDevent cannot be used to distinguish whether a probe is not properly connected vs the probe has no mobile API license. We currently use this event to indicate to the user that the mobile api has to be enabled in the first place, though we cannot deliver a consistent UX due to this behaviour. The possibility of aMSG_PROBE_STATUS_CHANGEDwould allow for a more explicit interface and resolve those challenges as well.