Good Practices
Important
Exception handling should be used with try/catch. Unhandled exceptions could disable the HTML5 player in some of its functions. If errors occur that could harm the normal execution of the player, Admira will not be responsible for the consequences.
Iframe
The execution of content or WebApps occurs within a sandboxed HTML <iframe> TAG. This iframe sandbox contains the following permissions enabled:
allow-forms Re-enables form submission
allow-pointer-lock Re-enables APIs
allow-same-origin Allows the iframe content to be treated as being from the same origin
allow-scripts Re-enables scripts
By cons are not allowed:
top-navigation; (esto es, solo se puede usar “_self” en target de links)
popups
Access to external resources
Each case is different. In the case of wanting to access resources from other “sites”, the execution policies from an <iframe> must be taken into account. This means that options like X-Frame-Options or CORS must be set correctly on the server we want to make the request to. In short, the WebApps that we want to run in admire <iframe> do not run as in a browser, but in an “unattended window”.
ASYNC requests
It is important to note that any request made either abroad (url on the internet) or locally (file on filesystem) must be done ASYNCHRONOUSLY, since the HTML content shares an execution THREAD with the player. Therefore, if a SYNC request were to occur, the player would stop until the request was finished. This can cause serious problems running player. Therefore, ALL requests must be made ASYNCHRONO, just as any execution of SYNCRONO blocking code must be avoided so that it does not cause an unusual stop to the player.
On this website we can simulate blocking of requests:
http://slowwly.robertomurray.co.uk/delay/3000/url/http://api.admira.com
Where 3000 is the delay in milliseconds.
Last updated