23 |
24 |
25 |
26 |
-
28 |
- Última versión 29 |
- 30 | http://www.w3.org/Mobile/mobile-web-app-state/ 31 | 32 |
- Ésta versión 33 |
- (versión PDF) 34 |
- Versión anterior 35 | 36 |
Las tecnologías Web se han convertido en algo tan potente que se utilizan para construir aplicaciones completas; esto ha sido así durante muchos años en el ámbito de ordenadores de escritorio y portátiles, pero cada vez más también para dispositivos móviles.
38 |Este documento resume las diversas tecnologías desarrolladas en W3C que aumentan las capacidades de las aplicaciones Web, y cómo se aplican más específicamente al contexto móvil. Un buen subconjunto de estas tecnologías se describe y se explica en la formación online en programación de aplicaciones Web de W3C.
39 |-
40 |
- Gráficos 41 |
- Multimedia 42 |
- Adaptación al dispositivo 43 |
- Formularios 44 |
- Interacción con la persona usuaria 45 |
- Almacenamiento de datos 46 |
- Gestión de la información personal 47 |
- Integración con sensores y hardware 48 |
- Red 49 |
- Comunicación y Descubrimiento 50 |
- Empaquetamiento 51 |
- Pagos 52 |
- Rendimiento y Optimización 53 |
- Privacidad y Seguridad 54 |
Estructura del documento
57 |Las características que estas tecnologías aportan a la plataforma Web se organizan en las siguientes categorías: gráficos, multimedia, adaptación al dispositivo, formularios, interacción con la persona usuaria, almacenamiento de datos, gestión de la información personal, integración con sensores y hardware, red, comunicación y descubrimiento, empaquetamiento, pagos, rendimiento y optimización y privacidad y seguridad.
58 |
La Web como una plataforma para desarrollo de aplicaciones
En cada categoría, una tabla resume para cada funcionalidad:
60 |-
61 |
- qué especificación de W3C define la funcionalidad; aquellas especificaciones que se han identificado como de particular importancia en el Core Mobile Web Platform 2012 report están señaladas con una medalla, 62 |
- qué grupo de W3C es responsable de dicha especificación, 63 |
- la etapa de la especificación en el camino a W3C Recommendation (véase más adelante), 64 |
- la estabilidad estimada de la funcionalidad, por ejemplo lo poco que el autor espera que cambie, a partir de un primer borrador que aún puede evolucionar mucho, a un documento final en el que los cambios esperados sean de poca importancia, 65 |
- un enlace al último borrador de los editores del documento, y una representación de la reciente actividad de edición, 66 |
- alguna indicación cualitativa de la disponibilidad de las implementaciones en dispositivos móviles, basado en los datos recogidos de Can I Use… y mobile HTML5, completado con datos de Mozilla developer network, QuirksMode, estado del vídeo en HTML5 según JWPlayer, Chromium Dashboard, estado de la Plataforma Internet Explorer, así como la comprensión del autor del mercado de dispositivos móviles (véase también el código utilizado para generar los iconos de soporte), 67 |
- cuando esté disponible, un enlace a un tutorial de WebPlatform Docs, y a cursos de formación on-line en W3DevCampus relevantes 68 |
- un enlace con el banco de pruebas para dicha función y, cuando sea pertinente, enlace para acceder al repositorio github. 69 |
A modo de recordatorio, W3C crea estándares Web a través del progreso del documento en su track a Recomendación, con los siguientes estados:
71 |-
72 |
“Editors drafts” representa la visión actual de las personas que editan la especificación, pero no tienen posición en términos de estandarización.
73 | “Working Drafts” (WD) son los primeros hitos del progreso del Grupo de Trabajo.
74 | “Last Call Working Drafts” señal de que el Grupo de Trabajo ha determinado que la especificación cumple con sus requisitos y que todos los problemas conocidos se han resuelto, por lo que solicita la opinión de la comunidad en general.
75 | “Candidate Recommendations” (CR) desencadena una llamada para la implementación en la que se invita a los implementadores a implementar la especificación y enviar sus comentarios; Se espera que los grupos de trabajo muestren la especificación mediante la ejecución de los conjuntos de pruebas que han desarrollado.
76 | “Proposed Recommendations” (PR) manifiesta que el grupo ha reunido la suficiente experiencia de ejecución, y desencadena la revisión final por Miembros del W3C
77 | “W3C Recommendations” (Rec) son estándares Web estables y completos; estos documentos son actualizados en raras ocasiones, a través del proceso de “Edited Recommendation”, como resultado de erratas recogidas por los Grupos de Trabajo.
78 |
Antes de iniciar la normalización, un Grupo de Trabajo necesita ser puesto en marcha, basándose en las aportaciones de los Miembros del W3C, a menudo a través de la organización de un taller, o después de la recepción de una Petición de un Miembro de W3C.
80 |W3C ha creado los Grupos de Comunidad, un mecanismo que permite que cualquiera pueda hacer el trabajo experimental dentro de la infraestructura del W3C, en virtud de las normas de Derechos de Propiedad Intelectual que son compatibles para la transición del trabajo al proceso de normalización del W3C.
81 |1. 84 | Gráficos
85 |SVG, Scalable Vector Graphics, proporciona un lenguaje de marcado basado en XML para describir gráficos vectoriales de dos dimensiones. Dado que estos gráficos se describen como un conjunto de formas geométricas, pueden ampliarse a petición del usuario, lo que los hace muy adecuados para crear gráficos en dispositivos móviles donde el espacio de pantalla es limitado. También se pueden animar fácilmente, lo que permite la creación de interfaces de usuario muy avanzadas y manejables.
87 |La integración de SVG en HTML5 abre nuevas posibilidades, por ejemplo, la aplicación de filtros de gráficos avanzados (a través de filtros SVG) a contenido multimedia, incluyendo vídeos. SVG 2.0 se establece para facilitar esa integración y completar el conjunto de características de SVG.
Como complemento del enfoque de declaración proporcionado por SVG , el elemento <canvas>
añadido en HTML5 habilita una API de programación 2D que es muy adecuada para el procesamiento de gráficos con un menor uso de memoria. Esta API no sólo permite la representación de gráficos, si no que también se puede utilizar para realizar el procesamiento y análisis de imágenes - HTML 5.1 agrega la capacidad de hacer ese procesamiento en un Web Worker separado.
Tanto SVG como HTML pueden ser estilados usando CSS (Hojas de Estilo en Cascada); en particular, CSS3 (el tercer nivel de la especificación) se construye como un conjunto de especificaciones establecidas para ofrecer un gran número de nuevas características que hacen que sea sencillo crear efectos gráficos, como esquinas redondeadas, imágenes de fondo complejas, efectos de sombra (Fondos y bordes CSS), contenido girado (Transformaciones CSS, incluido con efectos 3D).
90 |Las animaciones pueden ser descritas de forma declarada via Animaciones CSS, y Transiciones CSS.
92 |Las animaciones también se pueden gestionar a través de secuencias de comandos a través de la API expuesta en Animaciones Web; ya que pueden ser intensas en el uso de recursos, la posibilidad que ofrece la API para el control de la temporización de animaciones basadas en secuencias de comandos para manejar el ratio de actualizaciones a animaciones puede ayudar a mantenerlos bajo control.
93 |Para asegurar resultados óptimos cuando se animan partes de una aplicación, los autores pueden hacer uso de la propiedad CSS will-change
para permitir a los navegadores calcular la animación antes de que ocurra.
CSS Flexbox permite construir disposiciones complejas necesarias para aplicaciones interactivas en pantallas pequeñas.
96 |Las fuentes juegan también un papel importante en la construcción de interfaces gráficas atractivas, pero los dispositivos móviles son, en general, distribuidos con sólo un conjunto limitado de tipos de letra. WOFF 1.0 (Web Open Font Format) aborda esa limitación facilitando la utilización de fuentes que se descargan automáticamente a través de las hojas de estilo, mientras se mantiene limitado el tamaño de las fuentes descargadas a lo que realmente se necesita para hacer que la interfaz se renderice. La próxima WOFF 2.0 actualiza que ese formato tenga tamaños de descarga un 25% más pequeñas, reduciendo el tiempo necesario para descargar y visualizar estas fuentes.
98 |Teniendo en cuenta el tiempo necesario para la descarga de fuentes a través de redes móviles, los autores tienen que adaptar su contenido a la disponibilidad progresiva de las fuentes; Carga de fuentes CSS da los eventos necesarios a los desarrolladores para permitir esa adaptación.
99 |Otro aspecto importante en aplicaciones de uso intensivo de gráficos (por ejemplo, juegos) es la posibilidad de utilizar la pantalla completa para visualizar dichos gráficos; la API de pantalla completa permite a las aplicaciones Web pedir y detectar visualización en pantalla completa.
101 |Del mismo modo, en estos escenarios, a menudo es útil ser capaz de bloquear la orientación de la pantalla; la API de orientación de pantalla permite no sólo detectar el cambio de orientación, sino también bloquear la orientación a un estado específico.
102 |NB: una API de gráficos 3D para HTML5 canvas
, llamada WebGL, se ha desarrollado fuera del W3C, como parte del Khronos Group; esta API se ha construido para ser compatible con OpenGL ES, es decir, para sistemas embebidos, y está diseñado para funcionar en dispositivos móviles.
2. 128 | Multimedia
129 |HTML5 añade dos etiquetas que mejoran drásticamente la integración de contenidos multimedia en la Web: las etiquetas de <video>
y <audio>
. Estas etiquetas permiten, respectivamente, la incorporación de contenidos de vídeo y audio, y permiten a los desarrolladores Web interactuar con mucha más libertad con ese contenido de lo que sería a través de plug-ins. Hacen de los contenidos multimedia ciudadanos de primera clase de la Web, de las misma forma que las imágenes lo han sido durante los últimos 20 años.
La reproducción de contenido puede ser aumentada y completada a través de Media Source Extensions que permite a los desarrolladores generar contenido multimedia en JavaScript.
131 |Para atender a las necesidades de algunos proveedores de contenido, está bajo consideración por parte del Grupo de Trabajo HTML una propuesta para permitir la reproducción de contenido protegido, la API Encrypted Media Extensions.
132 |La Network Service Discovery API abre la puerta para la integración de contenidos DLNA en aplicaciones Web, aunque el futuro de esa especificación es actualmente objeto de examen, debido a la actual falta de interés de implementadores.
133 |Mientras que las nuevas etiquetas HTML5 permiten reproducir contenido multimedia, HTML Media Capture define un mecanismo basado en el marcado para acceder a contenido multimedia capturado usando la cámara y los micrófonos, una característica muy común en los dispositivos móviles. El Web Real-Time Communications Working Group y el Device APIs Working Group están construyendo juntos una API (getUserMedia
) para manipular directamente los flujos de datos de la cámara y los micrófonos, así como una API para grabar esos flujos en ficheros, y otra API para utilizar el acceso a cámaras para tomar fotos de forma programada.
Más allá de la captura y grabación, dos APIs adicionales añaden capacidades multimedia de manipulación para la plataforma Web. Ya hemos mencionado la API Canvas 2D Context API: permite la modificación de las imágenes, que a su vez abre la posibilidad de edición de vídeo.
135 |En una línea similar, el Audio Working Group está trabajando en una API que hace que sea posible modificar el contenido de audio, así como analizar, modificar y sintetizar sonidos, la Web Audio API.
136 |La combinación de todas estas características marca el punto de inicio de la Web como una plataforma completa para multimedia, tanto para los consumidores como para los productores. El creciente interés en torno a la unión de los mundos de la Web y la TV (que se manifiesta a través del W3C Web and TV Interest Group) debería reforzar esta tendencia en los próximos meses. Se espera que los dispositivos móviles asuman un papel cada vez mayor en la experiencia de muchas personas usuarias con la TV, proporcionando una experiencia de "segunda pantalla", donde los usuarios pueden encontrar más información o interactuar con un programa de televisión que están viendo a través de sus dispositivos móviles.
137 | 138 | 139 |3. 142 | Adaptación al dispositivo
143 |Los dispositivos móviles no sólo son muy diferentes de los ordenadores tradicionales, sino que también tienen una gran cantidad de variaciones entre ellos, en términos de tamaño de la pantalla, resolución, tipo de teclado, capacidades de grabación, etc.
144 |La Device Description Repository API es una API de servidor unificada que permite a los desarrolladores Web recuperar los datos en los dispositivos que tienen acceso a sus páginas en una variedad de base de datos de información del dispositivo.
145 |La Media Capture Streams API expone alguna información concreta sobre las capacidades de la cámara y los micrófonos para que sea posible tomar ventaja de la gran variedad de los medios de captura de los dispositivos que contienen los teléfonos móviles.
146 |CSS Media Queries ofrecen un mecanismo que permite la adaptación del diseño y el comportamiento de una página Web basado en algunas de las características del dispositivo, incluyendo la resolución de la pantalla - a las que Media Queries Level 4 propone añadir la disponibilidad y el tipo de puntero de señalización del dispositivo, la capacidad de flotar (hover) sobre los elementos, y la luminosidad ambiente.
148 |CSS Device Adaptation define un conjunto de directivas de CSS para definir el tamaño en el que debe basarse este diseño, en relación al tamaño del dispositivo subyacente - especificando lo que se ha implementado utilizando elemento <meta name="viewport">
.
Las unidades CSS relativas del viewport vw
y vh
permiten diseñar disposiciones que se adaptan a la dimensión del viewport, mientras que el ajuste por CSS del texto en móviles permite al texto adaptarse a las partes de la página redimensionadas mediante zoom.
El Responsive Images Community Group (RICG) está trabajando actualmente en una extensión de HTML, conocida como el elemento picture
, que permite a los autores definir qué imagen cargar en función de las capacidades del dispositivo y/o otras características de media. El RICG publica un documento de casos y requisitos de uso que describe completamente el problema.
Como enfoque complementario, el atributo srcset
, especificado por el WHATWG y también publicado como una extensión de HTML, permite a los desarrolladores Web definir las diferentes proporciones de píxeles de una imagen por dispositivo, dejando que el navegador elija la mejor opción para la densidad de píxeles de la pantalla.
154 | A partir de enero de 2014, existe un acuerdo general entre los fabricantes de navegadores para implementar ambos, picture
y srcset
.
SVG, que permite definir las imágenes que se pueden escalar ampliando y disminuyendo sin ninguna pérdida de calidad, es otra herramienta fundamental para el desarrollo de aplicaciones Web que se adapten a la resolución del dispositivo subyacente.
156 |4. 160 | Formularios
161 |La capacidad de construir formularios enriquecidos con HTML es la base para la entrada de la persona usuaria en la mayoría de las aplicaciones basadas en Web. Debido a sus teclados limitados, la entrada de texto en los dispositivos móviles sigue siendo una tarea difícil para la mayoría de las personas; HTML5 trata parte de este problema al ofrecer nuevos tipos de controles de formulario que optimizan la forma en que las personas pueden introducir datos:
162 |-
163 |
- la entrada de fechas y horas pueden utilizar una serie de controles de formulario dedicados (por ejemplo,
<input type="date">
) donde la persona puede utilizar el control de calendario nativo;
164 | - the
<input type="email">
,<input type="tel">
y<input type="url">
se puede utilizar para optimizar la forma en la que la persona introduce estos difíciles tipos de datos frecuentes, por ejemplo, a través de teclados virtuales dedicados, o accediendo a los registros del dispositivo para estos datos (libreta de direcciones , favoritos , etc.);
165 | - el atributo
inputmode
(propuesto en HTML 5.1) define el tipo de entrada textual que se espera en una entrada de texto;;
166 | - el atributo
pattern
permite tanto guiar las entradas de texto de la persona, así como para evitar la validación en el servidor (que requiere una red de ida y vuelta), o la validación basada en JavaScript (que ocupa más recursos);
167 | - el atributo
placeholder
permite guiar la entrada de texto de la persona mediante la inserción de pistas sobre qué tipo de contenido se espera en un control de entrada de texto;
168 | - el elemento
<datalist>
permite crear controles de entrada de texto libre que vengan con valores predefinidos que la persona puede seleccionar; HTML 5.1 define un mecanismo para el atributoautocomplete
para rellenar automáticamente los campos de entrada basados en los datos conocidos para la persona.
169 |
5. 174 | Interacción con la persona usuaria
175 |Una parte creciente de los dispositivos móviles se basa en las interacciones táctiles. Mientras que las interacciones tradicionales reconocidas en la plataforma Web (teclado, ratón) todavía se pueden aplicar en este contexto, un manejo más específico de entrada basada táctil es un aspecto crítico de la creación de experiencias de usuario bien adaptadas que permite y recoge Touch Events in the DOM (Document Object Model). El trabajo en esta especificación está casi terminado.
177 |Mientras tanto, el Pointer Events Working Group ha realizado un buen progreso en un enfoque alternativo para manejar las entradas del usuario, Pointer Events, que permite manejar eventos de ratón, táctiles y de puntero bajo un único modelo. Se espera que este nuevo enfoque sustituya al actual que está ampliamente desplegado.
178 |A medida que más y más contenido se representa como largas listas desplazables, más lógica se une a los eventos de desplazamiento, y la calidad de la experiencia de la persona usuaria en estas acciones depende de su forma de actuar. El CSSOM View Module determina cuándo los eventos de desplazamiento son lanzados, y deja que los desarrolladores especifiquen el tipo de comportamiento de desplazamiento que quieren.
181 |El trabajo propuesto en CSS Scroll Snap Points añade una mayor capacidad para controlar el comportamiento panorámico y el scrolling mediante la definición de puntos a los que la vista de una aplicación se fijaría cuando el usuario se mueve a través de la página.
182 |La propiedad CSS will-change
también está disponible para indicar a los navegadores que una parte determinada de la página tendrá pronto scroll y debe ser pre-renderizada.
Muchos dispositivos móviles utilizan teclados en pantalla para permitir que los usuarios escriban; la Input Method Editor (IME) API permite coordinar las interacciones entre ese teclado en pantalla y las aplicaciones Web.
185 |A la inversa, muchos dispositivos móviles utilizan la retroalimentación háptica (como la vibración) para crear nuevas formas de interacción (por ejemplo, en los juegos); el trabajo en la vibration API en el Device APIs Working Group está realizando buenos progresos.
186 |Pero a medida que la Web llega a nuevos dispositivos, y como los dispositivos obtienen nuevos mecanismos de interacción con las personas, también es importante permitir a los desarrolladores Web reaccionar a un conjunto más abstracto de interacciones: en lugar de tener que trabajar en términos de "haga clic en", "presione la tecla", o "un evento de toque", ser capaz de reaccionar a un comando "deshacer", o un "página siguiente" independientemente de lo que la persona ha indicado al dispositivo será beneficioso para el desarrollo de aplicaciones Web independientes del dispositivo. La especificación IndieUI Events, desarrollado por el Indie UI Working Group, tiene como objetivo abordar esta necesidad.
187 |Los dispositivos móviles acompañan a las personas que los usan a todas partes, y muchas personas dependen de ellos para recordarles o informarles de eventos, como los mensajes: la especificación Web Notifications habilita esa característica para el entorno Web, mientras que la Push API hace posible alertar a la persona con notificaciones desde el servidor, incluso si el navegador no está en ejecución.
188 |Los dispositivos móviles, en particular los teléfonos móviles, son también en muchos casos muy adecuados para ser utilizados a través de interacciones de voz; la Speech API Community Group está explorando la posibilidad de iniciar los trabajos de normalización en torno a una API JavaScript que haría posible que los usuarios puedan interactuar con una página Web a través de comandos de voz.
189 |Si las personas dictan comandos o utilizan sus aplicaciones a través de interación no táctil, se arriesgan a que la pantalla del dispositivo se apague debido al salvapantallas. Una primera propuesta para una Wake Lock API permitiría a los desarrolladores señalizar la necesidad de mantener la pantalla encendida en dichas circunstancias.
190 |Las limitaciones de hardware de los dispositivos móviles, y sus diferentes contextos de uso puede hacer que las personas usuarias de dispositivos móviles experimenten barreras similares a las personas con discapacidad. Estas similitudes en las barreras significan que se pueden utilizar soluciones similares para responder a las mismas, siendo un objetivo natural hacer un sitio Web accesible tanto para las personas con discapacidad como para los dispositivos móviles (como se detalla en Relationship between Mobile Web Best Practices and WCAG).
192 |Cómo las Directrices de Accesibilidad de Contenido Web (WCAG) y las Directrices de Accesibilidad de Agente de Usuario (UAAG) brindan asesoramiento sobre accesibilidad móvil - es decir, hacer los sitios Web y las aplicaciones más accesibles para las personas con discapacidad cuando están utilizando teléfonos móviles y una amplia gama de otros dispositivos - se está discutiendo en Mobile Accessibility.
193 |WAI-ARIA proporciona información semántica de los widgets, las estructuras y los hooks de comportamiento para hacer aplicaciones Web más accesible, entre ellas en los dispositivos móviles.
194 |6. 199 | Almacenamiento de datos
200 |Un componente crítico de muchas aplicaciones es la capacidad de guardar el estado, exportar contenido, así como de integrar datos de otros archivos y servicios en el sistema.
201 |Para el almacenamiento de datos simple, la especificación Web Storage ofrece dos mecanismos básicos, localStorage
y sessionStorage
, que puede preservar los datos respectivamente de forma indefinida, o bien según la sesión de navegador.
Para interacciones más ricas, la plataforma Web proporciona la File Reader API que hace que sea posible cargar el contenido de un archivo.
204 |Anteriormente, el Web Applications Working Group había considerado de forma complementaria las APIs File Writer y FileSystems, pero estas aproximaciones han sido abandonadas. Se han iniciado conversaciones sobre una nueva propuesta de API para una sandboxed filesystem API.
205 |Mientras tanto, el atributo HTML5 download
ofrece un simple mecanismo para desencadenar una descarga de archivos (en lugar de una página de navegación), con la posibilidad de crear un nombre de archivo fácil de usar.
Sobre este acceso basado en ficheros, la Indexed Database API (IndexedDB) define una base de datos de valores y objetos jerárquicos que se integra de forma natural con JavaScript y puede ser consultada y actualizada de manera muy eficiente - se está trabajando en una nueva versión de la especificación. Destacar que el trabajo hecho alrededor de una base de datos del laddo del cliente basada en SQL, comenzado en 2009, ha sido abandonado en favor de este nuevo sistema.
208 |Con la necesidad de almacenar cada vez más datos por el navegador (por ejemplo, para uso sin conexión), se convierte en fundamental para los desarrolladores conseguir espacio de almacenamiento, que la Quota Management API ofrecerá a las aplicaciones Web.
209 |Del mismo modo, ya que algunos de estos datos deben ser cifrados, la Web Cryptography API del Web Cryptography Working Group expone fuertes primitivas de cifrado para aplicaciones Web, y se puede enlazar a claves preprovisionadas a través de la API WebCrypto Key Discovery.
210 | 211 |7. 214 | Gestión de Información Personal
215 |Las aplicaciones pueden beneficiarse de la integración con los registros de datos existentes de sus usuarios; en los dispositivos móviles, la libreta de direcciones y el calendario son fuente muy útil de información.
216 |Para aplicaciones Web fuera del navegador, un enfoque puramente programático es parte del System Applications Working Group, con el trabajo en curso de la Contacts Manager API.
218 |En el navegador, HTML 5.1 proporciona autocompletado de campos relativos a información de contactos que permitiría a los navegadores reutilizar información de la libreta de contactos del dispositivo.
219 |8. 225 | Integración con sensores y hardware
226 |Los dispositivos móviles están llenos de sensores, por lo que son un gran puente entre los mundos reales y virtuales: GPS, acelerómetro, detector de luz ambiental, micrófono, cámara, termómetro, etc.
227 |Para sacar el máximo provecho de estos sensores en aplicaciones Web móviles, los desarrolladores Web deben estar provistos de hooks para interactuar con ellos.
228 |La Geolocation API proporciona una interfaz común para localizar el dispositivo, independientemente de la tecnología subyacente (GPS, identificación de redes WiFi, triangulación en las redes celulares, etc.). Se está trabajando en nueva propuesta para una versión de la API que incluye geofencing.
229 |Las aplicaciones Web ahora también pueden acceder a los datos de orientación y aceleración a través de la especificación DeviceOrientation Event Specification.
230 |Una serie de APIs para otros sensores están en desarrollo: la Battery Status API, la Proximity Events API, la Ambient Light Events API o la propuesta Ambient Humidity Events API.
231 |Como ya se mencionó en el apartado de multimedia, hay un trabajo en curso sobre las APIs para abrir el acceso a los de datos de cámaras y micrófonos.
232 |La oportunidad para las aplicaciones Web para utilizar mecanismos Near-Field Communications (NFC) han llevado al NFC Working Group a desarrollar la Web NFC API.
233 |Un acceso más global de sensores y hardware (incluyendo USB y bluetooth) está en el ámbito de System Applications Working Group. Recientemente un Web Bluetooth Community Group ha comenzado a desarrollar una Bluetooth Low Engergy API para navegadores.
234 |9. 237 | Red
238 |La conectividad de red representa un activo importante para los dispositivos móviles: la Web es una inmensa tienda de contenidos, así como una fuente casi inagotable de poder de procesamiento, superando dos de las limitaciones de los dispositivos móviles.
239 |La plataforma Web está creando una serie de APIs que facilitan el establecimiento de la conectividad de red en diferentes contextos.
240 |242 | XMLHttpRequest (la base del desarrollo Ajax) es una API ampliamente desplegada para cargar contenido desde servidores Web utilizando el protocolo HTTP y HTTPS: la especificación W3C (anteriormente conocido como XMLHttpRequest Level 2) completa la vigente API con la capacidad de hacer peticiones a servidores en un dominio diferente, la retroalimentación programática sobre la marcha de las operaciones de red, y un manejo más eficiente de contenido binario.
243 |La API Beacon iniciado recientemente permitirá a los desarrolladores encolar las peticiones HTTP sin supervisión, dejando que el navegador las ejecute cuando lo considere necesario, abriendo la puerta para una mejor optimización de la red.
244 |El trabajo iniciado en Web Background Synchronization API proporcionaría un mecanismo robusto basado en Web Worker que permita a las aplicaciones Web descargar y subir contenido en segundo plano, incluso si el navegador no está en ejecución.
245 |Por defecto, los navegadores no permiten hacer solicitudes a través de diferentes dominios (o más específicamente, a través de diferentes orígenes, una combinación del protocolo, el dominio y el puerto) desde una única página Web; esta regla protege al usuario de sufrir un abuso de sus credenciales y el robo de sus datos en otro sitio Web. Los sitios pueden optar por no usar esa regla, haciendo uso del mecanismo de Cross-Origin Resource Sharing, abriendo una cooperación mucho más amplia entre aplicaciones y servicios Web.
247 |XMLHttpRequest es útil para las solicitudes de red iniciadas por el cliente, pero los dispositivos móviles con sus capacidades de red limitadas y el coste que las solicitudes de red inducen en su batería (y algunas veces en su factura de usuarios), a menudo puede hacer un mejor uso de las solicitudes iniciadas por el servidor. La API Server-Sent Events permite desencadenar eventos DOM basados en notificaciones push (a través de HTTP y otros protocolos).
249 |Los primeros trabajos sobre una Push API permitiría a las aplicaciones Web recibir mensajes enviados por el servidor tanto si la aplicación está activa en una ventana del navegador como si no. Para estandarizar los aspectos del protocolo del mecanismo, se está discutiendo un manifiesto por un IETF Working Group.
250 |La API WebSocket, construida sobre el protocolo IETF WebSocket, ofrece una conectividad de red bidirectional, más flexible, y menos intesiva en recursos que XMLHttpRequest.
252 |El trabajo en Web Real-Time Communications también ofrecerá conexiones directas de datos fuente a fuente entre navegadores con características de tiempo real, abriendo el camino para la colaboración multi-dispositivos de las aplicaciones Web.
253 |Por supuesto, una parte importante de la utilización de la conectividad de red se basa en ser capaz de determinar si existe dicha conectividad, y el tipo de red disponible. La flag DOM HTML5 onLine (y su evento de cambio asociado, ononline
) señala cuando la conectividad de red está disponible para el entorno Web.
La network-information API, que se suponía iba a abordar el descubrimiento de las características de la red, ha sido abandonada por el momento debido a la falta de casos de uso.
256 |La API Resource Timing ofrece medir con precisión el impacto de la red en el tiempo necesario para cargar diversos recursos, ofreciendo otro enfoque para adaptar una aplicación Web a su entorno de red.
257 |10. 261 | Comunicación y Descubrimiento
262 |Más allá de la conexión a los servicios en línea, permitir la comunicación entre usuarios y también entre dispositivos y entre aplicaciones es un aspecto importante de una buena plataforma de desarrollo móvil. Para comunicarse con dispositivos desconocidos o servicios ya existentes, un componente de descubrimiento es fundamental.
263 |Para las aplicaciones Web no en un navegador, el System Applications Working Group está trabajando en una completa Messaging API.
264 |La API postMessage
del HTML5 Web Messaging permite a las aplicaciones Web comunicarse entre sí.
La API Network Service Discovery ofrece descubrir servicios en la red local (como los que se ofrecen a través de DLNA), permitiendo a las aplicaciones Web móviles integrarse perfectamente con estos servicios.
268 |El Web Real-Time Communications Working Group es el encargado de un diverso y amplio conjunto de oportunidades de comunicación:
269 |-
270 |
- Conexión Peer-to-peer entre dispositivos, 271 |
- Flujo de datos de audio y video P2P permitiendo la comunicación en tiempo real entre usuarios. 272 |
11. 277 | Packaging
278 |Un aspecto importante de la experiencia del usuario de aplicaciones está ligada a cómo la persona percibe que dicha aplicación está disponible de forma permanente (incluso off-line, que es particularmente importante en dispositivos móviles), así como la forma en que puede ser compartida y distribuida, típicamente a través de compras vía tiendas de aplicaciones - esta se aborda adecuadamente mediante el empaquetado de la aplicación.
279 |La plataforma Web ofrece dos enfoques complementarios para el empaquetado de aplicaciones Web:
280 |-
281 |
ApplicationCache
de HTML5 permite el acceso a las aplicaciones Web off-line a través de la definición de un conjunto de archivos que se espera que el navegador mantenga en su caché; el enfoque actual ha mostrado algunas limitaciones importantes y el HTML y Web Applications Working Groups están considerando una potencial importante revisión de esta tecnología, probablemente basado en ServiceWorker
282 | - un manifiesto en formato JSON en desarrollo por el Web Apps Working Group. El System Applications Working Group estaba construyendo un modelo de ejecución y seguridad sobre ese empaquetado, pero ahora está definiendo una especificación del ciclo de vida la aplicación basada en la de Service Workers. 283 |
12. 288 | Payment
289 |Las tiendas de aplicaciones nativas en dispositivos móviles han facilitado la monetización de las aplicaciones a los desarrolladores, tanto a través de la venta de las propias aplicaciones como de la venta a través de las mismas (las in-app purchases).
290 |Mientras que las aplicaciones Web pueden usar soluciones bien conocidas de pago on-line, se ha comprobado que estas soluciones son más difíciles de usar en dispositivos móviles.
291 |En Marzo de 2014, W3C organizó un taller sobre pagos en la Web para identificar posibles vías en que los estándares pudieran ayudar a hacer la experiencia de pago más simple, especialmente en disositivos móviles. Se está elaborando un manifiesto para un W3C Interest Group que dirija el trabajo en éste ámbito.
292 |Mientras tanto, HTML5.1 especifica ayuda para autocompletar los detalles de la tarjeta de crédito, haciendo más simple el pago mediante tarjeta de crédito una vez que los datos han sido ya introducidos una vez.
293 |13. 296 | Rendimiento y Optimización
297 |Debido a su CPU limitada, y más importante su batería limitada, los dispositivos móviles requieren una gran cantidad de atención en términos de rendimiento.
298 |El trabajo iniciado por el Web Performance Working Group en Navigation Timing, Resource Timing, Performance Timeline y User Timing, da las herramientas a los desarrolladores Web para la optimización de sus aplicaciones Web.
299 |Los primeros trabajos en una especificación de Resource Priorities, part del nuevo objetivo del Web Performance Working Group, dejará que los desarrolladores indiquen qué solicitudes de red deben ser priorizadas.
300 |El trabajo propuesto sobre Efficient Script Yielding ofrece la oportunidad a los desarrolladores Web de utilizar la programación asíncrona más eficiente, pero ha ganado hasta el momento tracción muy limitada.
301 |La API para determinar si se está visualizando una página Web (Page Visibility API) también se puede utilizar para adaptar el uso de los recursos a la necesidad de la aplicación Web, por ejemplo mediante la reducción de actividad de la red cuando se minimiza la página. Del mismo modo, la API para control del timing para animaciones basadas en scripts puede ayudar a reducir el uso de los recursos necesarios para la reproducción de animaciones.
302 |Más allá de la optimización de los recursos, la reactividad percibida de una aplicación es también un aspecto crítico de la experiencia del usuario móvil. El mecanismo tipo hilos hecho posible por Web Workers permite mantener la interfaz de usuario en modo responsive al descargar las operaciones que mayor recursos consumen en un proceso en segundo plano.
303 |La API de batería permite ajustar el uso de los recursos al nivel actual de energía disponible en la batería de un dispositivo móvil.
304 |Las Mobile Web Application Best Practices proporcionan recomendaciones generales sobre cómo crear aplicaciones Web que funcionan bien en los dispositivos móviles, teniendo en cuenta en particular las necesidades de optimización. La oportunidad de actualizar estas mejores prácticas se está construyendo en el Web and Mobile Interest Group.
305 |14. 308 | Privacidad y Seguridad
309 |Los dispositivos móviles siguen a sus usuarios por todo el mundo, y tienen en ellos algunos de los datos más privados y confidenciales (contactos, fotos, calendario, etc.). En consecuencia, es fundamental que los usuarios puedan confiar en sus teléfonos para mantener los datos a salvo de posibles ataques.
310 |Las especificaciones del W3C son revisados por su impacto en la seguridad y la privacidad como parte de su progreso a través del track de Recommendation; el Privacy Interest Group y el Web Security Interest Group en particular, están coordinando revisiones en sus respectivos campos.
311 |Pero más allá de estas consideraciones de tecnología, una serie de elementos de trabajo en curso necesitan protección adicional.
312 |La primera línea de defensa para los usuarios y la unidad de aislamiento para las aplicaciones Web es la política del mismo origen, que limita a qué puede acceder una aplicación Web en cuanto a los contenidos y datos alojados en el mismo origen, es decir, la combinación del esquema de URL, nombre de dominio y el puerto.
313 |Por razones de herencia, esta política no es tan estricta en algunas partes de la plataforma Web, exponiendo a los usuarios a una mayor posibilidad de ataque a través de secuencias de comandos en sitios cruzados o cross-site request forgery. Para habilitar que los autores de aplicaciones Web reduzcan la superficie de ataque más allá de lo que exige la recomendación, la Content Security Policy ofrece hooks que limita los daños que un atacante podría aspirar a lograr.
315 |Para fortalecer aún más la integridad de sus aplicaciones, los desarrolladores Web pueden hacer uso del mecanismo Subresource integrity, que hace posible bloquear los ataques man-in-the-middle o comprometidos proveedores terceros.
316 |En las aplicaciones que agregan el contenido de múltiples fuentes (posiblemente de no confianza), el sandbox HTML5 iframe
permite restringir con qué tipo de interacciones con contenido intregrado de terceros se puede hacer uso.
Como se describió anteriormente, la Web Cryptography API proporciona las herramientas necesarias para cifrar los datos para el almacenamiento y la transmisión desde las aplicaciones Web, con claves de acceso aprovisionado previamente a través de la API WebCrypto Key Discovery.
319 |Para los usuarios que deseen indicar en sus preferencias no ser rastreados a través de sitios y aplicaciones Web, la Tracking Preference Expression (también conocida como Do No Track) permite a los navegadores comunicar de manera explícita su deseo a los proveedores de contenido, y determinar si un proveedor de contenido dado cumple ese deseo.
320 |Para facilitar la autenticación de las personas a los servicios on-line, se ha comenzado a trabajar en la identificación de las oportuniades para gestionar las credenciales y la autorización on-line.
321 | 322 |Agradecimientos
325 | 326 |Gracias a Art Barstow, Anssi Kostiainen, Jo Rabin, Jose Manrique Lopez, Mounir Lamouri, Marcos Caceres, François Daoust and Ronan Cremin for their contributions to this document.
327 | 328 |Este documento es producido a través del HTML5Apps project, financiado por la Unión Europea a través del Séptimo Programa Marco (FP7/2013-2015) bajo el acuerdo n°611327 - HTML5 Apps.
329 | 330 |La traducción al español ha sido producida en el marco del proyecto “Asesoramiento experto en materia de movilidad y visualización sobre Software de Fuentes Abiertas”, financiado por Cenatic.
331 | 332 |