¿Cuáles son las mejores prácticas para desarrollar aplicaciones en múltiples plataformas?

Primero: decide las plataformas a las que quieres apuntar. Dirigirse tanto a iPhone como a Android es “fácil” porque ambos usan una implementación similar de WebKit. La nueva plataforma BlackBerry 6 también está basada en Webkit, mientras que las versiones anteriores no. No podría confiar en características HTML5 sofisticadas si su sitio web móvil fuera completamente funcional en dispositivos BlackBerry más antiguos, y mucho menos Nokia o incluso teléfonos tontos / con funciones.

Si la compatibilidad con una amplia gama de plataformas es importante para usted, le sugiero que tenga una carga en http://www.jquerymobile.com. Parecen tener un enfoque serio para el soporte multiplataforma.

Terminaré con un pequeño complemento para mi propio idioma llamado mobl (http://www.mobl-lang.org). Es un lenguaje que se compila en HTML / JS / CSS y puede ejecutarse en navegadores webkit modernos (como iOS, Android y WebOS).

He creado una aplicación multimedia que tenemos o hemos ejecutado en Symbian 7/8, Symbian 9, iOS, EZX (teléfonos inteligentes anteriores a Android Motorola – se convirtió en base para Limo), BADA, WinCE y Linux (SDL, QT). (No podemos transferir a Android debido a las limitaciones de audio de Android). Casi el 90% del código se comparte entre estas plataformas, al igual que un gran porcentaje de los activos (gráficos, audio, cadenas).

Esto es lo que creo que acertamos para multiplataforma móvil:

Separe su código en particiones de back-end y front-end. Coloque todo el código específico de su sistema operativo en el back-end y use una interfaz estándar entre sus implementaciones front-end y múltiples back-end. Intente mantener su front-end lo más genérico posible, por ejemplo, C sería una mejor opción que Objective-C. C ++ y Objective-C pueden interactuar más fácilmente con C que C ++ con C ++ u ObjC. Codifique sus propias soluciones multiplataforma cuando sea posible (reconocimiento de gestos). Si está apuntando a Android, es posible que pueda usar su front-end genérico con el NDK y no tener que volver a escribirlo en Java.

No uses variables globales. (Pase una estructura * de globales si necesita globales)

Resumen de su entrada tanto como sea posible. Por ejemplo, si tiene una entrada táctil, haga que el back-end pase las coordenadas táctiles en un rango normalizado (es decir, 0.0 a 1.0 o 0-65535, etc.) y elija una esquina para que siempre esté [0,0] en su GUI Pase los gestos como eventos (es decir, deje que el back-end descubra que el usuario se deslizó de izquierda a derecha y pase el front-end a un evento “deslizar hacia la derecha”). Esto le permite hacer cosas como tener una función que es intuitiva como multi -Toque deslizar en una plataforma sea un botón en la GUI para plataformas que no admiten multitáctil).

Use la configuración de tiempo de ejecución dentro de su front-end. Por ejemplo, haga que el back-end establezca una variable de banderas con banderas como NO_VOLUME_KEYS o NETWORK_CONNECTED y ajústelas en consecuencia al inicializar el front-end.

Las plataformas nativas (al menos Symbian, iOS, Bada y Limo) tienen libc y algún nivel de cumplimiento posix. Las API normalmente documentarán la forma específica del sistema operativo de hacer algo, pero las funciones estándar libc y posix están disponibles. Por ejemplo, las 4 plataformas que menciono tienen API personalizadas para el acceso al sistema de archivos, pero las 4 también admiten el acceso al sistema de archivos libc (fopen / fclose). Lo mismo para redes POSIX e IPC (mutexes). Dos incluso admiten hilos POSIX.

Cree su GUI utilizando un paradigma de máscara y configure la máscara con un archivo externo. Esto permite que una base de código se ejecute en múltiples plataformas, incluso múltiples plataformas con compatibilidad binaria.

Almacene todos sus activos por separado de su código. Mantenga los gráficos, el audio y las cadenas separados. Es decir, no cree un archivo de wad con todo su audio y gráficos combinados. Cualquier cadena presentada al usuario debe provenir de un archivo de localización, no codificado en el software o integrado en los gráficos. Esto no solo permite una traducción más fácil del idioma, sino que también le permite describir la interfaz en diferentes plataformas (es decir, “presionar la tecla suave derecha” es “tocar el botón de menú” en una plataforma diferente).

