Posted tagged ‘software’

Android como plataforma de desarrollo

25 abril, 2019

Hola a todos,

Trayéndoles las siguientes notas del curso de Android, ahora vamos a conocer a Android como plataforma de desarrollo. Conoceremos las herramientas con las que podemos producir aplicaciones Android, cómo se administra la ejecución de las aplicaciones, cómo y qué se debe tomar en cuenta al desarrollar una aplicación.

Aquí las notas: http://www.nachintoch.mx/teaching/mobile_dev/android-framework.pdf

Vociferación: Frameworks y plataformas de desarrollo simultáneo

10 septiembre, 2016

Hola a todos,

Durante el último año, en diversos proyectos y por diversas razones he tenido que usar frameworks. No estoy seguro de qué tan importante pueda ser o qué tan impresionante sea el hecho; pero nunca antes había usado uno.

Sí, los conozco desde hace muchos años; sé para qué sirven y porqué se usan. Pero si decidí estudiar ciencias de la computación sobre todas las demás carreras afines a las TIC y/o la informática; fue porque quería aprender… Aún quiero aprender. Quiero saber muchas cosas; aún cuando soy consciente de mi efímera existencia en este universo vasto y dinámico, quiero tratar de aprender todo lo que pueda que me ayude a entenderlo mejor, a entenderme mejor y a desarrollar software de muy alta calidad.

También es cierto que soy muy práctico y a diferencia de muchos de mis colegas, prefiero trabajar en proyectos de desarrollo de software y/o hardware antes que realizando investigación y escribiendo artículos científicos; supongo que es lo único que puedo agradecer a mi último empleador: me enseño que es posible desencantarse por la industria y la academia al mismo tiempo (¡una condición de carrera salvaje ha aparecido!).

Pero por ahora quiero dejar eso de lado y enfocarme a los framworks y el desarrollo de sistemas computacionales…

¿Qué es un framework?

Para aquellos; estimados lectores, que no estén familiarizados con un framework, va una breve descripción.

Se conoce como “framework” a un conjunto de bibliotecas que resuelven; usualmente, más un problema.

A su vez, una biblioteca es un conjunto de rutinas/métodos/funciones y constantes que conforman un programa de computadora. Sin embargo, conforman un programa que no tiene un propósito especifico y que no está diseñado para ser ejecutado por sí solo.

Las bibliotecas las usamos casi todo el tiempo; seguramente todos hemos hecho algo por el estilo:

#include <stdio.h>

import java.io.PrintWriter;

library(Rlab)

require “template.php”;

Son ejemplos de importación de bibliotecas. Esto nos permite usar funciones definidas en ellas sin tener que implementarlas nosotros mismos. Esto es muy útil porque normalmente sólo podemos hacer llamadas al sistema a través de bibliotecas. Estas llamadas al sistema pueden ser: imprimir algo en la pantalla o en impresora, leer datos del teclado, dibujar en pantalla, abrir un archivo, escribir un archivo, etc… Y no nos tenemos que preocupar por como funcionan y mucho menos por tener que implementarlas.

También nos permiten usar instrucciones recurrentes en nuestros programas; como convertir una variable de tipo numérico a cadena de texto, usar funciones trigonométricas y calcular potencias.

Las bibliotecas tienen propósitos muy bien definidos y no suelen ser muy extensivas. Incluirlas en nuestros programas suele ser seguro, no los hace pesados ni ineficientes. Al contrario, muchas veces es recomendado usar las bibliotecas del sistema o del lenguaje antes de hacer nuestras propias implementaciones, ya que contienen software robusto y eficiente que hace los mejores usos de la plataforma en cuestión.

Ahora bien; por otro lado,

¿Qué es una plataforma de desarrollo paralelo?

Usualmente es todo un IDE (entorno de desarrollo integrado); que nos permite desarrollar aplicaciones para más de una plataforma. Típicamente se desarrolla en paralelo para Windows y Mac, Android y iOS. Además de tener editores de texto especiales para los lenguajes de programación para los que están orientados (rara vez el oficial de alguna de las plataformas objetivo), cuentan con una serie de bibliotecas y representan también un o varios frameworks…

Frameworks…

Oh los frameworks…

Aún en una carrera con un enfoque más teórico que práctico, una de las primeras cosas que nos hicieron entender muy en claro en la carrera, es que un computólogo debe aprender a diseñar, desarrollar y mantener software (yo agregaría que hardware también; luego creen que sólo es posible programar modelos de cómputo y se les olvida que la máquina donde los escriben es hardware y para el colmo: máquinas de registros) de calidad, eficiente y robusto.

