Buenas prácticas
Importante
Se deberá hacer uso de control de excepciones con try/catch. Las excepciones no controladas podrían inhabilitar el player HTML5 en alguna de sus funciones. Si se produjeran errores que puedan perjudicar la normal ejecución del player, Admira no se haría responsable de las consecuencias.
Iframe
La ejecución de contenidos o WebApps se produce dentro de un TAG HTML <iframe> sandboxed. Este iframe sandbox contiene los siguientes permisos habilitados:
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
Por contra no están permitidos:
top-navigation; (esto es, solo se puede usar “_self” en target de links)
popups
Acceso a recursos externos
Cada casuística es diferente. En el caso de querer acceder a recursos de otros “sites”, se deberán tener en cuenta las políticas de ejecución desde un <iframe>. Esto significa que opciones como X-Frame-Options o CORS deben ser seteadas correctamente en el servidor al que queramos hacer la petición. En definitiva, las WebApps que queramos correr en admira <iframe> no se ejecutan como en un navegador, sino en una “ventana desatendida”.
Peticiones ASYNC
Es importante remarcar que cualquier petición que se haga ya sea al exterior (url en internet) o de forma local (fichero en filesystem) debe hacerse de forma ASYNCRONA, ya que el contenido HTML comparte HILO de ejecución con el player. Por tanto, si se diera el caso de una petición SYNC, el player pararía hasta que la petición finalizara. Esto puede provocar problemas graves en la ejecución de player. Por tanto, TODAS las peticiones deben hacerse de modo ASYNCRONO, de igual modo que cualquier ejecución de código bloqueante SYNCRONO debe evitarse para que no provoque una parada inusual al player.
En esta web podemos simular bloqueos de peticiones:
Donde 3000 es el delay en miliseconds.
Last updated
Was this helpful?