Once you have started developing your Applet, you will need ways to debug and work with your code.
Whether you are working with Box Code Mode or creating your Applet through CLI, these steps will help you identify and correct any issues you might encounter.
Emulators
One of the biggest advantages of developing with signageOS is the ability to test your Applet before deployment through Emulators. These Emulators are cost-free and very closely simulate the display behavior.
Note: It is important to keep in mind that while Emulators can simulate the display behavior, they will not reflect display capabilities (such as LED functionality)
1. Create an Emulator
You can create emulators from the Box console under the Deployment -> Emulator generation menu item. Name your Emulator, select your Organization, and click "Create an emulator."
2. Assign an Applet to your new Emulator
Once your Emulator is available, you can find it under the "All devices" tab. Locate your Emulator and assign your Applet. To debug, you can now open your Emulator and open the Inspect tab like you would any other webpage elements. Within the console, you can see native logs straight from the Applet as well as your own console.logs from your own code, including any error or warning messages.
3. Open the Emulator in Chromium version matching your device
It is important to note that to achieve the best results, you should always check what version of Chromium is running on your device and reflect that while using an Emulator for your Applet development versions. You can find more information about which Chromium is used by which platform in our article here, including download links to them.
Remote debugging
The topic of remote debugging is described in more detail in this documentation article.
There are two options for remote debugging:
-
Weinre
- A third-party tool allowing you to remotely access DOM and console log of your device
- Accessible under the Troubleshooting tab under Device detail page
-
Native
- Depending on the platform, different approaches to accessing the Native debug
- For most platforms accessible through chrome://inspect page
Both of these options must be enabled under the Troubleshooting tab and may require a device reboot. For individual steps on how to access these tools, refer to the linked article.
Most common issues
Throughout our experience, some issues are re-occurring in this part of the article we will go over these cases and help you with resolving them.
Using modern JS on older browsers
The majority of older SoC devices are running old, non-upgradable browsers. To run on these devices, you need to transpile your JS code to ES5 and add the necessary polyfils.
CORS
Cross-Origin Resource Sharing (CORS) is an HTTP-header-based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources.
Occasionally, incorrectly set CORS might prevent you from loading resources into your applet. If the fetch request errors are handled correctly in your code, you should be notified in the console.
Example of how to handle a fetch request
fetch('https://giphy.com/explore/free-gif')
.then(function (resp) {
console.info('response', resp);
return resp.text();
})
.then(function (text) {
console.info('text', text);
})
.catch(function (error) {
console.error(error);
});
Error log notifying of failed fetch request
You can check for CORS setup for your resources by using our ready-to-use applet from our public GitHub repository.
To fix this error you will need either to have access to the server from which the resources are being served or send requests through a proxy server. In either case, the server will have to have its' CORS headers set up correctly.
The header that needs to be set up for either a wildcard or the domain is:
Access-Control-Allow-Origin
You can read more about CORS and the values the header accepts from various online resources. An example and more information can be found in Mozilla docs here.
If set up correctly, your applet should now be able to access the resources.
Headers
This error is related to SSSP2 and SSSP3 devices. In case you are encountering any issues with files downloaded to these lines of display models, make sure that your server provides the content alongside these headers in your request:
Content-Type
Content-Length
SSL
If your applet is accessing a third-party server for hosted resources (images, videos, etc.) and your content is not appearing when assigned to a device, one of the reasons could be an incompatible/expired root certificate. For requirements and recommendations on having your resources accessible, you can read the information in our documentation article.
The fastest way to check if your resources are available is to access OSD on your device and input the resource URL into the Network Connection test field.
Errors
As you are developing your applet and possibly run into issues (ie. videos not playing, content not showing, etc.) and access the content of your applet through previously mentioned debugging methods you should develop alongside with our JS SDK documentation. Developing alongside with the documentation can clarify various mistakes and provide helpful insight into all functions and methods called to leverage functionality of signageOS.
You can find the SDK documentation over at: https://developers.signageos.io/sdk/
In addition, it is highly recommended to develop alongside using our various example applets from a public GitHub repository where you can find several use-case examples and benchmarks: https://github.com/signageos/applet-examples/tree/master/examples