Todos tendrán un proceso diferente para el desarrollo.
Soy un tipo de abajo hacia arriba, especialmente por agregar características. Agregar características es lo que he estado haciendo últimamente, así que así es como trabajo para agregar una sola característica:
Si hay datos persistentes involucrados, comienzo con el diseño del esquema de datos y la actualización de la base de datos para manejar los datos.
- ¿Qué error se debe evitar en el desarrollo de aplicaciones móviles en un nivel inicial?
- ¿Cuál es la mejor agencia de desarrollo de aplicaciones móviles en Chicago?
- ¿Cuáles son las mejores estrategias de prueba para aplicaciones móviles con las que puede ahorrar tiempo sin comprometer la calidad de una prueba?
- Cómo cambiar de un desarrollador de aplicaciones móviles a un desarrollador de back-end
- ¿De qué maneras podemos obtener nuevas ideas de aplicaciones móviles?
Entonces podría ir a las pantallas. En Android puede definir pantallas en archivos de diseño XML, además de que Android Studio tiene un editor de diseño WYSIWYG. (Aunque normalmente hago toda mi edición en modo de texto y vuelvo al modo WYSIWYG solo para ver cómo se ven mis cambios).
Ahora es el momento de escribir un código. La mayoría de las características que agrego tienen al menos un tipo de solicitud / respuesta de datos remotos. Primero tengo que asimilar la estructura de la respuesta JSON a una solicitud, y generalmente codifico una clase que representa los datos de la solicitud, luego codifico un método estático para tomar un JsonReader que envuelve el flujo de entrada HTTP y genera una instancia de la clase, con todos los datos completados. Para estructuras de datos más grandes, prepararé una prueba JUnit para leer en un archivo JSON de muestra y ejecutaré el método para asegurarme de que esa parte esté funcionando.
A continuación, tengo una clase singleton llamada Servicio que encapsula la interfaz con el servidor remoto. Agrego un método al Servicio para formatear los parámetros en una solicitud y llamar a ese método estático en la respuesta para devolver el objeto de datos.
Luego tengo que lidiar con el manejo de la solicitud y la respuesta de forma asincrónica. Codificaré una subclase AsyncTask o AsyncTaskLoader para tomar los valores de los parámetros y llamar al método Service en un subproceso en segundo plano, y luego devolver los valores en el subproceso de la interfaz de usuario. Por lo general, creo una interfaz que la persona que llama implementará para recibir asincrónicamente los datos de respuesta. Esta interfaz tiene dos métodos: un método de éxito normal y un método de excepción. La persona que llama siempre tendrá alguna forma de manejar con gracia cualquier problema que ocurra con el acceso al servidor remoto.
Finalmente es hora de escribir el código de la interfaz de usuario. Por lo general, creo una subclase de Fragment que maneja todas las entradas del usuario y llama a la subclase AsyncTask. Aquí pienso en guardar / restaurar el estado de la interfaz de usuario (para rotaciones de dispositivos) y las ramificaciones de la navegación hacia adelante a una nueva pantalla, luego hacia atrás nuevamente (especialmente cuando la pantalla posterior podría tener interacción del usuario que actualiza esta pantalla).
Realmente es bastante al revés, y significa que tengo que depurar el código de la interfaz de usuario, el código AsyncTask y el código de servicio, todo a la vez. Pero para mí resulta ser más rápido que escribir una gran cantidad de código desechable para eliminar cosas de nivel inferior.
Eventualmente espero llegar al punto en el que tenga el lujo de hacer más TDD y proponer todas las pruebas unitarias junto con el código.
Así que esta es una forma ágil. Si estaba buscando un proceso de alto nivel para requisitos o diseño, todo lo que puedo decir es que soy más productivo cuando me concentro en una función a la vez, la elimino y paso a la siguiente.
