Roku deploy with args

[iBicha]

Allow options (perhaps in bsconfig.json) to specify args passed when launching, things like mediaType and contentId To allow launching with deep link data directly. It would be nice that brighterscript require('brighterscript').ProgramBuilder can take these launch arguments and pass them to the app on Roku.

[TwitchBronBron]

Yeah this would definitely be nice.

@chrisdp It kinda feels like this does belong in roku-deploy, even though roku-deploy hasn't done any code modifications up to this point. It wouldn't be too much, just have the "scan for the main function()" task and then modify the main function to look something like this:

sub main(params) : params.append({mediaType: "<the value>", contentId: "<the value>"})

[iBicha]

I thought it could be done using ECP https://developer.roku.com/en-ca/docs/developer-program/debugging/external-control-api.md#general-ecp-commands

http://:8060/launch/[dev | channeID]?contentId=&MediaType=

I would avoid modifying code if I could. But I'm too new to the system to know which is the best approach

[TwitchBronBron]

Since this is a developer workflow, the deep links will be triggered against the dev channel. However, we're not guaranteed that the dev channel exists yet, and since this is roku-deploy, normally developers are most likely going to be zipping and then uploading/sideloading the app.

So consider the following workflow:

1. zip and sideload the app. It starts running your "cold start" logic because there are no deep links
2. Now send the ECP deep link command. Your app is somewhere in the middle of starting up, and then it receives the deep link which is not the same flow as a cold start deep link launch.

Now, we could sideload the app, kill the app, then trigger the deep link, but if you've got run_as_process enabled, the app will already be loaded up in the background.

This is the approach we took in the vscode extension, but it's quirky.

So I guess it would help shape this feature request if you could clarify how you're planning to use the deep link feature. Are you going to be zipping, sideloading, deep link testing all in one flow? Or were you planning on using roku-deploy to trigger deep links on an already-sideloaded dev app?

[iBicha]

I was planning on both to be honest. Testing a deep link when the app is not running, and when the app is running. I have not considered any implications of run_as_process though.

The workflow I imagine is to have 3 (or more) launch settings in vs code

• One with no args
• One that starts the app with args
• One that sends the args to the currently running app

[TwitchBronBron]

Ok, so just for clarification, this is the roku-deploy npm package which many developers use to create their zips and run sideloads from bash scripts or CI situations.

Are you more interested in the vscode launch.json functionality? If so, we actually do already have some deep link support in vscode. See this docs link for more info: https://rokucommunity.github.io/vscode-brightscript-language/Debugging/deep-linking.html

[iBicha]

Ok, so just for clarification, this is the roku-deploy npm package which many developers use to create their zips and run sideloads from bash scripts or CI situations.

Are you more interested in the vscode launch.json functionality? If so, we actually do already have some deep link support in vscode. See this docs link for more info: https://rokucommunity.github.io/vscode-brightscript-language/Debugging/deep-linking.html

I think this is exactly what I was talking about - I just thought that such functionality would be embedded in roku-deploy.

So this feature would only be relevant for people not using VS Code. Perhaps I should close this issue, and wait for someone to actually need this in roku-deploy itself.

Thanks a lot of your thorough responses!