User Switching via HOSContract.METHOD_GET_HOS

[treverthomasET]

Summary

This PR updates the HOSContract to version 0.4 to support multi-user logins to allow for driver switching to be reflected in the HOS Consumer application when querying HOSContract.METHOD_GET_HOS.

For the HOS Consumer to support the user switching the KEY_HOS(sometimes referred to as active driver) will need to know the username provided by IdentityContract.DriverSession.username during the IdentityConsumers(ELD app) query METHOD_GET_LOGIN_CREDENTIALS.

There is an RFC currently open for discussion that this work is intended for. The most notable callout from the RFC is the need to remove Parcel as our means of data transfer within Bundle. Parcel does not like having missing data if the applications communicating do not have matching Class versions.

We've decided to show the work required for Option 2 on the RFC above as that is the preferred direction we would like to go. This allows us to have less Class name changes in the future to support backwards compatibility.

One change to note below is HOSTeamData. To cleanly pass a list of HOSData we've now placed that within it's own object called HOSTeamData that contains the ArrayList<HOSData. This allows the JSON conversion to be called without needing a list conversion or TypeToken.

Data Objects

Version = 0.4 HOSStatusV2(0.3) -> HOSData(0.4) HOSClockV2(0.3) -> ClockData(0.4) ArrayList(0.3) -> HOSTeamData(0.4)

HOSData -> Returned from HOSContract.METHOD_GET_HOS within KEY_HOS username addition

{
  "clocks": ClockData[],
  "logoutAction": "",
  "manageAction": "",
  "username":""
}

HOSTeamData -> Returned from HOSContract.METHOD_GET_HOS within KEY_TEAM_HOS

{
  "teamHosData": [
    {
      "clocks": ClockData[],
      "logoutAction": "",
      "manageAction": "",
      "username":""
    },
    {},... 
  ]
}

Sample Provider Bundle Call

From the provided Java object

HOSData hosData = createHosData(); //Provider implementation of createHosData()
result.putString(HOSContract.KEY_HOS, gson.toJson(hosData));

or straight from JSON itself

String jsonData = getHOSJson() //Provider generated
result.putString(HOSContract.KEY_HOS, jsonData);

Sample Consumer Bundle Call

HOSContract.HOSData hosData = gson.fromJson(result.getString(HOSContract.KEY_HOS), HOSContract.HOSData.class);

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
opencab	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 12, 2023 3:30pm

[BoKlassen]

@treverthomasET @pnc I just want to be clear about the expected object shape, should this PR be merged.

Can you please confirm that the expected object should look like this, with just a single array for all drivers' HosData? If so, is the expectation that the driver currently operating the vehicle is first in the array?

{
    "teamHosData": [
      {
        // HosStatus for driver
        "clocks": ClockData[],
        "logoutAction": "",
        "manageAction": "",
        "username":""
      },
      {
        // HosStatus for coDriver1
        ...
      },
      {
        // HosStatus for coDriver2
        ...
      },
      ...
    ]
}

From my understanding, this is an example of what is not expected:

{
    "hosData": {
        // HosStatus for driver
        "clocks": ClockData[],
        "logoutAction": "",
        "manageAction": "",
        "username":""
    },
    "teamHosData": [
      {
        // HosStatus for coDriver1
        ...
      },
      {
        // HosStatus for coDriver2
        ...
      },
      ...
    ]
}

[treverthomasET]

@BoKlassen Ah I can see how that could be confusing. I've updated the Data Objects section above to hopefully clear it up slightly for any other future readers:

When the HOS Consumer calls HOSContract.METHOD_GET_HOS we will be expecting your second definition where KEY_HOS contains HOSData for the driver

{
"hosData": {
        // HosStatus for driver
        "clocks": ClockData[],
        "logoutAction": "",
        "manageAction": "",
        "username":""
    },
}

and KEY_TEAM_HOS will contain HOSTeamData corresponding to any team drivers/co drivers

{
"teamHosData": [
      {
        // HosStatus for coDriver1
        ...
      },
      {
        // HosStatus for coDriver2
        ...
      },
      ...
    ]
}