Si va a necesitar un alto rendimiento, asegúrese de compilar diferentes binarios para los núcleos ARM9 y ARM11. Si bien un núcleo ARM11 ejecutará el código compilado para ARM9, la programación es significativamente diferente, lo que resulta en un gran impacto en el rendimiento. Al menos en Symbian, puede tener ambos ejecutables en un archivo de instalación y decidir en cuál instalar durante la instalación.

El audio es lo último que los desarrolladores de sistemas operativos recuerdan que olvidaron al diseñar un sistema operativo. No hay audio de baja latencia en Android y no se admite la transmisión dinámica. Apple tiene una serie de interfaces de audio, y al menos para la que elegimos, el código de ejemplo de Apple no funciona. Si está creando una aplicación donde el audio es un componente clave, asegúrese de planificar cómo su aplicación manejará el audio cuando las funciones no estén presentes.

Si todas sus plataformas de destino pueden iniciar mediante programación un navegador con contenido local, úselo para cosas como sus documentos, tutoriales, ELUA, soporte de contacto, etc.

Para los IDE, los enlaces simbólicos funcionan bien para organizar los datos. Apple y Windows admiten directorios simbólicos, pero debe crearlos en la CLI. Symlinking files no se admite bien en Windows, por lo que no puede tener ningún archivo symlinked en el repositorio de código para IDEs en plataformas Windows.

Aquí están las cosas principales que haría de manera diferente:

Mira cómo manejas los hilos. Algunas plataformas requieren código de subprocesos múltiples, algunas cosas que se comparten entre subprocesos en una plataforma no están en otras, y algunas solo pueden permitir el acceso a interfaces particulares desde subprocesos específicos. Es mejor crear su front-end de una manera que sea independiente pero capaz de enhebrar múltiples o uni y dejar que el back-end controle el enhebrado. Si volviera a escribir nuestro front-end, lo escribiría con un solo subproceso y crearía mi propio programador de tareas.

Si no necesita 3D, intente adherirse al renderizado en un mapa de bits en su interfaz y bórrelo en su interfaz. OpenGL-ES 1.1, la biblioteca gráfica más multiplataforma, está pobremente documentada y las bibliotecas PowerVR están llenas de errores. (Apple creó sus propias extensiones propietarias para evitar los errores, lo que rompe la plataforma cruzada).

Elementos de mapa de bits de capa que animan / cambian en submapas de bits con dimensiones de potencia de dos. Si necesita usar OpenGL (la única forma de obtener actualizaciones rápidas de pantalla en iPhone, probablemente lo mismo en Android), será más eficiente pasar ^ 2x ^ 2 subelementos que toda la pantalla, y no agregará demasiado sobrecarga a blits.

Lo más importante, priorizar. Si tiene recursos limitados, incluso si desea admitir todas las plataformas por igual, piense realmente en ello. Si su aplicación genera ingresos, concéntrese en lo que cree que será la plataforma más lucrativa y use los ingresos allí (si es necesario) para apoyar el desarrollo en otras plataformas.

Vaya con código nativo en cada plataforma si su aplicación es incluso un poco compleja. No es el dolor de cabeza de portar. Android y RIM son Java, pero versiones diferentes, con API muy diferentes. Es posible que * pueda encapsular parte de la lógica empresarial en clases portátiles, pero soy escéptico.

Utiliza gráficos vectoriales para todo. Realice los diseños en Illustrator y tenga un proceso para llevarlos a un ráster específico de resolución según sea necesario. Especialmente en Android, puede tener más de 10 versiones del mismo gráfico para diferentes tamaños de pantalla / resoluciones / orientaciones. Es mucho más fácil iniciar el vector, y la calidad es muy superior a la escala / recorte constante.

Documentar la lógica de negocios de la aplicación. Pequeñas cosas, como la validación de entrada, pueden ser confusas si se implementan de manera diferente en diferentes plataformas.

Si su aplicación se comunica con un servidor de fondo, produzca documentación detallada y de alta calidad que pueda proporcionar a los desarrolladores en cada plataforma.