Patrones de diseño - Android

#1 Suscribo todo lo que dices. Desde que programar en Android se convierte en algo muy "guarro" a que no hay absolutamente nada de material de calidad.

En mi actual y eterna fase de aprendizaje me ha ayudado mucho ver código de aplicaciones opensource. Y aun así, se percibe cierto guarreo con los hilos, servicios y demás. Seguro que es posible hacer las cosas mejores, pero esa sensación de código sucio en Android creo que hay que acostumbrarse a ella.

Hay cosas que se pueden mejorar. Yo ahora estoy con un tema de fragments en los que para comunicarme con ellos desde la actividad principal hago ciertas guarradas y hay formas mejores. Por ejemplo, tengo un listview en el fragment. Pero el fragment está dentro de un ViewPager y, por tanto, se crea y destruye cada vez. Con lo cual para no perder la referencia al listview, el objeto que apunta a él lo tengo estático. He visto por ahí código de gente que pilota que lo que hace es implementar una interfaz para comunicar los dos elementos.

Se puede mejorar algo. Pero insisto, el código guarro de Android va a ser siempre guarro. ¿O no ha sido así en web hasta que aparecieron los frameworks? Pues lo mismo. Y damos gracias que ahora empiezan a aparecer patrones de la IU con un cierto estatus de estándares, porque hasta ahora la interfaz payaso de VB6 se veía (y se sigue viendo...) en un huevo de aplicaciones.

Lo único que puedo pasarte son unos cuantos blogs de gente que realmente pilota. Pero libros y tal... difícil lo veo.

edito #2, ajajaja me parto con lo que dices de los listeners. Pero confiesa: ¿a que si lo haces así (separado) te da la sensación (absurda) de que si alguien ve el código va a pensar que eres un n00b) xDDD
Yo hace tiempo que si el contenido del evento tiene más de dos líneas, me hago el listener por un lado en su objeto correspondiente y luego lo vinculo.

Aprovechando el hilo, lanzo una pregunta de noob total.

He comenzado un curso de android esta semana y ahora estoy empezando a familiarizarme con layouts, jugando con los textviews y demás.....pero me pasa algo curioso ¿por qué cuando cambio la id de un elemento se me descuadra toda la puta ventana?.

El ide que uso es eclipse.

#10 indeed.

Yo he comprobado que la reusabilidad de un framework es bastante limitada. Me llevo pegando con distintos frameworks JS desde hace unos meses y TODOS son para un tipo de aplicación concreta.

Al final me quedé con un par que no te obligan a usar ciertas cosas y tomar ciertos caminos, pero tienen capas de abstracción intermedias bastante innecesarias IMHO. Al final he acabado "arrejuntando" librerías y fin.

#16

Hombre, yo de un framework espero cosas que funcionan directamente, y solo hay que poner los detalles de que hay que hacer. Por ejemplo el primer framework que usé hace ya años fue MFC, el framework de Microsoft para programar en Windows antes que que sacasen .net. Con MFC, tu creas un proyecto nuevo, y sin escribir ni una línea de código, tienes algo más o menos así:

Todos los botones de la barra de iconos eran totalmente funcionales, el de abrir, te mostraba la ventana de abrir documentos, y podías seleccionar un archivo (aunque no hacía nada), el de imprimir imprimía la ventana, la barra de estado mostraba lo que hacía cada icono al pasar el ratón por encima, etc. A partir de ahí tú ibas especificando lo que había que hacer con cada operación, y obviamente puedes añadir y quitar iconos, modificar la barra de menús, y todo eso.

Ahora si piensas en un juego, y las cosas típicas que cualquier juego de cualquier género tiene: mapas, npcs, records, pantalla de presentación, cutscenes, etc, si algo no da soporte directo para todo eso, no considero que se pueda decir que es un framework para juegos. Por ejemplo el Source SDK de Valve tiene todo eso, es más, sin escribir una línea de código, simplemente creando un proyecto nuevo del SDK, tienes algo totalmente funcional donde puedes cargar un mapa vacío y moverte en todas direcciones. Si quieres añadir algo al juego, creas una subclase de CBaseAnimating, la inicializas, y automáticamente tienes algo que aparece en el mapa con el modelo 3d que hayas especificado y que colisiona con la física del mapa. Todo el sistema para cambiar de un mapa a otro, para iniciar y terminar la partida, en fin, lo típico que se hace en un juego, está ya hecho y tú lo usas como necesites. Si buscas todo eso en cosas como cocos2d-x o libgdx, es inexistente, lo que tienes es una colección de clases para que las uses como tú veas y te crees tu propio sistema para hacer todas esas cosas.

