SDK Sample PluginUI Demo Update

[softworkz 5066]

Dear fellow Developers,

the PluginUI Demo Example in the Emby SDK is demonstrating the wide range of featuires from the Emby PluginUI, but a number of essential things were missing, like how to use buttons and perform actions on button click events, as well as how to create and use dialogs and wizard UI.

I'm glad to tell that these gaps have been filled. The demo plugin content is split into two tabbed views with two menu items in the navigation bar, and two new tab pages have been added for buttons, links, progress and status indication, updating the UI view from the server side and the other page is demonstrating multiple kinds of dialogs and a three-page wizard.

Here's a short video (no audio):

The sample plugin code will be included in the next beta SDK, which means everything after 4.9.0.32.

Edited December 5, 2024 by softworkz

[sjtuross 9]

In the EmbyPluginUiDemo project, I noticed that BasicsOptionsStore is used for persisting BasicsUI settings. If I want to persist options for other tabs, does this mean I need to create separate store classes with different plugin names, resulting in separate json setting files? Is there a way to persist settings across multiple tabs using a single plugin settings file?

I also have a question about EditableObjectBase.GetChangesFromDefault, which identifies differences only from the default values. Is there a way to track changes relative to the previous value instead?

[softworkz 5066]

25 minutes ago, sjtuross said:

In the EmbyPluginUiDemo project, I noticed that BasicsOptionsStore is used for persisting BasicsUI settings. If I want to persist options for other tabs, does this mean I need to create separate store classes with different plugin names, resulting in separate json setting files? Is there a way to persist settings across multiple tabs using a single plugin settings file?

The approach of using a UI class directly for storage is only suitable for simple cases.  Often, plugins have just a few things to configure, like a URL, user name, password, file path, etc., and for these it's just convenient to use the UI class for both, storage and UI. But in those cases, you can just start from the PluginSimpleUI template which does all this for you under the hood and you don't need to care much about it.

Such simple cases end for example when you need to have something in your UI which is not meant for storage or when you have multiple tabs or pages/dialogs/wizards. It would be possible of course, to have multiple UI classes stored to separate files, but that can lead to logical/consistency problems, when the data in one file has dependencies on values in another file and the saving/loading is done separately, so I would advise against doing that, unless your plugin has two or more completely separate blocks of functionality.

The way to go in non-trivial cases is to create a separate storage model, which can be a single class or often comprising multiple classes. Then you have to copy the values to the UI class before showing and back to the storage model on OK/Save, then SetOptions on the storage modal to save it and make it available to other parts of the plugin.
The storage implementation is just there for convenience. You need to be aware to always retrieve a fresh instance via GetOptions to get the latest configuration.
You can also do your own implementation, in one plugin I needed to persist to XML instead of JSON for example, that's all up to you.

57 minutes ago, sjtuross said:

I also have a question about EditableObjectBase.GetChangesFromDefault, which identifies differences only from the default values. Is there a way to track changes relative to the previous value instead?

Yes, you can use this

var changes = PropertyChangeDetector.DetectObjectPropertyChanges(object1, object2);

see: Emby SDK Reference: PropertyChangeDetector

[sjtuross 9]

4 hours ago, softworkz said:

it's just convenient to use the UI class for both, storage and UI.

To your point, it's indeed very convenient. As a plugin developer, I’d like to avoid spending too much time and effort on managing logistics. Initially, I thought SimpleFileStore could take an additional parameter for the option type, allowing multiple UI classes to be serialized into an array within a single JSON file.

Thank you very much for the information and guidance.

[Amything 122]

Thanks for this demo, it's a game changer!

I noticed there was no image sample, is it supported?

[softworkz 5066]

1 hour ago, Amything said:

Thanks for this demo, it's a game changer!

I noticed there was no image sample, is it supported?

What do you mean by "Image sample" - displaying an image?

That's not currently supported, but it might make sense to add something for that. May I ask which use case you have in mind?

[Amything 122]

57 minutes ago, softworkz said:

What do you mean by "Image sample" - displaying an image?

That's not currently supported, but it might make sense to add something for that. May I ask which use case you have in mind?

