Paso a paso explico como estructurar nuestros proyectos para ir solucionando y separando problemas para ver finalmente como la foto general de lo que hemos montado coincide con los principios de Clean Architecture y como esto nos ayuda a construir un software más solido, extensible y refactorizable.
Tras tres años programando en la plataforma Android esta es la película de mi vida como Android Developer, un conjunto de buenas practicas y conceptos necesarios que aún a día de hoy sigo viendo que no se cumplen en la mayoría de proyectos con los que me cruzo. Son la conclusiones sacadas de mi experiencia y de multitud de debates con compañeros. Se abordan temas como: fragmentación, uso de la clase Context, naming, maquetación en Android, memory leaks y S.O.L.I.D.
Slides utilizadas en charla a alumnos de Ingeniería del Software en la Escuela Politécnica de Gijón sobre:
- Necesidad de testing
- Problemas dentro de un proyecto
- Automatización de pruebas con Seleniun
Esta es la presentación que he preparado para mis compañeros de @NITSNETS en la que explico la integración del testing a todos los niveles de un proyecto y profundizo un poco más en la aplicación práctica para un entorno basado en Laravel.
Este documento presenta OpenAPI 3.0.2 como estándar para documentar APIs de forma interoperable. Explica cómo OpenAPI puede usarse para documentar APIs existentes, definir contratos de API antes de implementarlas, o generar documentación a partir de servicios existentes. También cubre herramientas de OpenAPI, casos de uso comunes, y tendencias como la adopción del estándar por gobiernos y empresas para promover la interoperabilidad.
App Inventor es una herramienta desarrollada por Google que permite crear aplicaciones para Android sin necesidad de escribir código. Usa una interfaz gráfica donde los usuarios arrastran y sueltan componentes visuales para construir una aplicación. Fue creada originalmente por Google pero ahora es mantenida por el MIT. Permite a cualquier persona crear apps de forma intuitiva y sin líneas de código.
Paso a paso explico como estructurar nuestros proyectos para ir solucionando y separando problemas para ver finalmente como la foto general de lo que hemos montado coincide con los principios de Clean Architecture y como esto nos ayuda a construir un software más solido, extensible y refactorizable.
Tras tres años programando en la plataforma Android esta es la película de mi vida como Android Developer, un conjunto de buenas practicas y conceptos necesarios que aún a día de hoy sigo viendo que no se cumplen en la mayoría de proyectos con los que me cruzo. Son la conclusiones sacadas de mi experiencia y de multitud de debates con compañeros. Se abordan temas como: fragmentación, uso de la clase Context, naming, maquetación en Android, memory leaks y S.O.L.I.D.
Slides utilizadas en charla a alumnos de Ingeniería del Software en la Escuela Politécnica de Gijón sobre:
- Necesidad de testing
- Problemas dentro de un proyecto
- Automatización de pruebas con Seleniun
Esta es la presentación que he preparado para mis compañeros de @NITSNETS en la que explico la integración del testing a todos los niveles de un proyecto y profundizo un poco más en la aplicación práctica para un entorno basado en Laravel.
Este documento presenta OpenAPI 3.0.2 como estándar para documentar APIs de forma interoperable. Explica cómo OpenAPI puede usarse para documentar APIs existentes, definir contratos de API antes de implementarlas, o generar documentación a partir de servicios existentes. También cubre herramientas de OpenAPI, casos de uso comunes, y tendencias como la adopción del estándar por gobiernos y empresas para promover la interoperabilidad.
App Inventor es una herramienta desarrollada por Google que permite crear aplicaciones para Android sin necesidad de escribir código. Usa una interfaz gráfica donde los usuarios arrastran y sueltan componentes visuales para construir una aplicación. Fue creada originalmente por Google pero ahora es mantenida por el MIT. Permite a cualquier persona crear apps de forma intuitiva y sin líneas de código.
This document discusses clean architecture, which aims to separate an application into distinct layers. The core application logic is separated from the user interface and database access. This improves testability and flexibility. Some benefits of clean architecture include excellent testability since each component can be tested in isolation, clearly defined separation of concerns, and flexibility to change parts of the application independently. However, there are also costs like increased complexity with more classes and data conversions between layers.
This document discusses clean architecture principles for Android applications. It outlines goals of having an architecture that is focused on use cases, easy to maintain and test, and decoupled. It describes layers including entities, use cases, interface adapters, frameworks/drivers, presentation layer, and data layer. It emphasizes separating domains, business rules in their own layer, and testing at different levels. Tools mentioned include dependency injections, Proguard, and Lint.
Este documento compara las bibliotecas Volley y Retrofit para realizar solicitudes HTTP en Android. Volley permite realizar solicitudes de forma sencilla con callbacks de éxito y error, mientras que Retrofit mapea la interfaz de una API REST a una clase Java. Aunque Volley es más intuitivo para manejar respuestas, Retrofit es una herramienta más completa que requiere algunas configuraciones iniciales pero permite un manejo más sencillo de encabezados y parámetros. En general, ambas son buenas opciones pero cada una tiene ventaj
This document provides an overview of unit testing and isolation frameworks. It defines key concepts like units, unit tests, stubs, mocks and isolation frameworks. It explains that the goal of unit tests is to test individual units of code in isolation by replacing dependencies with stubs or mocks. It also discusses different isolation frameworks like Rhino Mocks and Moq that make it easier to dynamically create stubs and mocks without writing implementation code. The document covers different styles of isolation like record-and-replay and arrange-act-assert. It emphasizes best practices like having one mock per test and using stubs for other dependencies being tested.
UML allows for extending diagrams and modeling elements through three main techniques:
1. Stereotypes allow applying tags to existing modeling elements like classes, associations, etc. to add domain-specific meaning.
2. Profiles extend UML with new modeling elements tailored for specific domains or platforms.
3. Extension mechanisms allow precisely defining new constructs that integrate with the UML metamodel. Together these techniques make UML extensible for multiple domains.
This document describes a test-driven development exercise for practicing TDD principles and building a string calculator. It provides instructions for an activity to implement a method to add numbers in a string using TDD. It outlines 5 business rules for the string calculator including handling an unknown number of numbers, new line delimiters, negative numbers, custom delimiters. It also provides tips for completing the TDD exercise and 3 optional "extra rules" to extend the functionality.
This document outlines Pedro Gomez's presentation on clean architecture and software design principles at the Karumi Dojo. It introduces clean architecture concepts like separation of concerns using layers and independence from frameworks. It then discusses how Karumi applies these principles using patterns like Model-View-Presenter and dependency injection. The document concludes by introducing a sample Kata Contacts app to practice these techniques.
Data binding is a process that establishes a connection between an application's UI and its business logic so that when data changes, it is reflected in the UI and vice versa. Android introduced data binding in 2015 to minimize glue code between layouts and logic. The key steps to using data binding are: 1) adding the data binding library, 2) applying binding to layouts, 3) creating data binding objects, and 4) doing the binding in activities/fragments. Data binding supports observable objects to automatically update views when data changes. It allows binding layout properties like visibility and text fields.
This document outlines an agenda for a Karumi Dojo session on property based testing. It introduces property based testing tools like JUnit-QuickCheck and SwiftCheck and provides instructions for a Maxibon kata exercise to practice writing property based tests in Java and Swift. Attendees will work through writing tests that check properties of a Maxibon model, using randomly generated inputs to stress the code under test. Tips are provided like starting with simple tests and logging input values. Resources like sample code repositories are also referenced.
This ppt is based on the book "Clean Code" written by Robert C Martin. It's a wonderful book and cover all the mistakes that we do while writing bad code. I am sharing few good practices shared in the book, hope you will like it
The document discusses the use of Retrofit, a type-safe REST client for Android and Java. It shows examples of defining API interfaces with Retrofit annotations, setting up Retrofit with a Retrofit builder, making requests both synchronously and asynchronously, handling responses and errors, canceling requests, and using interceptors and converters with Retrofit and OkHttp. Key aspects covered include setting the base URL, adding interceptors for logging and authentication, and using the LoganSquare converter for JSON parsing.
Is Activity God? ~ The MVP Architecture ~Ken William
The document discusses the Model-View-Presenter (MVP) architectural pattern for Android development. It begins with an introduction of the author and agenda. It then explains some issues with using just an Activity class, such as multiple threads and spaghetti code. MVP is presented as an alternative, with the model/data, use case/business logic, presenter/adapter, and view/UI layers separated and not communicating directly. Finally, pros and cons of MVP like maintainability and testability versus redundancy are discussed, along with concluding that MVP is one of several possible solutions.
This document outlines Pedro Gómez Sánchez's presentation on developing a world-class testing pipeline for Android applications. It discusses developing testable code through principles like dependency inversion and defining a testing pipeline to specify what to test (business logic, API integration, UI) and how (unit tests, integration tests, UI tests). Example code is provided for each type of test using tools like JUnit, Mockito, Robolectric and Espresso. The goal is to build trust in tests through an architecture and pipeline that facilitates isolated, repeatable testing.
A Separation of Concerns: Clean Architecture on AndroidOutware Mobile
Presented at YOW! Connected 2015 by Kamal Kamal Mohamed & Ryan Hodgman
As an Android developer, I want to deliver features without making compromises on code quality.
Scenario 1 - Given I am dealing with 1000+ line activities, When I have to develop a complicated feature, Then I waste time orienting myself and fixing bugs.
Scenario 2 - Given I have integrated a backend API directly into my app logic, When that API changes, Then I have to refactor large segments of unrelated logic in order to utilise the new API.
Scenario 3 - Given I have cleanly architected my application, When business/presentation/backend logic changes, Then I can easily update the relevant code without breaking unrelated features!
In this talk, two Android developers will present their take on what a cleanly architected app looks like and why it makes our lives easier. A well-defined separation of concerns has benefits not just for our sanity as developers, but also for the project workflow as it allows multiple developers to collaborate on a single feature with ease. We will be exploring how the domain-driven approach can improve code clarity, allow you to easily write tests, and provide a scalable infrastructure for you to quickly iterate on. Join us on our path of discovery as we discuss the advantages, drawbacks and implementation specifics in the context of a small sample project.
Este documento describe los pasos para crear una aplicación Android que se comunique con una base de datos a través de una API en PHP. Incluye información sobre las tecnologías necesarias como JSON, una aplicación Android e iOS, una base de datos y un servidor web con PHP. Además, explica el flujo general de la aplicación y los pasos para realizar peticiones HTTP, procesar datos JSON y almacenar registros en la base de datos.
Over the last year there has been a lot of buzz about Clean Architecture in the Android community, but what is Clean Architecture? How does it work? And should I be using it? Recently at Badoo we decided to rewrite our messenger component.
Over the years this core piece of functionality in our app has become large and unwieldy. We wanted to take a fresh approach to try and prevent this from happening again. We choose to use Clean Architecture to achieve our goal. This talk intends to share our journey from theory to implementation in an application with over 100 million downloads. By the end, you should not only understand what Clean Architecture is, but how to implement it, and whether you should.
Este documento describe diferentes taxonomías de arquitectura de software, incluyendo:
1) Big Ball of Mud, una arquitectura sin estructura donde los elementos están entrelazados;
2) Descomposición modular, que divide el software en módulos independientes con interfaces y cuerpos bien definidos;
3) Dependencias, donde un módulo utiliza o depende de otro módulo.
Android Clean Architecture for DummiesKengo Suzuki
Brief tutorial of implementing very primitive app(single list view) using Android Clean Architecture. It won't describe what and why, but rather, how to use it.
C# es un lenguaje de programación diseñado para generar aplicaciones en .NET Framework. Es un lenguaje orientado a objetos, tipado y seguro. Visual C# es la implementación de Microsoft de C# que ofrece compatibilidad completa con Visual Studio, incluido un editor de código, compilador, diseñadores y otras herramientas. C# ha evolucionado a través de varias versiones con nuevas características como genéricos, métodos anónimos y lambda expressions.
Chia sẻ về Clean Code tại XPDay Vietnam 2016.
Clean Code là gì?
Tại sao phải Clean Code?
Clean Code có khó không?
Một số ví dụ thực tế về áp dụng Clean Code.
El documento describe la metodología Iconix para el desarrollo de software. Iconix es una metodología iterativa e incremental que utiliza casos de uso y modelado de objetos. El documento explica las fases de Iconix, incluyendo el análisis de requisitos, análisis y diseño preliminar, diseño e implementación. También describe diagramas como el modelo de dominio, casos de uso y diagramas de secuencia utilizados en el proceso Iconix.
Este documento presenta un temario sobre interfaces de usuario en Android. Incluye secciones sobre introducción a Android, desarrollo con Android, interfaces de usuario con un ejemplo SobreTeleco, layouts, widgets, servicios, acceso a datos y bibliografía. También incluye objetivos de aprendizaje sobre conceptos básicos para desarrollar interfaces de usuario en Android como la estructura de proyectos, recursos, layouts y vistas.
This document discusses clean architecture, which aims to separate an application into distinct layers. The core application logic is separated from the user interface and database access. This improves testability and flexibility. Some benefits of clean architecture include excellent testability since each component can be tested in isolation, clearly defined separation of concerns, and flexibility to change parts of the application independently. However, there are also costs like increased complexity with more classes and data conversions between layers.
This document discusses clean architecture principles for Android applications. It outlines goals of having an architecture that is focused on use cases, easy to maintain and test, and decoupled. It describes layers including entities, use cases, interface adapters, frameworks/drivers, presentation layer, and data layer. It emphasizes separating domains, business rules in their own layer, and testing at different levels. Tools mentioned include dependency injections, Proguard, and Lint.
Este documento compara las bibliotecas Volley y Retrofit para realizar solicitudes HTTP en Android. Volley permite realizar solicitudes de forma sencilla con callbacks de éxito y error, mientras que Retrofit mapea la interfaz de una API REST a una clase Java. Aunque Volley es más intuitivo para manejar respuestas, Retrofit es una herramienta más completa que requiere algunas configuraciones iniciales pero permite un manejo más sencillo de encabezados y parámetros. En general, ambas son buenas opciones pero cada una tiene ventaj
This document provides an overview of unit testing and isolation frameworks. It defines key concepts like units, unit tests, stubs, mocks and isolation frameworks. It explains that the goal of unit tests is to test individual units of code in isolation by replacing dependencies with stubs or mocks. It also discusses different isolation frameworks like Rhino Mocks and Moq that make it easier to dynamically create stubs and mocks without writing implementation code. The document covers different styles of isolation like record-and-replay and arrange-act-assert. It emphasizes best practices like having one mock per test and using stubs for other dependencies being tested.
UML allows for extending diagrams and modeling elements through three main techniques:
1. Stereotypes allow applying tags to existing modeling elements like classes, associations, etc. to add domain-specific meaning.
2. Profiles extend UML with new modeling elements tailored for specific domains or platforms.
3. Extension mechanisms allow precisely defining new constructs that integrate with the UML metamodel. Together these techniques make UML extensible for multiple domains.
This document describes a test-driven development exercise for practicing TDD principles and building a string calculator. It provides instructions for an activity to implement a method to add numbers in a string using TDD. It outlines 5 business rules for the string calculator including handling an unknown number of numbers, new line delimiters, negative numbers, custom delimiters. It also provides tips for completing the TDD exercise and 3 optional "extra rules" to extend the functionality.
This document outlines Pedro Gomez's presentation on clean architecture and software design principles at the Karumi Dojo. It introduces clean architecture concepts like separation of concerns using layers and independence from frameworks. It then discusses how Karumi applies these principles using patterns like Model-View-Presenter and dependency injection. The document concludes by introducing a sample Kata Contacts app to practice these techniques.
Data binding is a process that establishes a connection between an application's UI and its business logic so that when data changes, it is reflected in the UI and vice versa. Android introduced data binding in 2015 to minimize glue code between layouts and logic. The key steps to using data binding are: 1) adding the data binding library, 2) applying binding to layouts, 3) creating data binding objects, and 4) doing the binding in activities/fragments. Data binding supports observable objects to automatically update views when data changes. It allows binding layout properties like visibility and text fields.
This document outlines an agenda for a Karumi Dojo session on property based testing. It introduces property based testing tools like JUnit-QuickCheck and SwiftCheck and provides instructions for a Maxibon kata exercise to practice writing property based tests in Java and Swift. Attendees will work through writing tests that check properties of a Maxibon model, using randomly generated inputs to stress the code under test. Tips are provided like starting with simple tests and logging input values. Resources like sample code repositories are also referenced.
This ppt is based on the book "Clean Code" written by Robert C Martin. It's a wonderful book and cover all the mistakes that we do while writing bad code. I am sharing few good practices shared in the book, hope you will like it
The document discusses the use of Retrofit, a type-safe REST client for Android and Java. It shows examples of defining API interfaces with Retrofit annotations, setting up Retrofit with a Retrofit builder, making requests both synchronously and asynchronously, handling responses and errors, canceling requests, and using interceptors and converters with Retrofit and OkHttp. Key aspects covered include setting the base URL, adding interceptors for logging and authentication, and using the LoganSquare converter for JSON parsing.
Is Activity God? ~ The MVP Architecture ~Ken William
The document discusses the Model-View-Presenter (MVP) architectural pattern for Android development. It begins with an introduction of the author and agenda. It then explains some issues with using just an Activity class, such as multiple threads and spaghetti code. MVP is presented as an alternative, with the model/data, use case/business logic, presenter/adapter, and view/UI layers separated and not communicating directly. Finally, pros and cons of MVP like maintainability and testability versus redundancy are discussed, along with concluding that MVP is one of several possible solutions.
This document outlines Pedro Gómez Sánchez's presentation on developing a world-class testing pipeline for Android applications. It discusses developing testable code through principles like dependency inversion and defining a testing pipeline to specify what to test (business logic, API integration, UI) and how (unit tests, integration tests, UI tests). Example code is provided for each type of test using tools like JUnit, Mockito, Robolectric and Espresso. The goal is to build trust in tests through an architecture and pipeline that facilitates isolated, repeatable testing.
A Separation of Concerns: Clean Architecture on AndroidOutware Mobile
Presented at YOW! Connected 2015 by Kamal Kamal Mohamed & Ryan Hodgman
As an Android developer, I want to deliver features without making compromises on code quality.
Scenario 1 - Given I am dealing with 1000+ line activities, When I have to develop a complicated feature, Then I waste time orienting myself and fixing bugs.
Scenario 2 - Given I have integrated a backend API directly into my app logic, When that API changes, Then I have to refactor large segments of unrelated logic in order to utilise the new API.
Scenario 3 - Given I have cleanly architected my application, When business/presentation/backend logic changes, Then I can easily update the relevant code without breaking unrelated features!
In this talk, two Android developers will present their take on what a cleanly architected app looks like and why it makes our lives easier. A well-defined separation of concerns has benefits not just for our sanity as developers, but also for the project workflow as it allows multiple developers to collaborate on a single feature with ease. We will be exploring how the domain-driven approach can improve code clarity, allow you to easily write tests, and provide a scalable infrastructure for you to quickly iterate on. Join us on our path of discovery as we discuss the advantages, drawbacks and implementation specifics in the context of a small sample project.
Este documento describe los pasos para crear una aplicación Android que se comunique con una base de datos a través de una API en PHP. Incluye información sobre las tecnologías necesarias como JSON, una aplicación Android e iOS, una base de datos y un servidor web con PHP. Además, explica el flujo general de la aplicación y los pasos para realizar peticiones HTTP, procesar datos JSON y almacenar registros en la base de datos.
Over the last year there has been a lot of buzz about Clean Architecture in the Android community, but what is Clean Architecture? How does it work? And should I be using it? Recently at Badoo we decided to rewrite our messenger component.
Over the years this core piece of functionality in our app has become large and unwieldy. We wanted to take a fresh approach to try and prevent this from happening again. We choose to use Clean Architecture to achieve our goal. This talk intends to share our journey from theory to implementation in an application with over 100 million downloads. By the end, you should not only understand what Clean Architecture is, but how to implement it, and whether you should.
Este documento describe diferentes taxonomías de arquitectura de software, incluyendo:
1) Big Ball of Mud, una arquitectura sin estructura donde los elementos están entrelazados;
2) Descomposición modular, que divide el software en módulos independientes con interfaces y cuerpos bien definidos;
3) Dependencias, donde un módulo utiliza o depende de otro módulo.
Android Clean Architecture for DummiesKengo Suzuki
Brief tutorial of implementing very primitive app(single list view) using Android Clean Architecture. It won't describe what and why, but rather, how to use it.
C# es un lenguaje de programación diseñado para generar aplicaciones en .NET Framework. Es un lenguaje orientado a objetos, tipado y seguro. Visual C# es la implementación de Microsoft de C# que ofrece compatibilidad completa con Visual Studio, incluido un editor de código, compilador, diseñadores y otras herramientas. C# ha evolucionado a través de varias versiones con nuevas características como genéricos, métodos anónimos y lambda expressions.
Chia sẻ về Clean Code tại XPDay Vietnam 2016.
Clean Code là gì?
Tại sao phải Clean Code?
Clean Code có khó không?
Một số ví dụ thực tế về áp dụng Clean Code.
El documento describe la metodología Iconix para el desarrollo de software. Iconix es una metodología iterativa e incremental que utiliza casos de uso y modelado de objetos. El documento explica las fases de Iconix, incluyendo el análisis de requisitos, análisis y diseño preliminar, diseño e implementación. También describe diagramas como el modelo de dominio, casos de uso y diagramas de secuencia utilizados en el proceso Iconix.
Este documento presenta un temario sobre interfaces de usuario en Android. Incluye secciones sobre introducción a Android, desarrollo con Android, interfaces de usuario con un ejemplo SobreTeleco, layouts, widgets, servicios, acceso a datos y bibliografía. También incluye objetivos de aprendizaje sobre conceptos básicos para desarrollar interfaces de usuario en Android como la estructura de proyectos, recursos, layouts y vistas.
El resumen del documento es:
1) El congreso web 2012 se celebrará del 1 al 3 de junio en Zaragoza y presentará aplicaciones como DrawCloud, Back.beam.io, Mail Marketing de Nerion y ShoTools.
2) Se ofrecerán talleres sobre el desarrollo de aplicaciones iOS e introducción a Objective-C así como sobre usabilidad en el diseño de aplicaciones y desarrollo web para móviles.
3) El programa incluye también sesiones sobre programación avanzada con Android y el desarrollo de sitios web con WordPress
El documento presenta un curso sobre Angular. Incluye información sobre el temario que cubre conceptos básicos de Angular como componentes, servicios, rutas y librerías de componentes. También proporciona recursos como presentaciones y ejemplos de código para aprender Angular. El documento promociona los servicios de formación y consultoría sobre desarrollo de software de Micael Gallego.
Este documento presenta el programa de la asignatura de Programación Móvil. La asignatura se divide en 3 unidades que cubren principios y fundamentos de programación móvil, almacenamiento y APIs, y tecnologías web móviles. Los estudiantes aprenderán a desarrollar aplicaciones móviles nativas e híbridas utilizando diferentes plataformas y frameworks. La evaluación consistirá en ejercicios, proyectos y exámenes parciales.
Este documento describe el desarrollo de aplicaciones móviles con Ionic 2. Explica brevemente la historia de las aplicaciones móviles, las diferentes arquitecturas de aplicaciones, y conceptos clave como Javascript, TypeScript y Angular 2. Luego introduce Ionic 2 como un framework para crear aplicaciones híbridas, y describe sus herramientas como Ionic CLI, Ionic View y Ionic Cloud.
Se presentó como trabajo de investigación de la asignatura Programación Web de la carrera Ingeniería en Sistemas de la Universidad de Cuenca, realizar un documento en el cual se detallen las métricas y demás aspectos necesarios para poder elaborar un trade-off sobre las diferentes tecnologías web en la actualidad.
Commit 2018 - Integrando Microservicios y Machine LearningRafa Hidalgo
1) El documento describe una arquitectura para integrar modelos de machine learning en una aplicación mediante microservicios.
2) Se propone dividir la aplicación en tres servicios principales - interfaz, servicios y ML - empaquetados como contenedores Docker y orquestados por Kubernetes.
3) La arquitectura permite el desarrollo políglota usando diferentes tecnologías para cada servicio, con integración continua y entrega continua mediante Jenkins.
Este documento resume una presentación sobre SPFx que tendrá lugar el 20 de mayo de 2017 en Madrid. La presentación se titula "SPFx - JS Patterns Applied to a Real World Example" y será impartida por Ángel-Rubén Yui y Javier Segura. La presentación introducirá SPFx, las herramientas principales como TypeScript y Gulp, y mostrará un ejemplo práctico aplicando patrones de TypeScript.
Este documento describe un taller extracurricular sobre desarrollo de aplicaciones móviles en Android ofrecido por la Facultad de Ciencias e Ingeniería de la Universidad de Ciencias y Humanidades. El taller tendrá una duración de 30 horas a realizarse los sábados durante 5 semanas y cubrirá temas como fundamentos de Android, interfaces de usuario, persistencia de datos en SQLite y comunicación con aplicaciones web. El objetivo es que los estudiantes adquieran habilidades prácticas para desarrollar aplicaciones móviles.
Este sílabo describe un curso de desarrollo de aplicaciones móviles en Android. El curso enseña las características principales de la plataforma Android y su integración con Java, incluyendo actividades, intents, vistas y diseños. Los estudiantes aprenderán a crear aplicaciones que usen los principales componentes visuales de Android y SQLite para la persistencia de datos, y también desarrollarán aplicaciones que se comuniquen con aplicaciones web y consuman servicios web. El curso utiliza una metodología de taller práctico para que los
El documento describe varios métodos y estrategias para el desarrollo rápido de prototipos, incluyendo un proceso iterativo con usuarios para validar requisitos. Se explican las etapas de identificación de requisitos, desarrollo de un modelo conceptual, revisión del prototipo por usuarios e iteraciones continuas hasta completar el prototipo. También se detallan estrategias como prototipos por pantallas, de procesos y funciones básicas para validar la interfaz y flujo del sistema de manera temprana.
Este documento presenta una actividad sobre la instalación y configuración de aplicaciones y servicios. Los estudiantes deben trabajar en equipos para investigar diferentes sistemas de software para diseñar redes informáticas, seleccionar uno y crear una infografía sobre él. Luego, deben diseñar una red de topología estrella indicando sus servidores. Se proporcionan ejemplos de cinco sistemas de software y se describen sus características, ventajas y desventajas.
Este documento describe los pasos para elaborar una propuesta de desarrollo de proyecto, incluyendo la redacción de una propuesta y documentos de requisitos, el diseño y modelado del proyecto usando diagramas UML, y la documentación y presentación del proyecto final. El documento también incluye una evaluación de varias actividades relacionadas con el desarrollo del proyecto.
Aplicaciones universales, Windows 8 y Windows Phone 8. @RiojaDotNetAsier Tarancón
Este documento presenta una introducción a las aplicaciones universales de Windows. Resume los objetivos del grupo RiojaDotNet de promover las tecnologías .NET, describe la estructura básica de un proyecto de aplicación universal con un proyecto compartido y proyectos para cada plataforma, y lista algunos recursos para estudiantes interesados en aprender sobre desarrollo para Microsoft.
Este documento presenta la unidad 3 de un curso sobre elaboración de propuestas de proyectos de I+D. Explica cómo elaborar una propuesta de proyecto, incluyendo un documento ejecutivo, los requisitos del proyecto, el diseño y modelado, la codificación y pruebas, y la documentación. También incluye una evaluación de la unidad con varias actividades y una bibliografía recomendada.
Este documento presenta un resumen de la aplicación móvil RoutiNow desarrollada por Adán de Jesús Silva Cuéllar. La aplicación ofrece rutinas de ejercicios para diferentes niveles y recomendaciones para mejorar proyectos futuros como asegurarse de contar con recursos sobre el tema y no subestimar la interfaz gráfica. Se utilizaron Java, XML y librerías de Android para el desarrollo en Eclipse.
Lp II clase01 - Desarrollo de software con RUPAngelDX
Este documento presenta la clase Nro. 1 de Ingeniería de Software. Introduce conceptos clave como el patrón MVC, lenguajes de programación como PHP y Java, y marcos como Struts. Explica las unidades de contenido, criterios de evaluación, bibliografía y conceptos fundamentales de ingeniería de software como características del software, metodologías como RUP, roles, herramientas CASE e introducción a Scrum.
Proyecto de Aplicación-Implementación de una INTRANET = Colegio Sagrado Coraz...Ianpierr Miranda
Este documento presenta un proyecto para implementar un sistema web de registro académico para un colegio. Incluye la fundamentación, definición del problema, objetivos y herramientas como Bootstrap, MySQL, PHP y HTML que se utilizarán. Explica las actividades programadas como recolección de datos y entrevistas. Describe el análisis, diseño e implementación incluyendo diagramas de casos de uso, secuencias y clases. El objetivo es controlar y gestionar el registro académico de los alumnos usando esta intranet.
Similar a Visteme con 'Clean Architecture' que tengo prisas (20)
3. ¡Estamos contratando!
Miguel Ángel Sánchez Vidales
masanchezv@indra.es
● Departamento de Movilidad.
● Desarrollo de aplicaciones móviles híbridas y nativas.
● Aplicar buenas prácticas en los desarrollos:
○ Arquitectura
○ Testing
● Objetivo: Crear un departamento referente en el área de movilidad dentro
y fuera de Indra.
4. Preparando el curso 2016/17
http://movilidad.usal.es
● Dirigidos a graduados y profesionales que quieran especializar su perfil
en el desarrollo de aplicaciones móviles.
● Todas las plataformas actuales: Híbridas, Android, iOS y Windows Phone.
● Modalidad Semi-presencial y Online.
● Profesores profesionales en el sector.
● Prácticas en empresas.
5. Objetivos de la Charla
● Compartir conocimientos (Betabeers).
● Introducción a la Arquitectura Clean.
● Beneficios de aplicar una arquitectura en el desarrollo de aplicaciones.
● Arquitectura Clean en un proyecto real:
○ Planificar las tareas según la situación del proyecto.
○ Sacar el máximo provecho de los desarrolladores según su perfil.
○ Etc.
7. ¿Qué es una Arquitectura Software?
Estructura de un Sistema compuesta de elementos* con propiedades visibles de
forma externa y las relaciones que existen entre ellos. (Software Engineering
Institute,SEI).
*Definición abstracta: objetos, hilos, clases, componentes...
1
8. ¿Qué NO es una Arquitectura
Software?
● Jerarquía de carpetas. Ej: paquetes en java.
● MVC o MVP. El uso del patrón MVC o MVP no implica una arquitectura.
● Estructura de un framework. Ej: Symfony, AngularJs, SDK Android, etc.
1
11. “Architecture is about intent, not
Frameworks.”
2
Rober C. Martin
● Una arquitectura se centra en lo que hace la aplicación, no en el
framework o librerías que usa.
● El dominio o modelo de negocio (casos de uso y entidades) debe ser el
núcleo la aplicación.
● Base de datos, Servicios Web, Framework, librerías, User Interface, etc.
no es relevante para el modelo de negocio.
12. 2Capas y dependencias
Dominio o Modelo de
Negocio
● Lo más importante de
la aplicación.
● No depende de
ninguna otra capa.
● Formado por Casos de
Usos (Interactors) y
entidades.
14. 2Capas y dependencias
Interfaces Externas
● Framework o librerías
que se usan para el
desarrollo de la
aplicación.
● Base de datos,
Interfaz de Usuario,
Servicios Web, etc.
16. 2Capas y dependencias
Regla de Dependencia
● Las dependencias a
nivel de código
fuente sólo pueden
apuntar hacia dentro.
● Una capa interna no
puede usar
elementos de una
capa externa.
18. El Proyecto: Inditex
3
Desarrollo de aplicaciones móviles para la gestiones diarias de artículos en las
tiendas de la cadena Inditex.
Estas gestiones pueden ser:
● Control de stocks de artículos.
● Pedidos de artículos.
● Nuevas ofertas.
● Etc.
20. Contexto del Proyecto
3
● Desarrollo de una aplicación iOS y Android al mismo tiempo que se
desarrollaban los servicios web.
● Servicios Web con constantes cambios en los datos de entrada y/o salida.
● El cliente entrega prototipos para que se use como funcional.
21. Perfil desarrolladores Android
3
● Desarrollador A: Gran conocimiento de la UI en Android y Arquitectura
Clean.
● Desarrollador B: Gran conocimiento de la UI en Android y pocos
conocimientos Arquitectura Clean.
● Desarrollador C: Gran conocimiento de la UI en Android.
23. El porqué de
Arquitectura Clean
4
● Evolución constante de la aplicación con nuevas funcionalidades.
● Desarrollo paralelo con los servicios web.
● Requisitos: minimizar al máximo las incidencias. Desarrollar test.
● Posibilidad de incluir desarrolladores no Android.
27. Arquitectura y Estructura
4
En el módulo ‘domain’ se encuentra el modelo
de negocio formado por:
● Casos de usos.
● Entidades
Usaremos un Repository para la obtención de
datos.
Capa ‘Domain’
28. Arquitectura y Estructura
4
En el módulo ‘domain’ se encuentra el modelo
de negocio formado por:
● Casos de usos.
● Entidades
Usaremos un Repository para la obtención de
datos.
Interfaz con la obtención de datos. Su
concreción será implementada en data.
Ej: void getUserById(int id);
Capa ‘Domain’
30. ● En el módulo ‘presentation’ se encuentra el
presentador que recibe peticiones del
módulo android y ejecuta casos de uso.
● Accede a la UI a través de una interfaz que
es implementada por la vista.
● Forma parte del patrón MVP.
● Mappers de modelo de datos
Arquitectura y Estructura
4
Capa ‘Presentation’
31. MVP: Model View Presenter 4
Vista: MainActivity.class Presenter: MainPresenter.class
*executeMockUseCase():
ejecutaría un caso de uso de la
capa de dominio y se recogería el
resultado.
32. Arquitectura y Estructura
4
En el módulo ‘android’ se encuentra todo el
código dependiente del sdk android:
actividades, fragmentos, adaptadores, inyección
de dependencias, etc.
Se crean modelo de datos adaptados a la
Interfaz de Usuario.
Capa ‘Android’
33. Arquitectura y Estructura
4
Modelo de Datos de la Interfaz de Usuario
● Clases que contienen atributos o métodos para obtener datos que
necesita la vista.
● En la vista no hay lógica, la vista mostrará datos con métodos simples:
public String getTitle();
○ Si hay una fecha se pasará ya formateada.
○ Si hay datos concatenados se pasará la cadena definitiva. Ej:
124.000 €
○ Se evitará el pedir continuamente datos al dominio.
34. Arquitectura y Estructura
4
● En el módulo ‘data’ se encuentra el código
para la obtención de datos: base de datos,
servicios web, ficheros.
● Tiene dependencia con el sdk Android.
Se crean modelo de datos adaptados a la
Base de datos o API.
Capa ‘Data’
35. Arquitectura y Estructura
4
Modelo de Datos para la capa ‘Data’
● Se crea un modelo de datos para el envío y recepción de datos. Se
usarán anotaciones Gson.
● Se crea un modelo de datos para trabajar con base de datos. Se usarán
anotaciones de GreenDAO.
● Al usar anotaciones particulares de una librería es conveniente usar
modelos de datos específicos para evitar “acoplar” las entidades a estas
librerías.
41. Etapa 1: “No llegamos”
No hemos empezado y ya vamos con
retrasos.
5.1
42. Etapa 1ª: “No llegamos”
● La fecha de entrega del prototipo
‘funcional’ está cerca.
● Prototipo bien definido en esta
primera entrega.
● Cambios constantes en la API.
● Se permite trabajar con mocks.
● Prioridad: Desarrollar la interfaz
de usuario. Diseño de la Interfaz
de Usuario ‘definitivo’.
● No desarrollar la capa de datos
(API) y trabajar con mocks.
Context Tareas
5.1
43. Etapa 1ª: “No llegamos”
● La fecha de entrega del prototipo
‘funcional’ está cerca.
● Prototipo bien definido en esta
primera entrega.
● Cambios constantes en la API.
● Se permite trabajar con mocks.
● Prioridad: Desarrollar la interfaz
de usuario. Diseño de la Interfaz
de Usuario ‘definitivo’.
● No desarrollar la capa de datos
(API) y trabajar con mocks.
Context Tareas
5.1
44. Etapa 1ª: “No llegamos”
● La fecha de entrega del prototipo
‘funcional’ está cerca.
● Prototipo bien definido en esta
primera entrega.
● Cambios constantes en la API.
● Se permite trabajar con mocks.
● Prioridad: Desarrollar la interfaz
de usuario. Diseño de la Interfaz
de Usuario ‘definitivo’.
● No desarrollar la capa de datos
(API) y trabajar con mocks.
Context Tareas
5.1
45. Etapa 1ª: “No llegamos”
● La fecha de entrega del prototipo
‘funcional’ está cerca.
● Prototipo bien definido en esta
primera entrega.
● Cambios constantes en la API.
● Se permite trabajar con mocks.
● Prioridad: Desarrollar la interfaz
de usuario. Diseño de la Interfaz
de Usuario ‘definitivo’.
● No desarrollar la capa de datos
(API) y trabajar con mocks.
Context Tareas
5.1
46. Resultado Obtenido:
● Definición de la Arquitectura y sus capas.
● Definición de librerías de terceros:
○ Butterknife
○ Dagger
○ Test
○ Retrofit
○ OkHttp
● Capas a desarrollar: android y presentation.
Etapa 1ª: “No llegamos”
5.1
48. Dos desarrolladores Android con
gran conocimientos de la UI.
Desarrollador Android con gran
conocimientos de la UI y
arquitectura.
Capa Android: UI
Context Tareas
Capa Presentación. Mocks para la
vista.
Etapa 2ª: “¡Empecemos! ¿Qué hago yo?”
5.2
49. ● Se definen los presentadores y
devuelven modelos de datos
exclusivos para la UI con datos fake.
● Un desarrollador trabajando en esta
capa.
Etapa 2ª: “¡Empecemos! ¿Qué hago yo?”
5.2
50. ● Se implementa la Interfaz de Usuario
(UI).
● La UI recibe del presentador un modelo
de datos que cumple con todas las
necesidades de la UI.
● Dos desarrolladores trabajando en esta
capa.
Etapa 2ª: “¡Empecemos! ¿Qué hago yo?”
5.2
51. Resultado Obtenido:
● Interfaz de Usuario desarrollada.
○ Aspecto visual completado.
○ Los modelos que reciben la interfaz de usuario son definitivo aunque se
crean a través de datos Fakes.
● Se cumple el objetivo de tener la aplicación funcional con mocks (permitido).
● No somos bloqueados por otros desarrollos. Ej: Servicios Web.
Etapa 2ª: “¡Empecemos! ¿Qué hago yo?”
5.2
53. ● Se definen las entidades y casos de
uso de la aplicación.
● Se usan mocks para la obtención de
datos desde la API o Base de datos.
● Un desarrollador.
Etapa 3ª: “Primer matchball salvado”
5.3
54. ● Se quitan los datos fakes de la capa
‘presentation’ y se ejecutan los casos
de uso de la capa ‘domain’.
● Se crean los mappers entidad-
modeloUI y modeloUI-entidad.
● Un desarrollador.
Etapa 3ª: “Primer matchball salvado”
5.3
55. Resultado Obtenido:
● Se implementa la capa presentación.
○ Interacción con los Casos de Uso.
○ Creación de mappers.
○ Se eliminan los datos fakes.
● Se implementa la capa de dominio.
○ Se corrigen posibles errores en la obtención de datos para la UI.
○ Se definen las abstracciones para la obtención de datos.
Etapa 3ª: “Primer matchball salvado”
5.3
57. ● Se quitan los mocks de la capa data y
se implementa la obtención de datos
de la API y de Base de datos.
● Se usa un cliente de acceso a la API
que consume ficheros json locales.
● Dos desarrolladores.
Etapa 4ª: “Web Services acabados”
5.4
58. Resultado Obtenido:
● Se implementa la capa data.
○ Se define la obtención de datos de la API.
■ Se crean modelos exclusivos para la API para el envío y recepción de
información.
■ Los mocks son JSON obtenidos de forma local (evitar depender de una
conexión a red)
○ Se define la obtención de datos locales.
■ Se crean modelos exclusivos para las operaciones con SqLite
(GreenDAO-ORM).
Etapa 4ª: “Web Services acabados”
5.4
60. ● Se apunta al servidor de desarrollo y
se prueba con conexión a internet.
Etapa 5ª (Final): “Integrando todo”
5.5
61. Etapa 5ª (Final): “Integrando todo”
5.5
● Se ejecutan los test y se refactoriza si
es necesario.
● Se elimina cualquier deuda técnica
detectada (ToDo).
63. Conclusiones
6.1
● La definición de la arquitectura, integración con librerías, inyección de
dependencias, etc. hace que el inicio sea lento. Recomendación: crear un
proyecto con todo esto definido y que sea la base de futuros proyectos.
● Al estar las funcionalidades distribuidas por capas, se crea la sensación de
no encontrar el código o de estar perdido.
● El trabajar con capas te aísla de problemas que afectan a otras capas.
64. Conclusiones
6.2
● El trabajar con abstracciones permite que el proyecto sea más flexible ante
cambios.
● Reutilización de código. Toda la lógica está centrada en la capa de dominio
que es accesible desde cualquier otra capa.
● Código testeable. No hay código acoplado que no permita falsear ciertos
datos para comprobar distintos comportamientos.