Hay muchos problemas con los frameworks, que trataré de desglosar a continuación y empezando por continuar la idea de las bibliotecas.

Los frameworks son monstruos.

Cuando el Dr Frankenstein puso en práctica sus conocimientos de química para jugar el papel de dios y crear vida, dando origen a su monstruo (que ni nombre tiene); al darse cuenta de lo que había hecho, tuvo un miedo terrible y auténtico. Un miedo que lo llevó a tratar de matarlo y destruirlo; que lo llevó al fin del mundo y luego a la muerte del doctor.

Pasa algo similar con los frameworks… No puedo simplemente vociferar contra ellos y afirmar que sus creadores deberían sentirse mal de lo que hacen, porque en muchos casos se tratan de proyectos de software libre impulsados por las comunidades que fomento, admiro y participo. Pero somos nosotros; los desarrolladores de cualquier índole, los que estamos dándoles un mal uso, abusando de ellos y trayendo sus problemas a nuestro trabajo.

Al ser un conjunto de bibliotecas y al tener un propósito que escala con el número de ellas, se vuelve difícil tanto su diseño; como API, como su integración en sí misma y es común que los usuarios de las frameworks descubran que si llamas ciertas rutinas en un orden particular, causas estados de memoria incorrectos y al final tu aplicación crashea o empieza a producir comportamientos inesperados.

