javascript - container - popover jquery
Escribir una aplicación de estación de radio para teléfono móvil: ¿es viable Javascript/HTML/CSS o necesitamos ser nativos? (3)
Después de haber trabajado en varias de las aplicaciones móviles para Pandora (principalmente BlackBerry), puedo decirte que sería muy difícil (si no imposible) conseguir la experiencia del usuario de la forma que quisiéramos sin hacer cada una de ellas como una aplicación nativa. Los frameworks multiplataforma pueden ser adecuados para una aplicación móvil "típica" que navega por algunos menús de árbol, muestra información, realiza algunas llamadas a servicios de backend, etc. Pero aún no he visto uno que exhiba una API multimedia completa. Puedo entender por qué, también, cada plataforma definitivamente tiene sus peculiaridades cuando se trata de reproducir multimedia. Incluso algo tan simple como precargar la siguiente pista en una lista de reproducción requiere un código personalizado. O seleccionando la ruta de audio para enrutar el audio (bluetooth? Auriculares?) En BlackBerry, la transmisión de audio tiene requisitos especiales de red porque no puede usar los transportes predeterminados BIS o BES; debe tener TCP directo, WAP2 o Wi-Fi. (si está disponible). Así que de nuevo, más código personalizado.
Si te sirve de consuelo, es posible compartir un poco de código entre BlackBerry y Android, es decir, lógica empresarial que no usa API nativas. Dado que BlackBerry usa J2ME, es solo un subconjunto del J2SE que usa Android.
Quiero escribir una aplicación que transmita archivos MP3 desde un servidor a cualquiera de los tres principales sistemas operativos de teléfonos inteligentes en los EE. UU. (IPhone, Blackberry y Android).
Esta es la compensación que me preocupa: si escribo la aplicación de forma nativa, se obtendrá la mejor experiencia de usuario y me dará la capacidad de agregar muchas más funciones si quiero, pero tendré 3 bases de código separadas, lo que viola el Principio DRY
Si uso uno de los frameworks para escribirlo en Javascript / HTML (por ejemplo, Rhomobile Rhodes ), entonces tengo una base de código para todas las plataformas principales, así que no estoy violando DRY y el proceso de desarrollo es más simple en ese sentido, pero a) la experiencia del usuario sufrirá, yb) Hice algunas pruebas simples usando SoundManager para reproducir archivos MP3 con Javascript en el iPhone, y comenzó a chupar de inmediato (por ejemplo, la segunda fase del experimento después de "genial, puedo jugar"). un MP3 "fue" No tengo acceso a las etiquetas ID3? Eso apesta ").
Me pregunto si alguien con experiencia en desarrollo para múltiples plataformas móviles podría confirmar o des-confirmar mi impresión: ¿es viable el desarrollo multiplataforma con Javascript y HTML (particularmente para una aplicación multimedia)? ¿O es "desarrollar y mantener tres bases de códigos nativas separadas" el camino a seguir aquí?
Gracias por adelantado.
Editar: esta pregunta asume que tengo que hacer esto como una aplicación. Entiendo que puede ser mucho mejor simplemente enviar mp3s y dejar que los usuarios de iPhone / Android / Blackberry Media Player los manejen, pero para mi propósito esas soluciones están fuera del marco de esta pregunta.
Gracias, echa un vistazo a Jango, www.jango.com, es todo HTML / JS por el aspecto de las cosas. Funciona muy bien
Me gustaría ir con "desarrollo y mantenimiento de tres bases de código nativas separadas". Como dijiste, ofrecerás una experiencia de usuario más integrada y nativa y ofrecerás funciones que aún no están disponibles a través de HTML / JavaScript.
Creé y mantuve con éxito una aplicación que se ejecutaba en Android, iPhone, J2ME y Symbian, y no es un gran problema.