Define the `_activityID` at launch time

[ht2]

It would be useful for launching Activity Providers to define the _activityID at the time of launch dynamically. This could be a best effort approach as such:

• If _activityID is defined in the package, use that
• If activity_id is defined in URL query params, use that (borrowing the format from the existing TinCan launch method)
• If statement.object.id is defined in ADL launch request, use that (may require changes to the LL Launcher to check that the prefix of the incoming object.id matches the defined one in the launch, @ryansmith94 - thoughts here?
• Else use the URL current window

[ryasmi]

This is a bit of an interesting one, I actually think the activity provider should only be able to specify the context activities. I think the content should either come with a hardcoded activity ID or use the current URL. The reason for this is that when the content is moved between activity providers, the content can still be found in the LRS. Granted there are things the LRS could do to connect activities (similar to personas) and I appreciate that there are some requirements in Curatr specifically that mean Curatr looks for the object.id alone to complete certain learning activities.

[ryasmi]

Also worth pointing out that the tin can launch method does allow you to specify an activity_id parameter, however, nothing enforces the content to use it as the object.id, the content can choose to only use it in the context activities.

Using it in the context activities also means there doesn't need to be strange logic in the launch service to partially match in some places, however, partial matching and other matching operators may be useful.

[ht2]

Thank for the 2 cents @ryansmith94, I hear your concerns and we probably longer term need to think about how we could implement. Lets go with the lowest hanging fruit if poss of just passing activity_id via the URL query params as it means Trex will all work nicely and we won't have to change how the creation of those statement forwards work

[ryasmi]

Okay cool, guessing you're not expecting any changes in the launch service with this approach either.

[ht2]

Agreed - there would be complexity if we were to implement a setting of passing a statement.object.id to the launcher filter, as we would want it to "loose match" on that value anyway (e.g. Adapt would append #component/456 to the URL in some statements and would expect that to pass the launch filter).

[brian-learningpool]

Hi @ryansmith94, @ht2, I haven't actually tested it yet but the ADL xapiwrapper used in this extension seems to have support for passing the activity_id in the query string already. See https://github.com/adlnet/xAPIWrapper/blob/master/src/xapiwrapper.js#L1318

Also, in our code the logic for determining the activity ID is in the following order:

1. check the config
2. check the query string
3. fallback to use the current URL

[ryasmi]

That sounds like the correct logic for determining the activity ID. Guess it just needs trying out now. @brian-learningpool you can use and modify our ADL Launch xAPI Demo to test this out with some Adapt content.

[danielghost]

Bit late, but just to add, for cmi5, the spec indicates that the activityId MUST come from the Activity Provider for 'cmi.defined' statements. I know we aren't adhering to cmi5 here, but an argument for the query string being the first check I guess. Personally, I agree with https://github.com/adaptlearning/adapt-contrib-xapi/issues/70#issuecomment-516336138 and it makes most sense for this to come from the content.

[ryasmi]

Hey @danielghost! Hope you're well, it's been a while.

Didn't know that was part of the CMI5 spec, so that's an interesting twist in this tale. Perhaps in that case the order should be the following as you say Dan.

1. Check the query string
2. Check the config
3. Fallback to use the current URL