Closed franyack closed 6 years ago
En los siguientes commits: b5129421f751dae2a7264fe43d98e24aa82c25e3 y 4185e1e722bb758bd820d1d80fa8247c9e2225e5 se aplicaron los cambios recomendados. En principio funciona de manera correcta, pero el motor de procesamiento sigue trayendo problema con los hilos de ejecución.
Dale está perfecto lo que planteás, una vez que se solucione #1 vamos a tener libertad de crear cuantas activities se necesiten, así que aprovechemos este espacio para ir pensando cuantas serían necesarias. Por ahora:
Para meter más estilos a la app, agrego este tutorial simple que me pareció que podría ser útil: https://codelabs.developers.google.com/codelabs/material-design-style/index.html?index=..%2F..%2Findex#0
Primero de todo revisé y seguí el tutorial que compartiste acá arriba Lea, la verdad que se pueden sacar ideas muy buenas! Por ejemplo, mostrar el resultado del motor o el resultado final (las diferentes carpetas) tal como se hace en la parte de RecycleView. También se me ocurrió que para la pantalla donde se inicia la app podemos sugerirle al usuario procesar la carpeta de las fotos de la cámara, la de WhatsApp imágenes o todas usando una especie de RadioButtons. Por ejemplo:
Esto dependerá de si todos los dispositivos tienen el mismo path para este tipo de carpetas o si se puede obtener de alguna manera mediante una variable (estoy casi seguro que el de las fotos de la cámara si, no tanto con el de WhatsApp imágenes).
Segundo voy a proponer la cantidad de activities que yo creo que debería tener la app. Tomando como parámetro el diagrama de casos de uso que definimos en la ERS:
Entiendo que la app debería tener 5 activities, las cuales serían:
Activity 1: inicial, elección de directorios a procesar.
Activity 2: aquel dónde se ejecuta el motor y se le avisa al usuario que la aplicación está trabajando.
Activity 3: el del resultado del procesamiento, ofreciéndole al usuario los diferentes ABMs para poder administrar el resultado a su gusto.
Activity 4: dónde se le indica al usuario dónde y cómo se guardarán sus imágenes, y se le da la opción de confirmar el resultado final o descartarlo.
Activity 5: el final, dónde se le da la opción al usuario de volver a procesar un grupo de imágenes o salir de la App.
Obviamente esto es mi opinión y es totalmente discutible. Me gustaría saber que piensan ustedes con respecto a esta propuesta, si agregaría o sacarían algo, etc.
Excelente definición! Algunos comentarios nomás:
Una vez definido eso, me parece que está perfecto como para ya implementarse!
Esto ya estaría definido? Se necesita alguna revisión? Veamos eso así ya se puede cerrar
Perdón, pero se me había pasado el último comentario.
Con respecto al primer punto, tenes toda la razón. No le veo tampoco sentido, lo había hecho/propuesto siguiendo el curso que había realizado en YouTube, pero ahora no creo que sea necesario. Así que si, opino como vos y se debería remover.
Con respecto al punto 2, también creo que se podría resolver directamente en la A3, donde el user puede ir confirmando los resultados a medida que va terminando de administrar las carpetas resultantes.
Por lo tanto y en resumen, de momento la app debería tener estas activities para interactuar con el usuario:
Activity 1: inicial, elección de directorios a procesar. Ejecución del motor y aviso de que la app está procesando.
Activity 2: el del resultado del procesamiento, ofreciéndole al usuario los diferentes ABMs para poder administrar el resultado a su gusto. Además, el usuario podrá decidir donde se guardará cada una de las carpetas según su preferencia.
Activity 3: el final, dónde se le da la opción al usuario de volver a procesar un grupo de imágenes o salir de la App.
Genial por mi! Me convence ese esquema, así que empecemos con eso al menos y luego vemos lo que surja para agregar activities o extender las que tenemos. Cuando tengamos unos screenshots de cada una (como para que quede visible lo que tiene cada una), los ponemos acá y cerramos este issue.
Me parece bien a mi también. Lo único que no sé que es ABMs jajaja 😁
Dr. Leandro Daniel Vignolo Assistant Professor | Assistant Research Scientist sinc(i), FICH-UNL/CONICET, Santa Fe, Argentina www.sinc.unl.edu.ar | Tel: +54 (342) 4575233 ext 117
On Thu, May 24, 2018 at 5:44 PM, Leandro Ferrado notifications@github.com wrote:
Genial por mi! Me convence ese esquema, así que empecemos con eso al menos y luego vemos lo que surja para agregar activities o extender las que tenemos. Cuando tengamos unos screenshots de cada una (como para que quede visible lo que tiene cada una), los ponemos acá y cerramos este issue.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/franyack/IMachineApp/issues/3#issuecomment-391853381, or mute the thread https://github.com/notifications/unsubscribe-auth/APJ-GxJPpkfgZermhZ8rj1zjNYbfzy9sks5t1xu_gaJpZM4TDj-i .
Jajaja! ABM's (Agregar, Borrar y Modificar) son los típicos menúes que aparecen en la mayoría de aplicaciones y sistemas que le permiten a los usuarios administrar la información que están utilizando!
@franyack Cuando tengas los screenshots que vas a subir en el informe final, pegalos tmb acá así ya cerramos este issue
Dale Lea, acá van diferentes screenshots según cada activity propuesta:
Excelente! Podemos cerrar este issue y luego seguimos en otro lo que quede iterar sobre los activities
Una cuestión que surge es la de definir cuantas activities tendrá la aplicación una vez que esté terminada, afín de poder realizar mocks en esta etapa y simplemente ir completando a medida que va avanzando el desarrollo. Volviendo al curso de desarrollo de aplicaciones android que realice por Youtube (https://www.youtube.com/playlist?list=PLU8oAlHdN5Bkn-KS1sRFlSEnXXcAtAJ9P - Preferentemente video 1 y 2, y luego saltarse al video 30, 31 y 32) y a modo de resumen se explican los siguientes conceptos sobre los diferentes componentes que tiene una App:
Vistas (View): elementos que componen la interfaz de usuario -> Descendientes de la clase View
Layouts: Conjunto de vistas agrupadas de una determinada forma. Ej: RelativeLayout, LinearLayou, etc... -> Descendiente de la clase View
Activity: diferentes pantallas que van surgiendo a medida que transcurre el uso de la aplicacion -> Descendiente de la clase Activity
Servicios: procesos que se ejecutan en segundo plano. No es necesaria la interacción con usuario
Intent: voluntad, intención de realizar una acción (Evento)
El autor del curso hace referencia a que se deben definir tantas actividades como pantallas(layouts) uno imagina que tendrá la app. Entonces, lo que se hace es desde el activity en donde se encuentra la aplicación y a través de un objeto Intent comenzar la nueva actividad y desde el constructor de dicha actividad llamar al método que lanza el nuevo layout y rescatar los datos enviados desde la actividad anterior a través de objetos tipo Bundle según corresponda.
Entiendo que estas serían buenas prácticas a tomar desde este punto ya que haría al código mucho mas limpio y entendible, respetando los fundamentos del desarrollo de aplicaciones Android. A su vez, quizás podría solucionar el primer issue definido donde la función nativa utilizada para llamar al motor de procesamiento no respeta el hilo de ejecución de la app.
Lo que voy a hacer es dejar en el master la aplicación tal cual se encuentra, y en un branch aplicar los cambios recomendados por el curso. En caso de que todo funcione correctamente, se hace el correspondiente merge.