androidvsxml

Android, su SDK y sus XML, ni contigo ni sin ti

1 Star2 Stars3 Stars4 Stars5 Stars6 Stars7 Stars8 Stars9 Stars10 Stars (3 votes, average: 8,67 out of 10)
Loading ... Loading ...

Como bien sabréis una aplicación Android se basa en dos apartados, la parte gráfica y el código. En este caso el apartado gráfico se construye de manera visual en principio gracias al SDK de Android, pero si lo comparamos con otros SDK´s nos acabaremos dando cuenta de lo pobre que es, por lo menos para todas las versiones anteriores a HoneyComb (Android 3.0). Digo hasta HoneyComb ya que la interfaz cambia un poco, los widgets son distintos y es una versión orientada a otro tipo de dispositivos, por lo tanto está algo verde pese al gran trabajo que han realizado y esperemos que lo mejoren aún más para cuando llegue Android “Icecream”.

Primer vistazo:

Antes de empezar a meter fondos y demás elementos a nuestra carpeta de recursos del proyecto, generalmente lo primero que tocamos suele ser el “main.xml”. Este fichero dispone de una extensión corta y realizar cambios o añadir código no supone mayor complicación más que la incomodidad de buscar entre los atributos uno por uno.

XML - elaborado

XML – elaborado

Fijémonos por el momento en Visual Studio 2010. Tenemos nuestra lista de widgets y a la derecha tenemos las propiedades de aquellos que arrastremos sobre nuestro formulario y pinchemos sobre ellos.
Este sistema se vuelve muy cómodo y fácil de usar, no así como navegar entre todas las etiquetas de nuestro archivo XML para poder cambiar un “@string”, un color o un simple fondo. A esto podemos sumarle que un listado de propiedades es y será siempre muchísimo más cómodo que andar buscando uno por uno dinamicamente con el Control + Espacio de Eclipse.

¿Compatibilidad? ¡Sus carpetas!

Uno de los pasos más decisivos que tendría que tomar la plataforma Android es la mejora de su SDK para facilitar la creación de interfaces de una manera más sencilla. Teniendo en cuenta que uno de los problemas de Android a día de hoy es la fragmentación y la gran variedad de tamaños y tipos de pantallas que disponen los terminales que lo implantan, es un buen comienzo intentar automatizar todo ese tramite de compatibilizar la aplicación para los distintos móviles.

<LinearLayout android:orientation="vertical"
	android:layout_width="fill_parent" android:layout_height="wrap_content">
<TextView android:text="@string/lbl_email" android:id="@+id/lbl_email"
	android:layout_width="120dp" android:layout_height="wrap_content"
        android:textSize="18sp">
</TextView>
<EditText android:singleLine="true" android:layout_width="120dp"
	android:id="@+id/login_email" android:maxLength="512"
	android:layout_height="wrap_content" android:inputType="textEmailAddress"
	android:hint="@string/required" android:layout_marginBottom="20dp"
        android:textSize="18sp">
</EditText>
<TextView android:text="@string/lbl_password" android:id="@+id/lbl_password"
	android:layout_width="120dp" android:layout_height="wrap_content">
</TextView>

Un buen ejemplo es el SDK de iOS que permite diseñar interfaces de una manera sencilla y eficaz (dejando de lado la complejidad de codificar después), aunque también deberíamos tener en cuenta que Apple fabrica sus móviles y su SO es bastante especifico lo que aporta grandes beneficios a la hora de desarrollar para esa plataforma.

Android - Drawables

Android – Drawables

Os pongo un pequeño ejemplo, si estamos realizando una app y queremos ejecutarla en 3 móviles con 3 densidades de pantalla distintas, tendríamos que triplicar los archivos de imágenes que tenemos y cambiarles la resolución (véase hdpi, mdpi y ldpi), deberiamos cambiar los tamaños de los elementos que tengamos en los XML por “fill_parent”, “wrap_content” si es posible y de no ser así, sustituir por “dp”, de tratarse de texto por “sp”…aburrido,tedioso y lento.

Cuando un programador con experiencia en su trabajo se encuentra ante esto puede quedarse un momento dubitativo, ¿Pero que pasa cuando no hay experiencia de por medio?. Para un programador novato no es facil anteponerse al código XML y la manera de tratarlo del SDK de Android y eso debería de cambiar, cuanto antes a ser posible.

