Roku (HFN) Plugin

That’s correct. You can update in onConnect if you want. I’m sure any performance improvement by skipping the call is negligible.

I’ve integrated the various changes discussed above, sometimes taking my best guess on how to handle a few situations. Please let me know if you have any problems with the latest version. One thing, @amingle, I wanted to call out is that I put in the valid signal check, but rather than clearing the ProgramTitle, I set it to “NO SIGNAL”. I’m open to change how that works, but I though it was a little more explicit/informative than simply clearing ProgramTitle.

In addition, one thing that is kind of bugging me is the WOL/PowerToggle portion of the code. Since the plugin does not currently “know” power state of the device, it in theory could send WOL for a PowerToggle even if you are trying to turn it off. That isn’t super-likely to happen because the WOL only gets sent if the Roku doesn’t respond within a second to the power command, but it’s just kind of ugly and I would recommend staying away from PowerToggle if possible.

It does raise a broader question, however, of how Switch should be handled in plugins. I’ve never incorporated it into any of mine because I use the explicit PowerOn/PowerOff Media Commands, but I thought I’d see, @bill, if you had any thoughts on the preferred convention for the Switch capability? I’m guessing in order to implement it correctly, you would have to continuously poll for power state information? If we did have reliable power state info, the WOL/PowerToggle thing could probably be cleaned up some more.

I probably wouldn’t worry about incorporating the Switch capability because, yeah, there really isn’t a reliable way to determine the current power state. None that I’m aware of anyway.

This all looks good to me. I don’t see any issues with how you implemented anything here. Thanks for your work on this.

Came across an interesting part of this plugin this week. I changed the above line to be:
device.SupportedInputSources = Object.keys(apps).sort();

This way, the list of Supported Input Sources is alphabetized (handy for a dropdown menu).

However, the default JS sort() is case sensitive. I ran into this with discovery+, which has a lower case app name. So, I changed it to:

device.SupportedInputSources = Object.keys(apps).sort(
	function(a, b) {
		if (a.toLowerCase() < b.toLowerCase()) return -1;
		if (a.toLowerCase() > b.toLowerCase()) return 1;
		return 0;

Now, the list is alphabetized regardless of case.

That’s an interesting point about sorting the sources, I assume you put them in a ComboBox to get the drop-down list? I haven’t actually used that control before. @bill, I’m curious, from a design/HR usability standpoint, does it make more sense to add a sort capability to the control itself (with an option to do a case-insensitive sort)? That way you could do it for any set of inputs (or other values you were putting in the ComboBox, regardless of whether they were from a plugin device or a built-in device. Obviously the plugin device code can always be modified, but with a built-in device, there’s no way to get a sorted list if you wanted to, correct? Is that a reasonable thing to put in a feature request?

That’s correct. I can switch inputs using the combo box options. Interesting thought about putting that at the designer level instead of within the plugin.

I don’t know if this is something I want to add to the ComboBox control. At least not now anyway. If the user really wants to customize the order they could just manually assign the Items instead of Binding to the ItemsSource. That or they can customize the plugin.

But manually assigning would only work if the item contents were known ahead of time, right? Otherwise, if the data from the binding varied over time and was not necessarily predictable, that wouldn’t be an option, would it? I’ve never really done anything with the ComboBox, so I may be off base here/not understanding exactly what you’re proposing.

Correct. I don’t know that there’s anything wrong with that. My preference would be to have the plugin do the sorting. Default to whichever sort method the majority of users want. You could also add a sort option Setting to your plugin. Have them choose their sort method when they create the plugin. It’s really no different than prompting them for the IP address of the Roku device.