¿Cómo convertirse en un buen desarrollador de Android?
Fácil de interactuar con el hardware, incluidas cámaras, GPS, etc.
Tiene su propio runtime y máquina virtual, excelente gestión de memoria.
Proporcione controles de interfaz enriquecidos para que los utilicen los desarrolladores, lo que permite el desarrollo visual y garantiza una interfaz de aplicación coherente en la plataforma Android.
Proporciona un mecanismo ligero de comunicación entre procesos.
Soporta aplicaciones de servicios en segundo plano sin interfaces.
Admite métodos de acceso a datos rápidos y eficientes.
Con todas estas características, no será demasiado difícil intentar desarrollar aplicaciones en Android. De hecho, los desarrolladores con un poco de experiencia en Java pueden comenzar rápidamente con el desarrollo de Android. El núcleo del desarrollo siempre se ha centrado en varias funciones importantes de los teléfonos Android, incluidas pantallas táctiles, cámaras, módulos GPS, funciones de Internet, entrada de voz, cuentas de Google, etc. Vale la pena señalar que si un ingeniero J2ME quiere cambiar a Android, pagará un precio mucho mayor que un ingeniero J2SE o J2EE. Después de todo, Android soporta un subconjunto casi completo de J2SE, mientras que J2ME es demasiado débil.
Además de Java, existen muchos lenguajes que admiten el desarrollo de Android, el más familiar es Scala. Como lenguaje subyacente del propio Android, no se puede ignorar el papel de C/C++. . En la comunidad de código abierto actual, ha habido algunos débiles que han intentado hacer que haya más lenguajes disponibles para desarrollar aplicaciones de Android. Koushik Dutta es uno de los representantes. Ha resuelto el problema de permitir que Dalvik llame al código Mono en la plataforma Mono. Quizás en un futuro cercano, todos los lenguajes bajo .NET podrán ejecutarse en Android a través de Mono, lo cual vale la pena esperar.
El idioma ya no es un problema, entonces ¿cuál es el problema? Mucha gente podría decir "experiencia". Es cierto que la experiencia determina la rapidez y la fluidez con la que los desarrolladores completan su trabajo, así como la solidez del software, la cantidad de errores, el nivel de calidad y la cantidad de trabajo necesario para solucionarlos. Pero no creo que nada de eso importe. Incluso un recién llegado a la industria de Android puede completar un proyecto mientras busca documentación, aunque la eficiencia puede ser baja. En Android, casi no hay cuellos de botella en las habilidades de desarrollo. ¿Dónde está entonces el cuello de botella? De hecho, después de utilizar una gran cantidad de software, descubrirá que muchos de ellos no son fáciles de usar. Muchos usuarios no están dispuestos a utilizar un determinado software, no porque no tenga contenido técnico o no pueda satisfacer sus necesidades. La razón es simple: no es fácil de usar.
La experiencia del usuario es superior a la tecnología. Se puede decir que una excelente experiencia de usuario tendrá el efecto de obtener el doble de resultado con la mitad de esfuerzo, entre un montón de software similar, el que tiene el mayor volumen de descargas. debe ser el que los usuarios se sientan más cómodos de usar, incluso si la funcionalidad no es mejor que la de otros productos, o incluso un poco peor. He visto a muchos desarrolladores que consideran la tecnología como su responsabilidad y solo se centran en investigarla. Piensan que el software con excelente tecnología será bien recibido por los usuarios. Incluso agregan varios efectos 3D magníficos y deslumbrantes a un juego móvil. Todos estos son buenos, pero a los usuarios reales no les gustarán. En las aplicaciones móviles, la simplicidad es lo que los usuarios quieren ver. Imagínese, cuando juega un juego de rol en un teléfono móvil, si está lleno de magníficos efectos 3D, no podrá ingresar a la siguiente operación. Es cierto que las imágenes hermosas son fáciles de atraer a la gente, pero detrás de esta belleza, llevarán a los usuarios y desarrolladores directamente al abismo, y no hay forma de mirar atrás. El resultado final es que los usuarios abandonan por completo el juego. y desarrolladores u operadores No puedes ganar dinero en absoluto.
En el proceso de desarrollo de plataformas móviles, la experiencia del usuario se ha convertido en una prioridad absoluta, y es probable que los usuarios sólo acepten el diseño centrado en el usuario. A continuación se muestran algunos ejemplos típicos.
La imagen de la izquierda es la interfaz clásica de Windows Mobile 6.1, que se ha promocionado desde el lanzamiento de Windows Mobile como un portal rico que contiene todas las funciones comunes y es muy consistente con las necesidades reales de los usuarios. . Quizás en ese momento, una interfaz de este tipo satisfacía algunas de las necesidades de los usuarios, pero hoy en día, un diseño de este tipo sólo puede describirse como algo alejado de los usuarios. Cada elemento tiene una altura demasiado pequeña, por lo que es necesario hacer clic con un bolígrafo o una uña. Los tres iconos situados en la esquina inferior derecha pueden resultar difíciles de alcanzar con las uñas. Utilizar un bolígrafo supone ocupar una mano más del usuario y la experiencia cae en picado. En un momento en el que los usuarios quieren liberar sus oídos, ¿cuál es el concepto de ocupar una mano extra? Esto significa que los usuarios no pueden sujetarse los apoyabrazos ni llevar bolsas cuando viajan en el automóvil. Además, al operar un teléfono móvil, tener una mano libre te brinda más oportunidades para hacer frente a emergencias, y ocupar las dos manos del usuario es realmente innecesario. Se puede decir que la experiencia de usuario de Windows Mobile es bastante mala. Afortunadamente, Microsoft ha realizado grandes mejoras en la interfaz del nuevo Windows Phone 7 y no repite los mismos errores.
Mirando hacia atrás en el enfoque de Android, la interfaz de Windows Phone 7 parece simple y clara en comparación con el Windows Mobile anterior, se puede decir que es insulsa e incluso fea a los ojos de algunas personas. Aún así, es bastante funcional, con íconos grandes e íconos muy espaciados. Esto significa que los usuarios pueden tocar con los dedos un área relativamente grande, lo que reduce la posibilidad de error.
Aunque la forma de tocar la pantalla también está relacionada en parte con el material de la pantalla, por ejemplo, las pantallas resistivas solo pueden usar un lápiz o una uña, mientras que las pantallas capacitivas pueden usar las yemas de los dedos, y algunas de ellas pueden También admite multitáctil. Para los usuarios comunes, parece ser más común usar las puntas de los dedos que las uñas. La razón es simple. Si el ícono es grande, el usuario hará clic inconscientemente con la punta de los dedos, y si el ícono es pequeño, el usuario hará clic con la punta de los dedos. Dóblelo y toque la pantalla con la uña. Esta acción de "doblar los dedos" es inaceptable para la mayoría de los usuarios. Por tanto, las pantallas capacitivas se irán popularizando poco a poco, mientras que las pantallas resistivas se irán eliminando poco a poco. Esta es la supervivencia del más apto basada en la experiencia del usuario, que es una cuestión muy evolutiva.
La experiencia del usuario no se refiere solo a la interfaz. Como teléfono móvil, cada función será parte de la experiencia del usuario y podrá ser aprovechada. Por ejemplo, si hay un teclado, si es compatible con multitáctil, etc. Para los teléfonos móviles con teclado y los teléfonos móviles sin teclado, la cooperación del usuario al realizar gestos de la máquina seguramente será diferente. Uno se centra en la parte inferior del cuerpo, que es el teclado, mientras que el otro se centra en toda la pantalla. Es decir, los dedos pueden moverse en cualquier posición de la pantalla. También es muy necesario diseñar programas de acuerdo con las condiciones específicas del dispositivo. El marco diseñado actualmente por Google para Android para cambiar automáticamente el diseño según el tamaño de la pantalla es muy útil. Cambia el proceso de programación anterior, que requería compilar uno por separado. programa para cada versión del dispositivo, o simplemente extendiéndose para diferentes pantallas. Además, al diseñar se debe tener en cuenta la experiencia operativa real, como por ejemplo si se utiliza el botón de zoom o la función multitáctil al ampliar una imagen. Ambas prácticas son comunes, pero una no puede usarse sola en aplicaciones que lo requieran. Un mejor enfoque es determinar en el código del programa si el dispositivo admite multitáctil y, si no lo admite, mostrar el botón de zoom. Si lo hace, aparece un recordatorio de Toast cuando se inicia la aplicación por primera vez para informar al usuario. que pueden hacer zoom a través de la imagen multitáctil.
Para obtener más información sobre el diseño de la interfaz de la aplicación, consulte las dos capturas de pantalla siguientes.
Ambas aplicaciones son emuladores de consola de Android. La imagen de arriba es el simulador de PS. Puede ver que el diseño de las teclas virtuales es un poco extraño, especialmente L y R. Es difícil adaptarse al diseño uno arriba, uno abajo. El de la derecha es el emulador GBA. Puede ver que el diseño de sus botones es bastante satisfactorio y los usuarios pueden comenzar de inmediato. Sin embargo, desde una perspectiva práctica, el emulador GBA es realmente simple, pero desde una perspectiva práctica, el emulador PS hace un mejor trabajo. ¿Por qué? La razón es simple: el emulador de PS utiliza toda la pantalla y el diseño de las teclas virtuales evita que las dos manos peleen y que la mitad inferior de la pantalla sea completamente invisible debido a los dedos. Después de un período de adaptación, el emulador de PS se puede jugar hasta el final.
El emulador de GBA solo puede usar la mitad de la pantalla y aún está vertical. Cuando se opera con las dos manos, las dos manos pueden pelear e interferir fácilmente entre sí, lo que hace que sea casi imposible jugar algunos juegos con movimientos un poco más grandes. Aunque parezca intuitiva y fácil de entender, los usuarios abandonarán dicha interfaz de usuario.
En las plataformas móviles, hasta ahora, los usuarios aún no tienen hábitos operativos fijos. Lo que los desarrolladores de software tienen que hacer es guiar a los usuarios para que obtengan una experiencia operativa simple y clara, para que puedan aprender a usar el software. Deje que se acostumbren y se vuelvan buenos en una o más operaciones. En cierto sentido, el manual de diseño de Apple resuelve muy bien este problema. El iPad facilita el inicio a personas de mediana edad y mayores, e incluso los gatos pueden jugar con él. Pero al menos hasta ahora, Android no tiene un manual de diseño. Los desarrolladores y proveedores de software diseñan cada uno su software según sus propias ideas, y los usuarios tienen que adaptarse a diferentes estilos cuando utilizan diferentes software.
La experiencia del usuario de las aplicaciones de Android (especialmente los juegos) será el foco de investigación en el próximo periodo. Debido a algunas limitaciones de Android, es difícil para los desarrolladores lograr los magníficos efectos de los juegos de PSP, por lo que solo pueden trabajar en la jugabilidad del juego en sí. Por supuesto, cuando el rendimiento de los teléfonos Android mejore enormemente nuevamente y la capacidad de la batería aumente considerablemente, tal vez haya juegos magníficos que puedan rivalizar con los juegos de PSP, pero por ahora, no pienses demasiado en eso.
Como mencioné en algunos artículos anteriores, el desarrollo para plataformas móviles debe considerar tanto la arquitectura como la eficiencia de ejecución del programa, debido a que la configuración de la plataforma móvil en sí no suele ser alta, por lo que es importante para optimizar el rendimiento con configuraciones limitadas. Desde otra perspectiva, la capacidad del iPhone para utilizar configuraciones más bajas para lograr un funcionamiento fluido de la máquina también se beneficia de una optimización específica más estricta para aprovechar al máximo el rendimiento de la plataforma de hardware. El resultado de esto es que el rendimiento general del iPhone parece ser mejor que el del iPhone. Algunos teléfonos móviles con configuraciones superiores.
Por último, hablemos brevemente de las similitudes y diferencias entre el desarrollo para Android y el desarrollo para otras plataformas. Sabemos que diferentes métodos de desarrollo tendrán diferentes impactos en el resultado final. A juzgar por la experiencia pasada, las herramientas de desarrollo de varios fabricantes se están desarrollando en la dirección de la visualización, por ejemplo, Visual Studio de Microsoft tiene funciones más potentes con cada generación y el grado de visualización es cada vez mayor. Lo mismo ocurre con Xcode de Apple, que recomienda que los usuarios utilicen soluciones totalmente visuales para resolver problemas de aplicaciones. Todo esto es bueno, pero también trae muchos problemas. Como ejemplo simple, digamos que tiene una aplicación de Windows Mobile con un ListBox y está intentando agregar un ícono a ese ListBox y cambiar el color del texto según el contenido de cada elemento. ¿Puedes hacerlo? Por supuesto que puedes, pero no es un proceso sencillo y hay que pasar por un complejo proceso de autopintura para lograrlo. Este es un problema común en el desarrollo RAD normal, donde los desarrolladores no tienen fácil acceso a todos los detalles de la aplicación. La encapsulación de API mediante marcos de desarrollo mejora la eficiencia del desarrollo hasta cierto punto, pero en otra medida bloquea demasiados detalles que los desarrolladores pueden necesitar.
Aunque Android también tiene un entorno de desarrollo visual, sus funciones son muy débiles y las soluciones RAD de terceros siguen siendo débiles hasta el momento. Para aquellos usuarios que están acostumbrados a entornos RAD avanzados de empresas como Microsoft. Pueden ser vistos con desesperanza y desprecio, entonces, ¿cuál es el punto de esta visualización? Si solo lo miramos desde la perspectiva del desarrollador, hay ventajas y desventajas. La desventaja es obviamente que la eficiencia del desarrollo no es lo suficientemente alta. De hecho, dado que Android se desarrolla utilizando el lenguaje Java, su eficiencia de desarrollo en sí no será demasiado alta. alto. En cuanto a las ventajas, es posible que a muchos ingenieros superiores les guste porque es un modelo que sacrifica la eficiencia del desarrollo a cambio de una máxima personalización. A algunos amigos que recién comienzan a aprender el desarrollo de Android les puede resultar inconveniente crear interfaces, pero mientras estudien en profundidad, sentirán que la implementación de la interfaz de Android es muy avanzada. Tomando el ListBox anterior como ejemplo, en Android, puede personalizar las funciones de ListItem y el Adaptador relacionado a través de un conjunto de códigos cortos y concisos.
Creo que los buenos desarrolladores deberían abandonar RAD por completo; en el entorno actual, RAD es de poca utilidad y puede ser un gran obstáculo para la estratificación de aplicaciones. En un entorno RAD, ¿cómo es posible pedir a los desarrolladores que cubran cada parte del software? Por ejemplo, la interfaz del software debe ser diseñada por expertos en interfaz de usuario y la parte de la base de datos debe entregarse a la persona responsable correspondiente. Es imposible que un desarrollador la maneje solo de principio a fin. Si el jefe contrata a un súper desarrollador para hacer todo, a menos que esa persona tenga 100 años de experiencia, el proyecto está condenado. Creo que el marco de desarrollo de Android ilustra muy bien este problema. Los recursos del programa (incluidas imágenes, cadenas, otros datos externos, etc.) están completamente separados del código. Los empleados realizan sus tareas y completan todo el proyecto sin ejercer demasiada presión sobre los empleados de cada departamento. Además, debido a que Android usa XML para describir la interfaz, es muy fácil reemplazar la interfaz. Los diseñadores pueden diseñar múltiples conjuntos de interfaces, lo cual es muy conveniente ya sea para evaluar un programa de interfaz de usuario o cambiar el estilo de la interfaz en aplicaciones reales. Este no es el caso de otras plataformas móviles.