Cuando se crea un proyecto en Android; por defecto el crea la carpeta “src” y dentro de esta el paquete que contiene todas las clases de la aplicación.
También crea otros folder por defecto, pero en donde se crea la interfaz de la aplicación es en el folder “res/layout” el cual contiene los archivos “.XML” que contienen la interfaz de la aplicación.
Cuando se agregan componentes a la interfaz de la aplicación, se genera automáticamente en el archivo “R” la definición de estos componentes en código java; para poder utilizar y darles la funcionalidad a estos en el archivo .java que se crea en la carpeta “src”.
Para aplicar un evento a un botón, o a cualquier otro componente de la interfaz; se declara en el archivo o actividad “.java “dicho botón; y se inicializa después agregándole el evento.
[Codigo][/Codigo]
Para utilizar varias pantallas en nuestra aplicación, se debe crear en la carpeta “res/layout” las pantallas que queramos utilizar “.XML” y las clases para utilizar o inicializar la interfaz los “.java”; y además hay que modificar el archivo “.XML” que se encuentra en la carpeta “res” llamado “AndroidManifiest.xml” agregándole las actividades nuevas de las clases que se necesiten. VER FIGURA 2-3:
Mostrando entradas con la etiqueta Proyecto. Mostrar todas las entradas
Mostrando entradas con la etiqueta Proyecto. Mostrar todas las entradas
lunes, 4 de enero de 2010
Creando un proyecto Android en Eclipse
Pasos para crear nuestro primer proyecto Android desde nuestro IDE:
1. Para ello nos dirigimos al menú File /New/Proyect... [1]
FIGURA 1 (Nuevo Proyecto)
2. Si escogen la primera opción (cuando sea la primera vez que creemos un proyecto Android no saldrá como un opción y tendremos que elegir Proyect como la FIGURA anterior). Se nos desplegara el siguiente diálogo donde seleccionamos Android Proyect y presionamos el botón Next. [1] VER FIGURA 2.
FIGURA 2 (Nuevo Proyecto)
3. Ahora se abrirá un nuevo diálogo donde tendremos que indicar 1º el nombre del proyecto, 2º el nombre del package (el nombre del package está formada por dos palabras unidas con un punto como por ejemplo com.aplicacion) este paquete es el que contendrá todos los archivos y es obligatorio. Estos dos campos son obligatorios y no se pueden dejar en blanco, y por último (3º) el nombre que queremos darle a nuestra aplicación y el nombre del arrancador de la aplicación (seria el Main de java). Finalmente presionamos Finish. [1] VER FIGURA 3.
FIGURA 3 (Nuevo Proyecto)
4. Finalmente si todo sale bien, se creara nuestro proyecto y se podrá visualizar desde el panel de área de trabajo (Workspace) que se encuentra a la izquierda de eclipse. Dentro del proyecto si lo desplegamos presionando el botón + veremos el contenido. Primero la carpeta src la cual al igual que en j2me contendrá los archivos java y el paquete, por defecto se crea el archivo HelloWorld.java y el R.java, el primero es el que modificaremos para que muestre Hola Mundo por pantalla. Más abajo vemos mas carpetas y archivos, estas las explicaremos más adelante. [1] VER FIGURA 4.
FIGURA 4 (Nuevo Proyecto)
5. Ahora para editar el fichero HelloWorld.java solo tendremos que hacer doble Click sobre él y se nos mostrara en la ventana de eclipse, aquí nos muestra el contenido del fichero. La primera línea indica el package (nombre que dimos al crear la aplicación), luego la sentencia import para utilizar las librerías de Android y finalmente la clase principal que lleva el nombre indicado al crear el proyecto y dentro el método constructor, aquí podremos agregar nuestro código o crear nuevas clases también. [1] VER FIGURA 5.
FIGURA 5 (Nuevo Proyecto)
1. Para ello nos dirigimos al menú File /New/Proyect... [1]
FIGURA 1 (Nuevo Proyecto)
2. Si escogen la primera opción (cuando sea la primera vez que creemos un proyecto Android no saldrá como un opción y tendremos que elegir Proyect como la FIGURA anterior). Se nos desplegara el siguiente diálogo donde seleccionamos Android Proyect y presionamos el botón Next. [1] VER FIGURA 2.
FIGURA 2 (Nuevo Proyecto)
3. Ahora se abrirá un nuevo diálogo donde tendremos que indicar 1º el nombre del proyecto, 2º el nombre del package (el nombre del package está formada por dos palabras unidas con un punto como por ejemplo com.aplicacion) este paquete es el que contendrá todos los archivos y es obligatorio. Estos dos campos son obligatorios y no se pueden dejar en blanco, y por último (3º) el nombre que queremos darle a nuestra aplicación y el nombre del arrancador de la aplicación (seria el Main de java). Finalmente presionamos Finish. [1] VER FIGURA 3.
FIGURA 3 (Nuevo Proyecto)
4. Finalmente si todo sale bien, se creara nuestro proyecto y se podrá visualizar desde el panel de área de trabajo (Workspace) que se encuentra a la izquierda de eclipse. Dentro del proyecto si lo desplegamos presionando el botón + veremos el contenido. Primero la carpeta src la cual al igual que en j2me contendrá los archivos java y el paquete, por defecto se crea el archivo HelloWorld.java y el R.java, el primero es el que modificaremos para que muestre Hola Mundo por pantalla. Más abajo vemos mas carpetas y archivos, estas las explicaremos más adelante. [1] VER FIGURA 4.
FIGURA 4 (Nuevo Proyecto)
5. Ahora para editar el fichero HelloWorld.java solo tendremos que hacer doble Click sobre él y se nos mostrara en la ventana de eclipse, aquí nos muestra el contenido del fichero. La primera línea indica el package (nombre que dimos al crear la aplicación), luego la sentencia import para utilizar las librerías de Android y finalmente la clase principal que lleva el nombre indicado al crear el proyecto y dentro el método constructor, aquí podremos agregar nuestro código o crear nuevas clases también. [1] VER FIGURA 5.
FIGURA 5 (Nuevo Proyecto)
domingo, 20 de diciembre de 2009
Arquitectura de Android
Los componentes principales del sistema operativo de Android (cada sección se describe en detalle). [3] VER FIGURA 1:
• Aplicaciones: Las aplicaciones base incluirán un cliente de email, programa de SMS, calendario, mapas, navegador, contactos, y otros. Todas las aplicaciones están escritas en lenguaje de programación Java.[1]
• Framework de aplicaciones: Los desarrolladores tienen acceso completo a los mismos API’s del framework usados por las aplicaciones base. La arquitectura está diseñada para simplificar el reutilización de componentes; cualquier aplicación puede publicar sus capacidades y cualquier otra aplicación puede luego hacer uso de esas capacidades (sujeto a reglas de seguridad del framework). Este mismo mecanismo permite que los componentes sean reemplazados por el usuario. [1]
• Bibliotecas: Android incluye un set de bibliotecas C/C++ usadas por varios componentes del sistema Android. Estas características se exponen a los desarrolladores a través del framework de aplicaciones de Android; algunas son: System C library (implementación biblioteca C standard), bibliotecas de medios, bibliotecas de gráficos, 3d, SQLite, entre otras. [1]
• Runtime de Android: Android incluye un set de bibliotecas base que proporcionan la mayor parte de las funciones disponibles en las bibliotecas base del lenguaje Java. Cada aplicación Android corre su propio proceso, con su propia instancia de la máquina virtual Dalvik. Dalvik ha sido escrito de forma que un dispositivo puede correr múltiples máquinas virtuales de forma eficiente. Dalvik ejecuta archivos en el formato Dalvik Executable (.dex), el cual está optimizado para memoria mínima. La Máquina Virtual está basada en registros, y corre clases compiladas por el compilador de Java que han sido transformadas al formato.dex por la herramienta incluida "dx".[1]
• Núcleo - Linux: Android depende de Linux versión 2.6 para los servicios base del sistema como seguridad, gestión de memoria, gestión de procesos, stack de red, y modelo de controladores. El núcleo también actúa como una capa de abstracción entre el hardware y el resto del stack de software. [1] VER FIGURA 1.
Figura 1(Arquitectura de Android)
• Aplicaciones: Las aplicaciones base incluirán un cliente de email, programa de SMS, calendario, mapas, navegador, contactos, y otros. Todas las aplicaciones están escritas en lenguaje de programación Java.[1]
• Framework de aplicaciones: Los desarrolladores tienen acceso completo a los mismos API’s del framework usados por las aplicaciones base. La arquitectura está diseñada para simplificar el reutilización de componentes; cualquier aplicación puede publicar sus capacidades y cualquier otra aplicación puede luego hacer uso de esas capacidades (sujeto a reglas de seguridad del framework). Este mismo mecanismo permite que los componentes sean reemplazados por el usuario. [1]
• Bibliotecas: Android incluye un set de bibliotecas C/C++ usadas por varios componentes del sistema Android. Estas características se exponen a los desarrolladores a través del framework de aplicaciones de Android; algunas son: System C library (implementación biblioteca C standard), bibliotecas de medios, bibliotecas de gráficos, 3d, SQLite, entre otras. [1]
• Runtime de Android: Android incluye un set de bibliotecas base que proporcionan la mayor parte de las funciones disponibles en las bibliotecas base del lenguaje Java. Cada aplicación Android corre su propio proceso, con su propia instancia de la máquina virtual Dalvik. Dalvik ha sido escrito de forma que un dispositivo puede correr múltiples máquinas virtuales de forma eficiente. Dalvik ejecuta archivos en el formato Dalvik Executable (.dex), el cual está optimizado para memoria mínima. La Máquina Virtual está basada en registros, y corre clases compiladas por el compilador de Java que han sido transformadas al formato.dex por la herramienta incluida "dx".[1]
• Núcleo - Linux: Android depende de Linux versión 2.6 para los servicios base del sistema como seguridad, gestión de memoria, gestión de procesos, stack de red, y modelo de controladores. El núcleo también actúa como una capa de abstracción entre el hardware y el resto del stack de software. [1] VER FIGURA 1.
Figura 1(Arquitectura de Android)
Android
Android es un sistema operativo para dispositivos móviles y computadoras basado en el núcleo Linux. Inicialmente fue desarrollado por Google y luego por la Open Handset Alliance (liderada por la propia Google). La presentación de la plataforma Android se realizó el 5 de noviembre de 2007 junto con la fundación Open Handset Alliance, un consorcio de 48 compañías de hardware, software y telecomunicaciones comprometidas a la promoción de estándares abiertos para dispositivos móviles. [1]
Esta plataforma permite el desarrollo de aplicaciones por terceros (personas ajenas a Google). Los desarrolladores deben escribir código gestionado en lenguaje de programación Java a través de SDK proporcionada por el mismo Google. Una alternativa es el uso de la NDK (Native Development Kit) de Google para hacer el desarrollo en C en código fuente. [1]
La mayoría del código fuente de Android ha sido publicado bajo la licencia de software Apache, una licencia de software libre y código fuente abierto. Google lanzó la última versión de Android, el 26 de Octubre del 2009, 2.0. [1]
Características
• Framework de aplicaciones: permite reutilización y reemplazo de componentes.
• Máquina virtual Dalvik: optimizada para dispositivos móviles.
• Navegador integrado: basado en el motor de código abierto Web Kit.
• Gráficos optimizados, con una biblioteca de gráficos 2D; gráficos 3D basado en la especificación OpenGL ES 1.0 (aceleración por hardware opcional).
• SQLite para almacenamiento de datos estructurados.
• Soporte para medios con formatos comunes de audio, vídeo e imágenes planas (MPEG4, H.264, MP3, OGG, AAC, AMR, JPG, PNG, GIF)
• Telefonía GSM (dependiente del hardware)
• Bluetooth, EDGE, 3G, y Wi-Fi (dependiente del hardware)
• Cámara, GPS, brújula, y acelerómetro (dependiente del hardware)
• Ambiente rico de desarrollo incluyendo un emulador de dispositivo, herramientas para depurar, perfiles de memoria y rendimiento, y un complemento para el IDE Eclipse.
• Pantalla táctil.
• Android Market permite que los desarrolladores pongan sus aplicaciones, gratuitas o de pago, en el mercado a través de esta aplicación accesible desde todos los teléfonos con Android.
• Además de esto, puedes acceder desde tu móvil programando diferentes utilidades y herramientas.
Limitantes
En cuanto a las limitantes de Android pueden ser muchas, eso va a depender del teléfono que se esté utilizando entonces a continuación se presenta una serie de ventajas y desventajas de Android para HTC MAGIC, ya que este es uno de los teléfonos más comunes en los cuales se utiliza Android.
Ventajas
• Facilidad de uso: Cualquier persona sin ningún conocimiento instala y desinstala aplicaciones en unos segundos.
• Miles de aplicaciones gratuitas.
• De serie viene preparada (siempre y cuando seas usuario de Gmail) para funcionar en unos segundos.
• La sensación es que es un teléfono táctil rápido, y que nunca se queda colgado.
• Las aplicaciones en segunda plano simplemente alucinantes.
Desventajas
• No es fácil de sincronizar con tus contactos como no uses los de Gmail.
• Uso intensivo de datos sin control ninguno.
• Las aplicaciones nunca tienes la sensación de que las cierras simplemente desaparecen.
• No hay marcación rápida en la aplicación teléfono (algo fundamental en un táctil).
Esta plataforma permite el desarrollo de aplicaciones por terceros (personas ajenas a Google). Los desarrolladores deben escribir código gestionado en lenguaje de programación Java a través de SDK proporcionada por el mismo Google. Una alternativa es el uso de la NDK (Native Development Kit) de Google para hacer el desarrollo en C en código fuente. [1]
La mayoría del código fuente de Android ha sido publicado bajo la licencia de software Apache, una licencia de software libre y código fuente abierto. Google lanzó la última versión de Android, el 26 de Octubre del 2009, 2.0. [1]
Características
• Framework de aplicaciones: permite reutilización y reemplazo de componentes.
• Máquina virtual Dalvik: optimizada para dispositivos móviles.
• Navegador integrado: basado en el motor de código abierto Web Kit.
• Gráficos optimizados, con una biblioteca de gráficos 2D; gráficos 3D basado en la especificación OpenGL ES 1.0 (aceleración por hardware opcional).
• SQLite para almacenamiento de datos estructurados.
• Soporte para medios con formatos comunes de audio, vídeo e imágenes planas (MPEG4, H.264, MP3, OGG, AAC, AMR, JPG, PNG, GIF)
• Telefonía GSM (dependiente del hardware)
• Bluetooth, EDGE, 3G, y Wi-Fi (dependiente del hardware)
• Cámara, GPS, brújula, y acelerómetro (dependiente del hardware)
• Ambiente rico de desarrollo incluyendo un emulador de dispositivo, herramientas para depurar, perfiles de memoria y rendimiento, y un complemento para el IDE Eclipse.
• Pantalla táctil.
• Android Market permite que los desarrolladores pongan sus aplicaciones, gratuitas o de pago, en el mercado a través de esta aplicación accesible desde todos los teléfonos con Android.
• Además de esto, puedes acceder desde tu móvil programando diferentes utilidades y herramientas.
Limitantes
En cuanto a las limitantes de Android pueden ser muchas, eso va a depender del teléfono que se esté utilizando entonces a continuación se presenta una serie de ventajas y desventajas de Android para HTC MAGIC, ya que este es uno de los teléfonos más comunes en los cuales se utiliza Android.
Ventajas
• Facilidad de uso: Cualquier persona sin ningún conocimiento instala y desinstala aplicaciones en unos segundos.
• Miles de aplicaciones gratuitas.
• De serie viene preparada (siempre y cuando seas usuario de Gmail) para funcionar en unos segundos.
• La sensación es que es un teléfono táctil rápido, y que nunca se queda colgado.
• Las aplicaciones en segunda plano simplemente alucinantes.
Desventajas
• No es fácil de sincronizar con tus contactos como no uses los de Gmail.
• Uso intensivo de datos sin control ninguno.
• Las aplicaciones nunca tienes la sensación de que las cierras simplemente desaparecen.
• No hay marcación rápida en la aplicación teléfono (algo fundamental en un táctil).
Introducción al Proyecto Android
Cada día se lucha por ser mejor y conforme pasan los años vamos aprendiendo cosas nuevas y todo a nuestro alrededor va cambiando y muy en especial en el ciberespacio, donde las tecnologías crecen cada día, o más bien cada milésima de segundo este es un mundo que avanza a pasos agigantados y como buenos desarrolladores que pretenden o deben ir a la velocidad que caminan estas tecnologías.
Existen grandes o más bien gigantes como se les conoce hoy por hoy que controlan o marca el paso en este mundo desconocido para algunos, temido por muchos y amado ustedes; estos gigantes del ciberespacio tales como Microsoft, Apple, Linux, Yahoo y desde unos años atrás el que hoy está dando las pautas de cómo se debe mover el ciberespacio y el primer enemigo en la lista negra de estos gigantes, más conocido como Google, que desde su aparición con un simple buscador web ha sido la pesadilla de muchos.
Google es un buen ejemplo de una de las compañías más exitosas, con una estrategia de mercado bien definida y con una misión muy concreta, llegar a ser el mejor de los mejores. Como bien se mencionaba anteriormente desde la aparición del buscador web de Google, se ha desatado una serie de productos innovadores y de gran utilidad para los cibernautas, entre las herramientas brindadas por Google podemos mencionar varias como: Gmail, Google Talk, Google Maps, Google Docs, Blogger, Google Wave, Android, en pocas palabras un sinfín de herramientas de las cuales podemos recalcar pero es sobre esta ultima Android sobre la que se expone en este articulo, el famoso sistemas operativo desarrolla por Google bajo una plataforma y Kernel Linux.
En este blog se expondrán una serie post relacionados directamente con temas con Android y muy especialmente enfocado a dispositivos móviles como celulares y el desarrollo de aplicaciones mediante el SDK de Android, entre un sin fin de cosas relacionados con este tema, cualquier duda, descubrimiento que encontremos, lo compartiremos con ustedes.
Enjoy
Existen grandes o más bien gigantes como se les conoce hoy por hoy que controlan o marca el paso en este mundo desconocido para algunos, temido por muchos y amado ustedes; estos gigantes del ciberespacio tales como Microsoft, Apple, Linux, Yahoo y desde unos años atrás el que hoy está dando las pautas de cómo se debe mover el ciberespacio y el primer enemigo en la lista negra de estos gigantes, más conocido como Google, que desde su aparición con un simple buscador web ha sido la pesadilla de muchos.
Google es un buen ejemplo de una de las compañías más exitosas, con una estrategia de mercado bien definida y con una misión muy concreta, llegar a ser el mejor de los mejores. Como bien se mencionaba anteriormente desde la aparición del buscador web de Google, se ha desatado una serie de productos innovadores y de gran utilidad para los cibernautas, entre las herramientas brindadas por Google podemos mencionar varias como: Gmail, Google Talk, Google Maps, Google Docs, Blogger, Google Wave, Android, en pocas palabras un sinfín de herramientas de las cuales podemos recalcar pero es sobre esta ultima Android sobre la que se expone en este articulo, el famoso sistemas operativo desarrolla por Google bajo una plataforma y Kernel Linux.
En este blog se expondrán una serie post relacionados directamente con temas con Android y muy especialmente enfocado a dispositivos móviles como celulares y el desarrollo de aplicaciones mediante el SDK de Android, entre un sin fin de cosas relacionados con este tema, cualquier duda, descubrimiento que encontremos, lo compartiremos con ustedes.
Enjoy
jueves, 10 de diciembre de 2009
RallyDev
Es una aplicación propietaria para la administración de proyectos, orientado a las metodologías Ágil, en dicha aplicación se nos permite llevar la administración de un proyecto completo según las reglas de la metodología Ágil, la empleada para nuestro caso es SCRUM. La aplicación nos permite agregar usuarios, mantenimiento de Backlog, releases, iteraciones y plan de trabajo, además de una sección de seguimiento, tanto para las iteraciones como para el equipo de trabajo y releases, además cuenta con una gama de gráficos para reportes gerenciales, así como una sección de Quality (aseguramiento de la calidad).
Antes de iniciar con la explicación detallada de la aplicación realizaremos una breve introducción a SCRUM. Esta es una metodología Ágil para la administración de proyectos de software, en la cual se mantiene una relación muy estrecha con el cliente, como primer paso se deben crear los Backlog, dicho de otra forma es todo el saco de posibles tareas para el sistema, estas Backlog son suministradas por el usuario, se recolectan en reuniones utilizando las técnicas de recolección de requerimientos, ya que los Backlog son los requerimientos del sistema.
Grafico de quemados, esta es la herramienta que le permite al administrador de proyectos visualizar en términos generales el avance del proyecto, también es de gran ayuda ya que no se necesita tener conocimiento tecnificado para comprenderla, por lo tanto se les puede presentar a gerentes o usuarios para brindar reportes de estado del proyecto.
El proyecto se dividirá en releases (entregables) los cuales consisten en las partes que se entregaran al cliente final, se decidirá la cantidad de releases que se realizaran dependiendo de la puntuación acumulada de las distintas historias de usuario que conforman un conjunto de tareas, es decir la totalidad del proyecto se dividirá según la prioridad de entrega y de este modo se acomodaran en releases. También es importante destacar que los releases se subdividen en iteraciones las cuales constituyen las unidades grandes de grupos de historias de usuario a realizar dentro de un releace.
La herramienta para la administración de proyectos de software RallyDev nos permite administrar todos los componentes de las metodologías Ágil, así mismo nos permite darle seguimiento a las iteraciones así como a las distintas unidades del proyecto. A continuación se realizara un manual explicativo de cómo utilizar la herramienta RallyDev en su versión Web.
Antes de iniciar con la explicación detallada de la aplicación realizaremos una breve introducción a SCRUM. Esta es una metodología Ágil para la administración de proyectos de software, en la cual se mantiene una relación muy estrecha con el cliente, como primer paso se deben crear los Backlog, dicho de otra forma es todo el saco de posibles tareas para el sistema, estas Backlog son suministradas por el usuario, se recolectan en reuniones utilizando las técnicas de recolección de requerimientos, ya que los Backlog son los requerimientos del sistema.
Grafico de quemados, esta es la herramienta que le permite al administrador de proyectos visualizar en términos generales el avance del proyecto, también es de gran ayuda ya que no se necesita tener conocimiento tecnificado para comprenderla, por lo tanto se les puede presentar a gerentes o usuarios para brindar reportes de estado del proyecto.
El proyecto se dividirá en releases (entregables) los cuales consisten en las partes que se entregaran al cliente final, se decidirá la cantidad de releases que se realizaran dependiendo de la puntuación acumulada de las distintas historias de usuario que conforman un conjunto de tareas, es decir la totalidad del proyecto se dividirá según la prioridad de entrega y de este modo se acomodaran en releases. También es importante destacar que los releases se subdividen en iteraciones las cuales constituyen las unidades grandes de grupos de historias de usuario a realizar dentro de un releace.
La herramienta para la administración de proyectos de software RallyDev nos permite administrar todos los componentes de las metodologías Ágil, así mismo nos permite darle seguimiento a las iteraciones así como a las distintas unidades del proyecto. A continuación se realizara un manual explicativo de cómo utilizar la herramienta RallyDev en su versión Web.
Control de Versiones
Durante el desarrollo de cualquier producto, no solamente del código de un programa, éste evoluciona mientras se realizan sucesivos cambios en él. Sin ir más lejos, un libro no se escribe entero en un par de horas sino que se prolonga durante un número de sesiones indeterminadas durante las cuales se añade más y más contenido. Esta adición de contenido realmente son cambios sucesivos al documento. Evidentemente, no todos los cambios consisten en adicciones sino que muchas veces se modifican o eliminan partes ya existentes por diversos motivos.
Generalmente cuando se están desarrollando proyectos ya sean pequeños o grandes se tiene como mínimo la participación de dos desarrolladores, esto hace que se trabaje en diferentes módulos del proyecto que luego de manera manual serán pegadas las partes, sin embargo si el grupo de desarrolladores va creciendo el modo de pegar las partes creadas por cada programador se vuelve bien difícil y complicada, es por eso que a lo largo de los años se han desarrollado diferentes herramientas que permiten llevar un control de las distintas versiones de los proyectos, donde se permite gestionar de una manera más organizada los repositorios de archivos y sus distintas versiones, utilizando una arquitectura cliente-servidor, donde un servidor guarda las versiones actuales del proyecto y su historia, todo esto dependiendo de las cambios y actualizaciones que haga el desarrollador. Independientemente del tipo de cambio realizado, los cambios no son siempre definitivos ni correctos. En muchos casos, un cambio introduce un error que es corregido con cambios posteriores pero, en algunos casos, se desearía poder deshacer completamente un cambio erróneo. En estas circunstancias es cuando interviene los programas de gestión de versiones.
Mediante los procesos definidos de estos sistemas, es posible trazar los cambios que se han realizado en el tiempo. Al disponer de esta información, es posible identificar y controlar todos y cada uno de los cambios realizados. Asimismo, es posible regenerar sin errores el estado del producto en cualquier momento de su desarrollo, es decir, cualquiera de sus versiones, además nos da una serie de ventajas, ya que permite que varios clientes pueden sacar copias del proyecto al mismo tiempo, realizar cambios a los ficheros manteniendo un histórico de los cambios, deshacer los cambios hechos en un momento dado y recuperar versiones pasadas así evitando posibles errores que ocurran en un proceso de actualización, también permiten ver un histórico de cambios y comentarios, lo cual permite que los clientes pueden también comparar diferentes versiones de archivos.
Llevar este control puede parecer complejo en un inicio pero simplifica enormemente el trabajo a corto plazo. Una vez implantado se transforma en una herramienta indispensable de trabajo.
Todos los sistemas de control de versiones se basan en el concepto repositorio. Un repositorio no es más que el conjunto de versiones del producto. Una vez creado, los distintos usuarios realizan sus cambios sobre el repositorio que se encarga de almacenarlos permitiendo la recuperación de cualquier versión.
Existen dos tipos de repositorios:
Centralizado
Cuando se desarrollaron los sistemas de control de versiones, muchos de ellos se hicieron en esquema cliente-servidor, con lo que el desarrollo de las herramientas está claramente diferenciado entre:
•El cliente: Es la aplicación que se conecta al servidor y mantiene una copia local del repositorio, así como se encarga, generalmente de la corrección de conflictos y la mayoría de lógica del sistema.
•El servidor: Es el sistema que toma los datos del cliente y los almacena a espera de una o múltiples peticiones de esos datos. Este sistema se encargaría del almacenamiento de las versiones, control de concurrencia, bloqueos y otras características parecidas a las de las bases de datos.
¿Qué limitaciones y características posee?
•El sistema servidor es un repositorio, como los que mantienen los clientes, pero perfectamente sincronizado y sin que dé lugar a conflictos. Es la copia maestra de los datos.
•Cuando un sistema web quiere hacer un listado, puede tomar los datos de este servidor y siempre serán seguros, con lo que no tendrá que resolver conflictos, ni tendrá que hacer mezclas.
•Una copia local debe de poder mezclarse con el repositorio central cuando queramos publicar un conjunto de cambios o cuando queramos tomar la última versión publicada en concordancia con nuestra copia local.
•Es normal ver en muchos de estos sistemas ramificaciones, versiones, etiquetas, o similares, a modo de tener varias copias según nos interese. Estas ramificaciones están en el servidor y en algunos casos puede llegar a ser muy costosa su diferenciación.
Algunos ejemplos de Controladores de Versiones Centralizados:
•Concurrent Versions System (CVS)
•SubVersion
Distribuido
Desarrolladores como Linus Torvalds, Eric S. Raymond y otros más, han desarrollado sistemas distribuidos de control de versiones tales como GIT, Baazaar, Mercurial, darcs, entre otros; estos sistemas se destacan por haber sido desarrollados en un formato distribuido, esto quiere decir que, en sí, no hay un servidor que mantenga una copia del repositorio, sino que está mantenida entre los clientes que estén en uso del repositorio y, al igual que los clientes P2P, mientras más desarrolladores haya conectados, mejor conectividad habrá entre todos.
En cualquiera de los dos casos, el repositorio es compartido por todos los usuarios (o al mismo usuario desde distintas máquinas) que tengan acceso al mismo. Es posible que se produzcan ediciones simultáneas de los mismos elementos que generen conflictos. Para solucionar este problema existen dos políticas básicas de resolución de conflictos:
Bloqueo-modificación-desbloqueo:
En esta política se evitan las modificaciones concurrentes. Cuando un usuario desea realizar una modificación, indica el elemento a modificar que queda bloqueado en el repositorio por lo que se impide el acceso al resto de usuarios (exclusión mutua). Cuando finaliza de realizar sus cambios, los envía al repositorio liberando el bloqueo con lo que el resto de los usuarios puede obtener la copia actualizada para realizar sus propios cambios.
Copiar-modificar-mezclar:
Esta política permite las modificaciones simultáneas. Cada usuario hace una copia del repositorio en su máquina y procede trabajar con ella como si no fuera un repositorio. Cuando finaliza su trabajo, envía los cambios al repositorio que se encarga de analizar los cambios realizados por el usuario y los que se han realizado en el propio repositorio y realiza la mezcla.
Evidentemente, la primera política es mucho más restrictiva lo que dificulta el trabajo diario ralentizando el acceso a los recursos y ocasionando problemas si no se liberan recursos bloqueados. La segunda, por su parte, tiene como inconveniente que no siempre es posible mezclar los cambios realizados aunque en esos casos, utiliza al usuario que envía cambios para solucionar esos conflictos irresolubles automáticamente.
Esto da una serie de ventajas al sistema centralizado, como son:
•Disponer de forma distribuida de la información del repositorio al completo, tanto de forma local, como a través de los demás componentes del grupo.
•Cada cambio se va replicando entre los demás equipos distribuidos, a modo de que puedan emplear esos datos y actualizarlos en sus sistemas.
•El sistema de control de versiones distribuido ha sido pensado con la forma de trabajo basada en ramas, unión central en una sola versión (trunk) y liberaciones (o tags). Con lo que cada rama puede identificarse como cada copia distribuida que se use.
•Una máquina servidora puede emplearse, al estar siempre conectada, como otro punto de sincronización, con la ventaja de que, aunque cayera, mientras haya más miembros conectados, el sistema siempre se mantiene activo y con buen ancho de banda.
Algunos ejemplos de Controladores de Versiones Distribuidos:
•Baazaar
•Mercurial
•GIT
Generalmente cuando se están desarrollando proyectos ya sean pequeños o grandes se tiene como mínimo la participación de dos desarrolladores, esto hace que se trabaje en diferentes módulos del proyecto que luego de manera manual serán pegadas las partes, sin embargo si el grupo de desarrolladores va creciendo el modo de pegar las partes creadas por cada programador se vuelve bien difícil y complicada, es por eso que a lo largo de los años se han desarrollado diferentes herramientas que permiten llevar un control de las distintas versiones de los proyectos, donde se permite gestionar de una manera más organizada los repositorios de archivos y sus distintas versiones, utilizando una arquitectura cliente-servidor, donde un servidor guarda las versiones actuales del proyecto y su historia, todo esto dependiendo de las cambios y actualizaciones que haga el desarrollador. Independientemente del tipo de cambio realizado, los cambios no son siempre definitivos ni correctos. En muchos casos, un cambio introduce un error que es corregido con cambios posteriores pero, en algunos casos, se desearía poder deshacer completamente un cambio erróneo. En estas circunstancias es cuando interviene los programas de gestión de versiones.
Mediante los procesos definidos de estos sistemas, es posible trazar los cambios que se han realizado en el tiempo. Al disponer de esta información, es posible identificar y controlar todos y cada uno de los cambios realizados. Asimismo, es posible regenerar sin errores el estado del producto en cualquier momento de su desarrollo, es decir, cualquiera de sus versiones, además nos da una serie de ventajas, ya que permite que varios clientes pueden sacar copias del proyecto al mismo tiempo, realizar cambios a los ficheros manteniendo un histórico de los cambios, deshacer los cambios hechos en un momento dado y recuperar versiones pasadas así evitando posibles errores que ocurran en un proceso de actualización, también permiten ver un histórico de cambios y comentarios, lo cual permite que los clientes pueden también comparar diferentes versiones de archivos.
Llevar este control puede parecer complejo en un inicio pero simplifica enormemente el trabajo a corto plazo. Una vez implantado se transforma en una herramienta indispensable de trabajo.
Todos los sistemas de control de versiones se basan en el concepto repositorio. Un repositorio no es más que el conjunto de versiones del producto. Una vez creado, los distintos usuarios realizan sus cambios sobre el repositorio que se encarga de almacenarlos permitiendo la recuperación de cualquier versión.
Existen dos tipos de repositorios:
Centralizado
Cuando se desarrollaron los sistemas de control de versiones, muchos de ellos se hicieron en esquema cliente-servidor, con lo que el desarrollo de las herramientas está claramente diferenciado entre:
•El cliente: Es la aplicación que se conecta al servidor y mantiene una copia local del repositorio, así como se encarga, generalmente de la corrección de conflictos y la mayoría de lógica del sistema.
•El servidor: Es el sistema que toma los datos del cliente y los almacena a espera de una o múltiples peticiones de esos datos. Este sistema se encargaría del almacenamiento de las versiones, control de concurrencia, bloqueos y otras características parecidas a las de las bases de datos.
¿Qué limitaciones y características posee?
•El sistema servidor es un repositorio, como los que mantienen los clientes, pero perfectamente sincronizado y sin que dé lugar a conflictos. Es la copia maestra de los datos.
•Cuando un sistema web quiere hacer un listado, puede tomar los datos de este servidor y siempre serán seguros, con lo que no tendrá que resolver conflictos, ni tendrá que hacer mezclas.
•Una copia local debe de poder mezclarse con el repositorio central cuando queramos publicar un conjunto de cambios o cuando queramos tomar la última versión publicada en concordancia con nuestra copia local.
•Es normal ver en muchos de estos sistemas ramificaciones, versiones, etiquetas, o similares, a modo de tener varias copias según nos interese. Estas ramificaciones están en el servidor y en algunos casos puede llegar a ser muy costosa su diferenciación.
Algunos ejemplos de Controladores de Versiones Centralizados:
•Concurrent Versions System (CVS)
•SubVersion
Distribuido
Desarrolladores como Linus Torvalds, Eric S. Raymond y otros más, han desarrollado sistemas distribuidos de control de versiones tales como GIT, Baazaar, Mercurial, darcs, entre otros; estos sistemas se destacan por haber sido desarrollados en un formato distribuido, esto quiere decir que, en sí, no hay un servidor que mantenga una copia del repositorio, sino que está mantenida entre los clientes que estén en uso del repositorio y, al igual que los clientes P2P, mientras más desarrolladores haya conectados, mejor conectividad habrá entre todos.
En cualquiera de los dos casos, el repositorio es compartido por todos los usuarios (o al mismo usuario desde distintas máquinas) que tengan acceso al mismo. Es posible que se produzcan ediciones simultáneas de los mismos elementos que generen conflictos. Para solucionar este problema existen dos políticas básicas de resolución de conflictos:
Bloqueo-modificación-desbloqueo:
En esta política se evitan las modificaciones concurrentes. Cuando un usuario desea realizar una modificación, indica el elemento a modificar que queda bloqueado en el repositorio por lo que se impide el acceso al resto de usuarios (exclusión mutua). Cuando finaliza de realizar sus cambios, los envía al repositorio liberando el bloqueo con lo que el resto de los usuarios puede obtener la copia actualizada para realizar sus propios cambios.
Copiar-modificar-mezclar:
Esta política permite las modificaciones simultáneas. Cada usuario hace una copia del repositorio en su máquina y procede trabajar con ella como si no fuera un repositorio. Cuando finaliza su trabajo, envía los cambios al repositorio que se encarga de analizar los cambios realizados por el usuario y los que se han realizado en el propio repositorio y realiza la mezcla.
Evidentemente, la primera política es mucho más restrictiva lo que dificulta el trabajo diario ralentizando el acceso a los recursos y ocasionando problemas si no se liberan recursos bloqueados. La segunda, por su parte, tiene como inconveniente que no siempre es posible mezclar los cambios realizados aunque en esos casos, utiliza al usuario que envía cambios para solucionar esos conflictos irresolubles automáticamente.
Esto da una serie de ventajas al sistema centralizado, como son:
•Disponer de forma distribuida de la información del repositorio al completo, tanto de forma local, como a través de los demás componentes del grupo.
•Cada cambio se va replicando entre los demás equipos distribuidos, a modo de que puedan emplear esos datos y actualizarlos en sus sistemas.
•El sistema de control de versiones distribuido ha sido pensado con la forma de trabajo basada en ramas, unión central en una sola versión (trunk) y liberaciones (o tags). Con lo que cada rama puede identificarse como cada copia distribuida que se use.
•Una máquina servidora puede emplearse, al estar siempre conectada, como otro punto de sincronización, con la ventaja de que, aunque cayera, mientras haya más miembros conectados, el sistema siempre se mantiene activo y con buen ancho de banda.
Algunos ejemplos de Controladores de Versiones Distribuidos:
•Baazaar
•Mercurial
•GIT
Introducción
El principio de este blog será como una serie de bitácora donde se publicarán una serie de entradas relacionadas sobre el desarrollo para ANDROID, será como una fuente abierta de la plataforma de este teléfono móvil y se explica su ventajas y desventajas, las características básicas, la instalación de los plugins en algunos IDE como Netbeans y Eclipse, de cómo crear el primer proyecto y además de algunos ejemplos.
El propósito de este blog es presentar al usuario de la plataforma móvil nuevo y prometedor basado en el sistema operativo Linux y proporcionada por Google. Además, se introducen infraestructura de código abierto que no sólo apoya el desarrollo, pero también tiene el potencial para convertirse en una actividad principal en el futuro.
Todo desarrollo de proyectos tiene una serie de etapas, y existen software bien importantes que se utilizan durante el ciclo de vida de un proyecto, es por eso que en este blog se publicarán todos lo aprendido en el ciclo de vida del proyecto de DESARROLLO PARA ANDROID., desde metodologias de diseño, administración, programación entre otros.
Somos un grupo de estudiantes del Instituto Tecnológico de Costa Rica con deseos de crear cosas nuevas, donde aplicaremos todos los conocimientos y la investigacion obtenida para hacer de este proyecto exitoso y en el cual podamos aprender todos.
Enjoy
Bernal Fernández Rojas
Steven Mendez Di Marco
Jonathan Esquivel Quesada
Steven Barba Obando
El propósito de este blog es presentar al usuario de la plataforma móvil nuevo y prometedor basado en el sistema operativo Linux y proporcionada por Google. Además, se introducen infraestructura de código abierto que no sólo apoya el desarrollo, pero también tiene el potencial para convertirse en una actividad principal en el futuro.
Todo desarrollo de proyectos tiene una serie de etapas, y existen software bien importantes que se utilizan durante el ciclo de vida de un proyecto, es por eso que en este blog se publicarán todos lo aprendido en el ciclo de vida del proyecto de DESARROLLO PARA ANDROID., desde metodologias de diseño, administración, programación entre otros.
Somos un grupo de estudiantes del Instituto Tecnológico de Costa Rica con deseos de crear cosas nuevas, donde aplicaremos todos los conocimientos y la investigacion obtenida para hacer de este proyecto exitoso y en el cual podamos aprender todos.
Enjoy
Autores:
Bernal Fernández Rojas
Steven Mendez Di Marco
Jonathan Esquivel Quesada
Steven Barba Obando
Suscribirse a:
Entradas (Atom)