¿Ni contigo ni sin ti? No, de la mano de Init

Para concluir me gustaría añadir que pese a ser pesado y tedioso leerse un XML en busca de fallos o modificaciones, la practica hace la experiencia y para ello abordaremos de ahora en adelante los XML con más atención, dando explicaciones claras y fáciles de entender para todo el mundo en las próximas entradas. Recordad que si sois fans tanto de Android como de iOS o XML, podéis comentar y de este modo charlar sobre el tema para ver la diferencia de opiniones y puntos de vista. De momento os planteo las siguientes preguntas.
¿Es más fácil dibujar interfaces en iOS que en Android?¿Os parece XML un lenguaje fácil y claro?

Un saludo y os espero en los comentarios.

  • jmarti

    Se nota que alguien está un poco “quemado” haciendo una aplicación que yo me sé y que además se tenga que ver bien en tablets, en el nexus y en el hero, no?? :) ))

    Estoy de acuerdo en general, aunque no sé muy bien si lo que propones es destruir el XML de la faz de la tierra, o que Android mejore la facilidad de hacer el diseño de layouts. O ambos.

    La verdad es que el editor de diseños es bastante precario… Estaría guay que existieran aplicaciones que lo mejoraran…

  • afernandez

    En sí XML es un buen lenguaje, a decir verdad por ejemplo Visual Studio también trabaja con XML´s por detrás. Pero por parte de Android falta automatizarlo, ser un poco más developer-friendly.

    En mi opinión no creo que tenga que haber una aplicación que mejore el apartado de interfaces del SDK sino que la propia empresa lo mejore y cuide de sus desarrolladores y tiene a nuevos para que desarrollen en esta plataforma.

  • Jkeycode

    Lo que debería hacer, seria intentar igualar el desarrollo de la interfaz gráfica a la facilidad de vb, y ya puestos que se hagan un eclipse tuneado con todo bien configurado a falta de un IDE propio, como hace zend

    • afernandez

      No estaría mal, pero me gusta la funcionalidad de Eclipse, deberían de mejorar el IDE, en eso estoy de acuerdo.

  • http://www.yeradis.com Yeradis P. Barbosa Marrero

    Saludos

    Un articulo interesante, al menos su idea como material introductorio, se nota la preferencia por iOS y supongo que por eso mismo las “suposiciones” o valoraciones que rozan lo falso.

    Decir que el SDK de Android es muy pobre comparado con otros, sobre todo las versiones antes de Honeycomb es una blasfemia, partiendo de que la version de Android para tablets no ha introducido cambios super significavos a la paleta de componentes visuales de Android, cierto que introdujo sus cosillas, pero de ahi a dar a entender que antes de Honeycomb Android era una castaña demuestra un desconocimiento de la plataforma Android y mas aun de su evolucion.

    Ademas, a que otros sdk te refieres? porque solo podrias incluir en esos otros a “iOS, windows phone”, digo solo a esos porque son los mas nuevos y los que mas estan dando de que hablar (no se nota? xD )

    Tambien dices que una aplicacion Android se basa en dos apartados: la parte grafica y el codigo

    Lo cual es otra informacion erronea, principalmente porque en Android no solo existen las aplicaciones visuales, sino que existen muchas aplciaciones que son servicios y pasarelas a otras operaciones.

    Pero si quieres generalizar, es cierto que muchas aplicaciones su funcionamiento principal radica unica y excluvisamente en el componente visual.

    Ademas, las aplicaciones Android implementan en cierto modo el patron MVC en su estructura y funcionamiento. Desmontando lo que dices qe se basa en dos partes la visual y el codigo, ya que ademas existen partes de las aplicaciones android que no son ni una ni otra.

    No niego que el diseñador visual de ventanas que ofrece ECLIPSE, NO ANDROID deja mucho que desear, es muy mejorable. Pero si lo has probado(por lo que escribe no lo parece) veras que en cierto modo funciona como los demas, tienes tu paleta de componentes y los arrastras hacia el contenedor principal donde definiras sus propiedades y comportamientos y todo de manera VISUAL.
    Aqui solo hablas de la experiencia que se tiene al iniciarse en Android y se trabaja solo con XML. Es normal que sea frustrante, si te fijas en la ventana donde defines el layout con su xml abajo a la izquierda tiene una pestañita que te permitira cambiar al diseñaor visual de ventanas, podras cambiar facilmente los background, los strings y demas propiedades, podras definir los comportamientos de la ventana y sus vistas asi como los contenedores entre muchas mas cosas. Pero creo que no lo has visto nada de esta parte de diseño visual sino verias que en el plugin par a Eclipse tambien tienes tu listado de propiedades ese que siempre es mucho mas comodo que el Control + Espacio de eclipse para el autocompletado y sugerencias.

    En cuanto a la compatibilidad, fragmentacion y demas temas que comentas.

    No te niego que es un coñazo en algunos momentos, pero no de la manera que lo comentas, necesitarias informarte mas del tema y sobre todo buscar que plataforma para moviles ha manejado tan bien el poder ejecutarse en mas de 100 tipos de dispositivos distintos en menos de 3 años.

    La fragmentacion viene principalmente por las diferentes versiones de Android presentes en cada uno de esos dispositivos y por tanto las caracteristicas introducidas en cada version de android son las que generarian incompatibilidad,pero es relativo, el tamaño de pantalla y su densidad para nada se puede contar dentro de la fragmentacion.

    Una cosa es que se venga de iOS donde al ser solo un unico dispositivo el programador y diseñador se vuelva vago y le cueste lidiar con los temas de diseño y la creatividad que hay que aplicar en las aplicaciones Android.

    Desarrollar para un unico dispositivo no aporta grandes beneficios, la diversidad si, como decia antes si se es vago cuesta mas llevar a cabo un trabajo de I+D. Eso es lo que aporta trabajar solo para un dispositivo X, que se pierda la creatividad y la capacidad de afrontar problemas X de diseño. Pero la cultura del pelotazo y el ladrillo supongo que es muy dificil de erradicar. Esto de trabajo una ves y vivo del cuento es lo que tiene. Viva iOS.

    Mencionas un ejemplo ejemplo que es valido, si trabajas con imagenes es lo que tiene, tendras que multiplicar cuanto sea necesario segun la cantidad de densidades y resoluciones quieras soportar, es lo que tiene la varidad, pero tambien podrias usar los patches.9 o los shapes, y te quitarias mucho trabajo de encima, trabajar con imagenes para segun que cosas es una chapuza y demuestra lo poco que se conoce la plataforma.

    Dices que un programador con experiencia se puede quedar debutativo ante el modelo de desarrollo para Android, es posible, pero solo porque no se tiene experiencia con MVC y HCI, ademas acostumbrarse a este modelo es muy facil, actualmente no existe NINGUN SDK que aborde la problematica para el desarrollo de dispositivos moviles como lo hace el de Android, logico que si se desarrolla solo para una cafetera no hay necesidad de mirar mas lejos, por suerte Android no solo mira cafeteras sino lavadores,neveras,teles. Esta pensado para todo tipo de disposivos, algo que no puede decirse de otros SDK ni OS.

    Para terminar, leer un XML si no se esta acostumbrado a ellos suele ser tedioso y pesado, pero uno ves que le pillas el truco no quieres q te den otra cosa y mas cuando ese xml es para la definicio de interfaces como el de ANdroid pero mejor aun si ese xml, la manera en qeu se define es muy parecido al que se usa en WPF y su XAML o traduciendolo al vulgar, la manera en que se definen actualmete las interfaces en .NET

    Ahora a tus preguntas

    ¿Es más fácil dibujar interfaces en iOS que en Android?

    Hombre aqui iOS lleva ventaja, ya que aunque android tiene su diseñador visual y estar pensando para infinidad de dispositivos tiene sus inconvenientes, como seria la facilidad de crear una herramienta WYSIWYG que facilite el trabajo visual como en algunos puntos lo hace la de iOS

    ¿Os parece XML un lenguaje fácil y claro?

    Si me parece muy facil y claro, total ni que estuvieramos hablando de los XML Schemas, igual eso si seria mas pesado

    Sin mas….
    Me despido

    pd: el articulo no esta mal pero tecnicamente no es correcto, como obversaciones y valoraciones y preferencias personales es valido fuera de ahi lo que hace es incitar la polemica xDDD

    • http://steamcommunity.com/id/Bhardiel Igomez

      +1 a lo de los 9-patch. Realmente son una solución con una lógica tan sencilla que casi te hace sentir un poco zoquete por no haber pensado algo parecido antes, pero te ahorran un montón de quebraderos de cabeza en cuanto a diseños en diferentes resoluciones.

    • afernandez

      Gracias Yeradis por tu comentario, cuando redacte el post estaba con un buen puñado de dudas ya que aún me queda un largo camino por recorrer como developer para esta plataforma. Por lo tanto escribí este post en gran parte desde el desconocimiento y desde el punto de vista de un novato, no solo en Android sino en mi todavía por conocer iOS, intentando transmitir como opinión todo aquello a lo que una persona como yo se pueda encontrar al parase a programar.
      Gracias a tu comentario he conseguido darme cuenta de varias cosas que hasta ahora desconocía o para mi eran incorrectas y lo agradezco mucho.
      Respecto a lo que comentas que hay aplicaciones más allá de lo gráfico y del código, tienes razón, con esa frase pretendía abarcar la gran mayoría de aplicaciones que están hoy en día en el Market.
      Te daré la razón también en que el apartado visual tiene sus propiedades un poco incomodas de acceder pero ahí están.
      Respecto a los 9.patch, me costó enterarme de su existencia, pero una vez que los empecé a usar funcionan tremendamente bien, pero como bien dices algunos momentos en los que tienes que usar un tipo de imagen en concreto que no puede ser 9.patch debes meter las 3 fotos y es un poco coñazo.

      Sobre lo de iOS y la vagancia del programador, yo lo llamaría más comodidad para programar, hemos llegado a un momento en los terminales móviles en la que lo más importante debe ser la calidad y si mejoramos de tal manera las herramientas de desarrollo para que los programadores puedan centrarse más en hacer una aplicación de calidad que cumpla sus requisitos y sus ideas principales en vez de hacer una aplicación que haga algo sin pena ni gloria.

      Un saludo y gracias leer, opinar y comentar.

      Pd: Este post era totalmente de opinión y si, que demonios, también para incitar un poco a la polémica haha.

      • http://www.yeradis.com Yeradis P. Barbosa Marrero

        Gracias a ti por dedicar parte de tu tiempo compartiendo tus ideas y publicarlas en forma de articulo en este blog.

  • http://www.theinit.com Javier

    En mi opinión no se pueden comparar las opciones de desarrollo para uno y otro, son dos modelos de negocio distintos y los principios de software otros, por ejemplo, a mi no me gusta xml, ni los uis armados con xml, ni tampoco el entorno armado por defecto como es eclipse con “javagoogleway”, por eso es mi gusto personal, siempre me gusto estar “mas cerca” de lo nativo, por ello hay mas opciones como decia, desde appinventor, nessesitas(qtdesigner), ruby ruboto(desarrollo en el device tmb), mirah, scala, clojure, s4la, o el ndk, lo cual permite al desarrollador a no limitarse cuando algo no nos gusta mucho, eso siempre fue lo bueno de linux: la variedad, impulso que el softwalibre le otorga.

    • afernandez

      Son dos modelos de negocio y principios de software distintos pero cuando nos centramos en el código todos los programas se basan en lo mismo.

      Es cierto que la variedad soluciona muchos problemas ante la necesidad de desarrollo pero muchas veces nos encontramos que perdemos un poco el tiempo intentando abarcar demasiado. Por ejemplo AppInventor es un entorno demasiado simple para desarrollo de aplicaciones normales y su nivel de abstracción es demasiado grande.

      Por otra parte y como bien dices la variedad siempre fue el punto fuerte del software libre y esperemos que la plataforma Android como sus entornos de desarrollo suban de nivel y permitan desarrollar mejores aplicaciones de manera más sencilla.

      Un saludo y gracias :)

      • http://www.theinit.com Javier

        Disculpame, pero una cosa es centrarse en el código y otra es un modelo de negocio y forma, distribucion y legalidad del software, de todos modos has llamado a la oracion de forma asentada así que no vamos a entrar en polémica porque este no es el punto de discusión, esta para una buena charla de café.
        Por lo demas estamos de acuerdo.

        • afernandez

          Entorno a una charla de cafe han surgido algunas de las mejores ideas, tengamos eso en cuenta hahahaha.

          Un saludo y gracias por comentar Javier.

          • http://www.yeradis.com Yeradis P. Barbosa Marrero

            para cuando el cafe? xDDDD