Normalmente los frameworks funcionan con "hooks", que vienen a ser funciones vacías donde tú pones el código concreto de tú aplicación. Si no escribes nada, tienes una aplicación completamente funcional, que puedes ejecutar y usar, solo que no realiza ninguna tarea concreta. Cada elemento del framework tiene sus propios métodos que funcionan a modo de gancho, así que la forma típica de usar un framework suele ser crear tu propia subclase que hereda del componente del framework que quieres usar, y sobreescribes los métodos que te interesan. Tú ni siquiera controlas cuando se llaman esos métodos, es algo que viene predefinido por el framework.

Vamos que con un framework, más que hacer una aplicación, tienes más la sensación de estar extendiendo una aplicación ya hecha, solo que esa aplicación que extiendes es tan básica, que la puedes convertir un poco en lo que quieras, pero claro eso ya implica que la estructura de la aplicación viene predefinida y es algo que no puedes cambiar.

#18

que no hombre, no es un proyecto de ejemplo, que es que toda la aplicación se hace así, todo tú código está en una subclase de una clase del framework, y hacer una aplicación consiste en eso, haces subclase de X, sobreescribes unos métodos, y ya está. Todo el ciclo de la aplicación para que se ejecuten esos métodos es ajeno a ti y no tienes control sobre ello, y como solo puedes hacer operaciones de esta forma, la estructura de la aplicación ya te viene predefinida.

Al final el problema va a estar en que en programación existe la fea costumbre de usar la misma palabra para todo, es como "componente" que es probablemente la palabra más sobreecargada de todas. Yo la primera vez que vi la palabra framework fue en ese contexto, y es a lo que la asocio.

Y es cierto que en cocos2dx puedes hacer eso, pero está limitado a la parte gráfica, si quieres decir que es un framework gráfico para juegos, estoy de acuerdo en que lo es, pero de ahí no pasa.

Además que yo no he dicho MVC, he dicho MFC (microsoft fundation classes), no tiene nada que ver...

#20

En MFC, si borras el código que te crea el asistente, y lo haces desde 0, ¿con qué acabas? con el mismo código que te ha hecho el asistente... por lo que la estructura de la aplicación viene ya definida, que es lo importante que define el framework, y tú solo trabajas extendiendo esa estructura de la forma que ya hemos hablado, por eso insisto en que no es un proyecto de ejemplo, es que es la única forma que hay de hacerlo.

"Y un framework es un framework tenga la extensión que tenga, a ver si un framework va a tener que hacer TODO lo del universo"

De acuerdo, pero la cuestión es Framework para XXX, ¿puedes decir que cocos es un framework web solo por ser un framework? obviamente no... pues eso mismo, yo no los considero framework para juegos, por que les falta muchas cosas que absolutamente todos los juegos tienen.... a partir de ahí eso ya es una opinión subjetiva, tu puedes pensar que lo mínimo que se necesita es una cosa y yo otra, y yo no los veo lo suficientemente completos. ¿puedes controlar el ciclo de vida de una entidad del juego?, ¿puedes controlar el ciclo de vida de una partida?, no, lo tienes que hacer tú, y dime que juego no necesita eso...

#22

No seas perro, paras la discusión pero sueltas una última coletilla final, y no, no he dicho eso, lo que he dicho es que si algo afirma ser un framework para juegos, tiene que tener soporte ya hecho (no que lo tengas que hacer tú) para lo que mínimo que va a tener siempre un juego. Si no lo tiene, no considero que sea un framework de juegos, y como ya te he dicho (no voy a entrar en bucle repitiendo lo mismo) para considerarlo framework tiene que haber algo más que simplemente clases y funciones relacionadas con eso.

Los juegos normales tienen una partida con un inicio, una duración, y un fin, entidades que son más que un simple elemento visual, etc. Los puedes considerar framework gráficos, framework físicos, framework lo que quieras, pero no es un framework para juegos, es una libreria para juegos, por que te da piezas para que lo hagas tú, no viene ya hecho.

De todas formas no se si crees que esto lo digo con connationes negativas o algo, yo digo que libgdx no es un framework para juegos y lo uso igual, ya ves tú lo que me importa llamarlo A o B....