Me gusta la forma en la que Joel on Software habla de esto (aquí la fuente: http://discuss.joelonsoftware.com/?joel.3.219431.12). Usa como analogías los martillos. Hay martillos de muchos tipos y cada tipo de martillo tiene propósitos específicos; como clavar un clavo o encajar estacas especiales en concreto o asesinar a tu exnovia (¿y el dolido?).

Pero crear un martillo universal no es buena idea porqué resulta que lo que tener un martillo que hace de todo, resulta en un martillo con mal desempeño en todas sus funciones.

Aumentan la curva de aprendizaje de una tecnología innecesariamente

Si no eres un experto en redes pero tienes que desarrollar un software que se debe comunicar por red, es posible que uses un framework. No tienes idea de como funcione, pero sabes que si usas ciertas rutinas de configuración, puedes empezar a pasar mensajes a otras rutinas y ¡voila!

En papel y platicado se escucha muy bien y hasta dan ganas de experimentar con diferentes frameworks para desarrollar pronto y fácil diversos tipos de aplicaciones… Hasta que empiezas a aprender un framework.

¿cuanto tiempo puede tomar aprender a usar un framework? Depende de la persona y del framework; pero yo me atrevería a decir que este tiempo puede ir de una semana a unos dos meses. ¿alguien se ha puesto a pensar que es aproximadamente el mismo tiempo en el que podrías haber aprendido a no sé… usar sockets? De hecho, aprender a usar sockets puede tomar solo una tarde (quizá larga, pero si a sabes programar, sólo una tarde sin entrar en detalles).

En este sentido, me gusta como Tomas Petricek nos deja bien en claro que es mejor diseñar y desarrollar bibliotecas antes que frameworks; porque los frameworks, son del diablo (http://tomasp.net/blog/2015/library-frameworks/).

¡Nos están haciendo más flojos de lo necesario! Y además, tontos…

La gente ajena a la programación y el desarrollo de software se está acostumbrando a que la única forma de crear software/hardware (arduino, ¿estas oyendo?) es a través de un framework, y tienen la idea de que programar es tedioso y tremendamente complicado.

Como lo ha dicho antes Linus Torvalds; yo también quisiera que más personas descubrieran lo divertido que es programar.

Los programadores se sienten cada vez menos capaces e interesados por aprender nuevas tecnologías, lo cual terminará por acortar sus vidas laborales mucho antes de lo normal.

¿para que aprender Android si Corona te produce simultáneamente aplicaciones para iOS también? Aprender Android debe ser muy difícil, mejor uso Corona…

Pareciera que los desarrolladores ahora se sienten menos capaces de hacer algo por ellos mismos y prefieren usar algún framework… Vamos chicos, que la satisfacción por un trabajo bien hecha no te la da nadie.

Los framworks y plataformas de desarrollo paralelo siempre van atrás de la demanda real

Y lo entiendo, tener que desarrollar una plataforma que tantas cosas es complicado y resulta en una arquitectura compleja. Pero mientras sale la nueva versión de la plataforma de desarrollo paralelo que soporta la última versión de Androd o iPhone (o las últimas actualizaciones); puede estar dejando a tras a los proyectos que quieren usar las nuevas tecnologías que implementen estas nuevas versiones de las tecnologías objetivos (Android/iPhone en este ejemplo) hasta por 6 meses… Y todo por no querer aprender Java, Objective-C o lo que se necesite…

Este es un problema porque también deja atrás a los desarrolladores que no se acostumbran a los cambios. La plataforma de desarrollo paralelo puede abstraer tan bien las operaciones subyacentes, que la forma de crear aplicaciones en cada versión es casi la misma; mientras que los desarrolladores nativos sabemos que cada versión trae cosas nuevas y en algunos casos, deja morir cosas viejas.

De hecho, aprendí Android inmediatamente después de haber aprendido Java Micro Edition: noté que estaba habiendo un cambio en el mercado y que el número de usuarios en Android parecía crecer mientras que el de Java ME disminuía.

Y fue una experiencia provechosa, haber sabido Java ME primero, me ayudó bastante a entender los conceptos y formas de trabajo de la plataforma Android; siento que en realidad fue un plus y una buena experiencia. Y desde el día que empecé a leer cómo programar en Android, estaba consciente de que un día, vendrá otra cosa y Android quedará olvidado y tendremos frases equivalentes para “¿se acuerdan cuando los celulares no soportaban operaciones de punto flotante por hardware..?”.

De verdad, no debemos tener miedo a aprender cosas nuevas, ni al constante ritmo cambiante de la tecnología. No podemos depender de los frameworks y plataformas de desarrollo paralelo para resolver este problema; porque no sólo llegan tarde, también…

Estamos creando software de mala calidad y además nos atrevemos a cobrar por él

Por diversas causas; como ya he comentado, los frameworks suelen traer bugs y cuando los insertamos en nuestros proyectos; no estamos más que haciendo herencia de sus bugs.

Además, el desarrollar sin comprender las capas subyacentes no nos permiten ni aprovechas sus  fortalezas, ni evitar sus debilidades: dependemos de la plataforma abstracta de trabajo; y no queda más asumir que funciona 100% bien… Lo cual no es cierto del todo.

Es bien sabido por un desarrollador, que es una mala práctica importar bibliotecas que al final no usas, ya que sólo se integrarán al código y lo harán más pesado y en algunos casos, lento. Afortunadamente, muchos compiladores resuelven esto y no incluyen en el código funciones que no se usen nunca. Pero dependiendo la plataforma y la estrategia de trabajo, esto puede ser difícil de evaluar y normalmente incluyen todo.

Esto escala cuando usamos frameworks.

Al ser un conjunto de bibliotecas, traen muchísimas cosas encima y normalmente no vamos a usarlas todas ellas; y por la forma en la que se estructuran: al compilar obtenemos una aplicación inmensa, y por las capas de abstracción; irresponsiva.

Recuerdo cuando empecé a desarrollar en Android y muchos lo criticaban; argumentando que iOS era mejor porque no usaba virtualización. Para mi Android siempre ha sido mejor por diversos motivos; empezando porque es software libre. Pero ahora con un mercado lleno de aplicaciones hechas en plataformas paralelas, iOS sufre de un problema similar por las capaz de abstracción de las plataformas de desarrollo paralelo y los dispositivos Android, parece ser una plataforma más lenta de lo que en realidad es.

En consecuencia, el usuario no disfruta al 100% de la experiencia que le puede ofrecer su dispositivo y los vendedores se cuelgan de esta situación para venderte uno con mejores características de hardware… Entiendo completa y perfectamente el hecho de que las computadoras tienen una vida útil limitada; principalmente por el mal uso de los usuarios y porque conforme avanza la tecnología, el software quiere hacer mejor uso de las nuevas capacidades que un modelo de hace algunos años no soportaba… Ahora parece que el hardware tiene que ajustarse al software (al menos en los móviles).

Esto no es justo. Estamos desangrando sin necesidad a los usuarios y sin ninguna razón ni justificación válida. ¿acaso se nos ha olvidado que también somos usuarios?

Pareciera que producir software de calidad ya no es importante; lo importante es sacarle al usuario todo lo que tenga, así nuestro sistema se una completa porquería.

¿quieren un ejemplo?

La aplicación de facebook. Facebook es una empresa de poder adquisitivo inmenso. Y aún así, se atreven a desarrollar y publicar la aplicación que da acceso a su red social en plataforma de desarrollo paralelo. ¿El problema? no solo es lenta; es inútil. Cuando abres un enlace en la aplicación, encima una pestaña que muestra la página web del enlace. Para esto, usa el navegador por defecto del sistema.

Peor aún. Si la página tiene un enlace a facebook; para los comentarios, para darle like o por alguna razón; ¡abre facebook en el navegador embebido! ¿que les cuesta diseñar correctamente su aplicación para que se cierre la pestaña del navegador y se muestre el contenido en la aplicación! Se supone que quiero la aplicación de facebook porque así navegar por la susodicha red social es más cómodo, rápido y eficiente; pero hey, ¿sabes qué?

Acércate.

Un poco más.

Sin miedo; sí, me falta un tornillo, pero no estoy tan loco.

La aplicación es inútil porque no cumple su propósito. Si quiero ver el contenido en un navegador, mejor uso el de mi preferencia… Y ni eso puede hacer bien. Para el colmo la app es mundialmente famosa por atascar la memoria de cache y pesar muchísimos megas. Ese mal gestión de memoria y excesivo tamaño son el resultado de una compilación en plataforma de desarrollo paralelo (y un grupo de desarrollo con decisiones extrañas). Contraste el desempeño, tamaño y cache de la aplicación de Facebook, con la de Google+ (hint, una de las dos es desarrollo nativo).

Pero las aplicaciones para móviles no son el único sector afectado por esta situación. Hay otro que en lo personal me parece más interesante: los videojuegos.

visage-bug-assasin-screend-unity-03

I’M ERROR UNITY. Screenshot de Assassin’s Creed Unity: un producto de usuario final con etiqueta de precio de venta no negociable.

Tanto los juegos de consola, como los de PC y los de móviles se han visto afectados por este tipo de problemas. ¿recuerdan que Pokémon Go; el juego que parecía el prometido, comenzó a perder usuarios por las constantes fallas y malas decisiones de Niantic? Pues quizá la primera de todas las malas decisiones fue desarrollar un juego de realidad aumentada; que va a exigir mucho a los GPU de los móviles, usando Unity: un framework de peso completo.

pokemon-go-elegido

Pokémon Go, eras el elegido…

Y aún siendo un producto por el que se cobra licencia bajo ciertas condiciones, el soporte para Unity es muy limitado; muchísimo más que para casi cualquier plataforma de dearrollo libre.

Finalmente, tengo que aceptar que hay buenos juegos hechos con frameworks y plataformas como Unity, los cuales acepto que disfruto; pero parecen ser exactamente el tipo de juegos para el que fue diseñado en engine o son suficientemente simples y la plataforma no cumple su promesa de ser general y aún así un juego que nativamente podría pesar apenas lo que los recursos gráficos, sonidos y otros medios, termina pesando hasta 1Gb por también incluir tooodo el engine; aunque no lo use y en tiempo de ejecución así se comportan.

En conclusión

Los frameworks tienen utilidad al desarrollar prototipos; no creo que puedan usarse para publicar productos de usuario final, sin importar que el usuario final sean otros desarrolladores; tanto de software como hardware. Los frameworks nos pueden ayudar a crear software modular, que después debe ser revisado y corregido por expertos en las áreas para las que se utilizó el framework en primer lugar y poder desecharlo.

Los frameworks sirven para ayudar a adentrarse en el desarrollo a personas ajenas a las tecnologías informáticas; como los artistas que desean adentrarse en el desarrollo de videojuegos; y otros interesados.

Pero tarde o temprano; y siempre antes de distribuir un producto, debe de sustituirse el framework por software funcional, probado, eficiente y orientado al propósito que se desea satisfacer.

En lo personal creo que es un insulto hacerme trabajar con frameworks. Si hay algo que se hacer bien, es programar, diseñar y desarrollar sistemas computacionales. Si estoy equivocado, que me aquellos que me conocen y que en cualquier forma hayan trabajdo con migo, me corrijan.

No sé porqué tirar a la basura mi conocimiento y mi trabajo por usar el software que está de moda.

En fin, tratemos de usar los frameworks en casos donde sean realmente necesarios y usar el framework adecuado; que el límite sea la imaginación, no la escasa documentación…. y soporte…. De productos por los que al final tienes que pagar… sigh


A %d blogueros les gusta esto: