#20428 gracias por la respuesta hermoso. Sinceramente, si Android es tan poca cosa lo dejaré para un par de semanas antes de empezar el curso y listo, tengo mucho que estudiar en verano xD
Aunque creéis que es mejor saber como va Android antes de meterse con Kotlin? (lo veré algo más a fondo ya que en el FP no lo daremos)
Mejor Kotlin antes que Android, igual que mejor Java antes que Android. Si no conoces lo mínimo de la sintaxis no vas a entender el framework ni ejemplos de código.
#20431 No es tan poca cosa como parece eh? Si hay algo q no me mola es la cantidad de bolierplate que hay q hacer para cualquier cosa. Pero en definitiva paso a paso de hace cualquier cosa q quieras si buscas y tienes paciencia.
@vincen te pregunto. Tú te acuerdas de todos los metodos que has de utilizar, los override, nombres de clases, propiedades, lo q tienes q usar y demás historias cuando haces apps? Porque yo esto y continuamente en Google y en la web de android buscando el hacer X cosa porque tienes q usar doscientasmil cosas para hacer algo.
#20433 Hombre, yo con dos semanas le meto 40h de Android xD, podría estar bien para comenzar el curso
#20433 No, todo no, pero me pasa en cualquier lenguaje, eso ya es cosa de la memoria, cosa que ando mal.
En el caso de la APP de android que tengo es una app "sencilla"
Hago unas llamadas a mi API, uso gson para pasar el json a una variable con clase y el resto de la app es usar esa variable usando RecyclerViews con custom Adapters..
Quitando lo ultimo que hice que fue añadir recordatorios con notificaciones con AlarmManager y un Receiver/Servicio para añadir las alarmas si el teléfono se reinicia.. lo demás no es complejo, solamente lleva tiempo xD
En esta app reutilizo mucho codigo..
#20430 esto te pasa por no separar la app en capas de abstraccion.
La Activity deberia ser atomica, se dedica simplemente a gestionar la vista y logica asociada a ello. Los datos los deberias guardar en un repositorio en el que tu controlas su lifetime, por poder puedes usar un singleton que tienes siempre cargado en memoria, o si quieres algo mas trabajado cargas en demanda de una BD o un JSON cuando toca, etc.
#20435 Pero d normal, no sé, para usar casi cualquier cosa actual de material o de hardware se tienen q llamar a clases pasandole otras clases con unos atributos y luego utilizar esos objetos para crear otros y mucha cosa q yo sinceramente a no ser q sean componentes q se usen mucho en distintos sitios no creo q sea capaz de recordar todsd esas cosas.
Dicho así suena típico de cualquier tecnología y no dudo q así sea, pero parece q o conoces muy muy bien toda la arquitectura de diseño del sdk de android y todas sus clases y pars qué o vas siempre tirando de google para que te diga qué hay que hacer.
#20436 En realidad por mucho que separes tu App por capas usando MVP, MVVM o lo que quieras, es muy fácil cagarla con el ciclo de vida de Android hasta que te aprendes todos los gotchas.
Entiendo que tb estaba pensado para funcionar en dispositivos con muy poca RAM, y de ahí el diseño que montaron..
Yo para empezar aconsejo aprender a diferenciar lo que es android/java/kotlin, hay un curso de 5 minutos en udemy creo.
#20436 No sabia la existencia del singleton xD
Me viene bien la verdad, soluciona el 50% de mi problema además de que es mas cómodo.. ya que por lo que veo crea una única instancia del modelo y así puedo usarlo globalmente en la app sin tener que andar pasando el modelo entre actividades/fragments y evitar duplicar datos.
Ahora, para solucionar el error que comentaba, digamos que para lo que es el fragment de "contactos" con su RV, en onCreate tengo esto:
Es un ejemplo rapido inventado..
Entonces soluciona el problema a medias, que por poder podria mandarle a la pantalla de contactos, pero estaria bien mandarlo a la ultima vista..
#20443 uf, como alguno de este hilo vea ese código te va a despellejar.
Así por encima, en vez de usar el getContext con ese cast horroroso usa getActivity(), plantéate por qué metes un json en las shared preferences a piñón en vez de meterlo en una tabla SQLite, ¿por qué quieres el String "NULL" como valor por defecto en las shared preferences? eso es un crash garantizado si luego lo deserializas...
Luego lo miro con más detalle porque me acabo de levantar y creo que todavía me dura el ciego. Lo más gordo que he visto ahí es que ese fragment crasheará en cualquier Activity que no sea MainActivity.
#20446 No me meto a construir un petardo sin saber antes como se hace un petardo.... No va de ir por la vida aplicando el prueba-error ...
No se trata de nacer aprendido, se trata de ser profesional... Que parece que aquí programa cualquiera que deje caer una pelota saltarina en el teclado....
Dicho de otra forma.... si es un estudiante se entiende, todos tenemos que aprender... si es un profesional que cobra por su trabajo me sorprende.... pero me sorprende del mismo modo que me sorprendería que un arquitecto no supiese de la existencia del cemento...
#20444 Controlo lo del NULL en otro lado, nunca voy a llegar a ese codigo si la sharedpref es null, como he dicho era un ejemplo rapido.. Ya llegue a la conclusion de que en este caso era mejor sharedprefs que sqlite, la APP no tiene mas de 1 activity, solo fragments.
#20443 No me he leido los conceptos basicos de la programación Hulio, todo lo que he aprendido sobre la marcha, y no me ha ido mal, también es cierto que vengo de PHP y no tiene nada que ver.
Ni soy estudiante, ni trabajo para una empresa, todo lo que programo son proyectos propios, que es como he aprendido todo lo que se. Voy aprendiendo sobre la marcha y no me va nada mal la verdad.. Que no se algo tan básico como los Singleton? Pues se aprende, cual es problema? Que no sigo los patrones básicos de aprender a programar? Que le vamos a hacer..
Ya no me sorprende FEDA xD
#20452 En caso de que no sea absolutamente necesario, deberías evitar usar singletons y estado global en general. Te recomiendo leer sobre dependency injection e inversion of control. Te vendrá bien para hacer tests.
#20450 #20453 #20456 Singleton es muchas veces un antipattern, pero viendo que sus conocimientos de programacion son escasos no me voy a poner a hablarle de DI/IoC para al final hacer lo mismo. Si le soluciona la vida, ya tendra tiempo de ir profundizando por su cuenta y aprender alternativas mas robustas.
#20443 estamos en las mismas, estas asociando a un objeto con una vida limitada algo que trasciende su lifetime. De ahi que necesites tener tu capa de datos, donde vive el singleton con todos los contactos, contacto seleccionado, metodos para actualizar esos contactos, etc; y luego la activity/fragment que su funcion es presentar al usuario los datos (capa de vista) de dentro de ese singleton. Cuando el lifecycle de la app te los mate te dara igual, porque al reconstruirse accederan a los datos que estan guardados en una posicion de memoria estatica y siempre seran iguales mientras la app no se haya cerrado completamente.
