For this case, the best would be to use the JS template, as I described above. For simplicity, you can draw a popup template in the editor, but clone and define links later in the script. Then changing the popup in one place will automatically change the behavior in the entire project.

I really don't understand you ((

Create a separate project with the desired popup and draw your component. With a project merge, you can reuse it. If you need additional logic, then you can use the script, if not, then only the interface. You can copy as many of these items as you like.

What confuses you about this option? What is the main purpose of such components for you?

You can create all graphics from a script, i.e. you will have one JS file that you can update (modify) and a separate definition class (constructor) that will allow you to use this component in the right place.

This is impossible for the current architecture from the point of view of isolating such a component (if it is not written by us in native code) and it is basically impossible for C # in mobile applications (code must be compiled before execution).

Your task of reuse is completely solved by the JS script and the selection of a pop-up with elements in a separate project, which you can merge as needed.

Hello

You can create your own JS driver and reuse it in your projects. How does this differ from your definition of a component?

https://dev.iridi.com/I3pro_install#Apple_iOS

Good day!

This is a system setting and cannot be controlled from the application.

You've described an interesting use case, but why can't you put the app in "guide mode" forever? In this case, it will never sleep (only control of the screen backlight).

https://dev.iridi.com/Sonos

Hello

Sorry for the late reply ...

The native driver is made according to open official documentation and supports basic commands and functions. If you have a simple project, it is best to use a native driver.

There are many functions in the script driver that were made by hidden commands and can be changed by the manufacturer at any time. Therefore, the scripting driver should be used with caution and when you know exactly why the client needs this functionality.

By changing the IP: the simplest solution now is to reserve IP addresses for players on your router at the MAC address. We plan to add to the native driver support for binding the driver not by IP, but by the unique serial number of the player (this is how the native application works).