Yeah, displaying an image. I was thinking of using one for aesthetics, but not necessary.  

[softworkz 5066]

The problem here (looking at older plugins which have config done with html/js) was often that developers make it look nice on one layout type (e.g. DisplayMode=Desktop, viewed in a browser or desktop app) but it doesn't fit when viewed in TV mode or on mobile devices. In turn we had to blacklist plugin configurations, so that they are not accessible on most apps.

When your plugin is in the catalog, you can show any images you like in the plugin info, and once somebody has installed it, you probably don't need any "convincing artwork" anymore.
The other thing is that every developer has its own measures of aesthetics and in the end, every developer might like their own creation, but when you go from page to page, there's no consistency and everywhere you'd see a different kind of style. I think that won't be beneficial overall.

What I thought about would be cases where a plugin does something visual (like the Cover Art plugin) which requires a kind of preview visualize the effect of certain options, but besides such special cases, I think it's good when everything has a uniform appearance.

[Amything 122]

Yeah, makes sense. Thanks!   

[Amything 122]

For hyperlinks you have

public LabelItem LabelItem1 { get; set; } = new LabelItem("This is a link to: https://emby.media") { HyperLink = "https://emby.media" };

I was wondering if you can think of a way to open up a hyperlink with a button? Reason I ask is that my plugins main call of action is to open up a web page so it would be a bit nicer as a button.

I've tried the following but it only works on Windows. 

Process.Start(new ProcessStartInfo
{
    FileName = fullUrl,
    UseShellExecute = true
});

Is there perhaps a way to programmatically execute the LabelItem action?

[softworkz 5066]

Emby uses a client-server architecture, so anything you do in the server code will happen on the server.

In you example using Process.Start, it will open a browser on the server only - you just "accidentally" see it when Emby Server runs in the same session as the client app from which you are accessing the server.
It doesn't even work when you're on the same machine, but somebody configured the server to run as a service - the browser would open in the session of the service and you can't see it. Same on other operating systems - e.g. Linux: Emby Server runs on a different session and under a different account and nobody would see anything.

What comes on top of it, is that not all clients support opening links. For example, on Android TV devices there is no browser installed and we cannot open windows in the context of the engine within which the Emby client is running for security reasons.

Finally, following links means to leave the context of the Emby app. In many cases (e.g. TV mode, operated via a remote), following links means to leave the context of the Emby app and in most cases, there's no chance to navigate back to the Emby app (like with a remote only).

For those reasons it is important that we have a clear distinction between 

• a HyperLink (from which you might not be able to return without changing your input method)
  and 
• a Button (which is always built-in functionality and doesn't cause you to leave the Emby app)

 

[sjtuross 9]

Is there a plan for PluginUI to include support for apps?

[bakes82 167]

How do you add plugins to apps ....

 

[Luke 42077]

1 hour ago, bakes82 said:

How do you add plugins to apps ....

 

HI there, can you please ask your question in a more descriptive manner? Thanks !

[bakes82 167]

@softworkzSo where is all the sample code? I look at the github and its all missing ...
Im looking here: https://github.com/MediaBrowser/Emby.SDK/tree/beta/SampleCode

[softworkz 5066]

Yes, thanks. I have seen that. The build is broken.

Meanwhile, you need to step a few versions back: https://github.com/MediaBrowser/Emby.SDK/tree/e5cfb863d227ee1d4aedf1d6f1b5f2291e2890aa

(there hasn't been a change anyway).

[sjtuross 9]

I'm wondering if PluginUI fully supports user-level configuration.

I set the following for the page info:

EnableInMainMenu = false,
EnableInUserMenu = true,

The page does appear in the user section and loads correctly, but when it's selected, the page title on the left navigation bar isn't highlighted (as it normally would be). Did I miss anything?

Also, is there an example of how UI data inherited from EditableOptionsBase can be saved to and loaded from the built-in user configuration (i.e., stored in the database, not in an external json file)?

[softworkz 5066]

@sjtuross - This might be a bug. 

 

Let's see what @Luke  thinks..