En términos de programación, necesitará un kit de desarrollo de software (SDK) para el entorno para el que desea programar. Hay SDK multiplataforma, que se adhieren exclusivamente a las funciones disponibles en todas esas plataformas. Son los más limitantes en términos de lo que puedes hacer, obviamente, pero los más flexibles sobre quién puede ver lo que has hecho. Recuerde, las versiones incompatibles (en cuanto a lo que desea hacer) de la “misma” plataforma cuentan como plataformas diferentes en lo que respecta al SDK.
Ahora, en la mayoría de los casos, los únicos lenguajes que puede usar están compilados (como C, C ++, D) o dónde está integrado el motor para ejecutarlo (eso generalmente significa Java, donde es posible, ya que Flash no está desarrollado para Linux también conocido como Android, y Silverlight / Moonlight es abandonware).
Cada SDK proporcionará una interfaz de programador de aplicaciones (API) que define exactamente lo que puede hacer y las instrucciones necesarias para hacerlo. Android tiene su propia API interna y ABI (interfaz binaria de aplicación), pero eso no es lo que te importa, incluso si es lo mismo que te dan. Lo que se le da es lo que puede usar y eso generalmente debe tratarse como si fuera específico del SDK. Algunos de ellos lo serán, porque el objetivo de un SDK es ocultar detalles y proporcionar un nivel de abstracción. Como resultado, no puedo decirte con precisión, para ningún idioma, qué obtendrás.
- ¿Qué marco debo usar para crear una aplicación multiplataforma como Evernote o Dropbox?
- ¿Qué nuevas tecnologías se usarán tanto en aplicaciones móviles como en servicios de desarrollo web en 2018?
- ¿Cuánto costaría desarrollar una aplicación móvil como OneBusAway?
- Quiero construir una aplicación de inventario simple para nuestra escuela primaria. ¿Algún consejo sobre por dónde empezar?
- Tienes una idea para una aplicación móvil y quieres saber si otra persona ya lo ha hecho antes buscándola en Google. ¿Puede esa búsqueda ser la fuente de una fuga?
Ahora, entramos en lo que se debe y no se debe hacer. La mayoría de los cuales son totalmente ignorados por los escritores de aplicaciones.
Recuerde que algunas pantallas de teléfono son muy pequeñas y de baja resolución.
No requiera permisos que no necesite o que pueda evitar.
Recuerde que el tiempo del sistema refleja lo que experimenta el usuario, no lo que el usuario puede utilizar.
No use la memoria dinámica, es un mal comportamiento que un programa se bloquee debido a algo que otro proceso está haciendo o para causar pérdidas de memoria.
Preste atención a la gravedad de la pantalla, al menos hasta el punto de voltear el dispositivo 180 ‘, porque los cables de alimentación son terriblemente frágiles.
No olvide permitir que los usuarios salgan, y no asuma que lo harán limpiamente.
Recuerde utilizar valores predeterminados razonables, especialmente para los tiempos de espera.
No asumas que nada se predetermina automáticamente.
Verifique los datos que ingresan, sin importar la fuente, para asegurarse de que los búferes no se desborden.
No deje datos confidenciales, como contraseñas, en la memoria más de lo absolutamente necesario.
Pruebe el código a fondo, los usuarios superarán a cualquier desarrollador y eso puede bloquear todo el dispositivo.
No asuma que otros desarrolladores pueden escribir código limpio, usar bloqueos y verificar códigos de retorno.
Recuerde que diferentes teléfonos / tabletas funcionan a diferentes velocidades.
No bloquee la preferencia más de lo absolutamente necesario, preferiblemente de ninguna manera.
Permita que los usuarios intenten ejecutar la aplicación varias veces.
No utilice llamadas a funciones que “bloqueen” (deje de ejecutar las cosas hasta que ocurra algún evento). Son malos juju.
Poner compacidad primero, velocidad segundo. Agrega tiempo pero resta dolores de cabeza.
No escriba la versión milmillonésima de algo de lo que todos están cansados, a menos que haya una recompensa especial por eso.
Por último, los gráficos. Siempre verifique la resolución real de la pantalla, nunca suponga que tiene una paleta de colores decente y recuerde que otras aplicaciones pueden tomar la pantalla física u otros canales de E / S como el sonido.
Con la excepción de la compacidad que tiene prioridad absoluta y la prohibición absoluta de la memoria dinámica, absolutamente todo esto debería ser riguroso para toda la programación, ya sea que esté buscando escribir un juego para un Kindle, un competidor de Windows, un enrutador de Internet, un marcapasos controlado por computadora (aunque probablemente no tenga que preocuparse demasiado por los gráficos allí) o un rival de Google.
La compacidad solo tiene prioridad en los sistemas integrados (enrutadores, marcapasos, ese tipo de cosas) y otros dispositivos con memoria muy limitada y sin medios para cambiar a / desde un dispositivo de almacenamiento más grande. De lo contrario, desea una compacidad suficiente para asegurarse de que su codificación sea correcta, ni más ni menos.
La memoria dinámica nunca debe usarse en tales sistemas y debe usarse con moderación en sistemas que hacen MUCHO (es una fuente importante de fallas de seguridad y otros tipos de errores de programación, y puede provocar que un programa incorrecto provoque el bloqueo de uno correcto impredecible – cosas realmente desagradables). Si necesita usarlo, hay asignadores alternativos que usan un grupo preasignado. No es perfecto, pero está a salvo de interferencias y generalmente es más rápido.
