Feb 25 | 3:50 PM |
Mark M. | has entered the room |
Feb 25 | 3:55 PM |
Mark M. | turned on guest access |
Feb 25 | 4:00 PM |
Angelos C. | has entered the room |
Mark M. |
hello, Angelos!
|
Mark M. |
how can I help you today?
|
Feb 25 | 4:05 PM |
Angelos C. |
Hello Mark, I have a question about async tasks and configuration changes. Up to now I'm using asynctasks as part of a retained fragment which is kept in configuration changes. Is this still the recommended way to handle them? I'm not 100% developing on android so I'm not sure if something else came up to tackle this
|
Mark M. |
no, AFAIK, if you're using AsyncTask, a retained fragment is still the best solution
|
Mark M. |
now, more and more developers are moving away from AsyncTask into other solutions (threads with an event bus, Rx, etc.)
|
Angelos C. |
:( ok
|
Angelos C. |
where can i find some more info on this ? I'm willing to rewrite the code because managing the fragments is quite a nightmare
|
Angelos C. |
If i remember correctly, on your book example for event bus you were still using a retained fragment (model) ?
|
Mark M. |
in your question, what is "this"?
|
Angelos C. |
sorry, 'this'= event buses
|
Mark M. |
the tutorial is using a model fragment not for managing async tasks, but for retaining model data across configuration changes
|
Mark M. |
that too has not changed
|
Mark M. |
however, there is no requirement that a background operation have to produce something that might need to be retained across configuration changes
|
Feb 25 | 4:10 PM |
Mark M. |
I'm not sure exactly where the "nightmare" comes into play with a model fragment, though I suppose there can be one
|
Mark M. |
fragments overall, for GUI work, can get complex, but a pure model fragment is pretty simple
|
Mark M. |
in terms of how to use event buses, I use greenrobot's EventBus in a lot of samples
|
Mark M. |
however, I do not remember off the top of my head which ones might not involve a retained fragment
|
Angelos C. |
the 'nightmare' is for my retained fragments, I'm using 1 retained fragment for each ui fragment. So if a have a SongsFragment i also have a SongsDataFragment (retained), ArtistFragment an ArtistDataFragment etc
|
Mark M. |
I usually keep the model fragment as being a per-activity thing
|
Mark M. |
not a per-fragment thing
|
Mark M. |
each fragment could contribute to that model, though, for things that are unique to it
|
Mark M. |
but that doesn't require a separate model fragment for each UI fragment, any more than you need a separate server for each UI fragment that does network I/O
|
Feb 25 | 4:15 PM |
Angelos C. |
ok Mark, I'll have a look greenrobot
|
Angelos C. |
one more question, which image library do you suggest? I was using universal image loader which is now deprecated
|
Mark M. |
they deprecated UIL?
|
Mark M. |
I missed that
|
Mark M. |
I think I still have a book example using it
|
Mark M. |
:-(
|
Mark M. |
anyway, my go-to solution is Picasso
|
Angelos C. |
yeah, the developer doesn't have enough time to support it.
|
Mark M. |
yup, all too common
|
Angelos C. |
that was all Mark, thank you for your support
|
Mark M. |
that doesn't mean you can't use it, but it's definitely something to move off of eventually, either to a maintained fork or to another library
|
Mark M. |
you are very welcome!
|
Feb 25 | 4:40 PM |
Angelos C. | has left the room |
Feb 25 | 4:55 PM |
Mark M. | turned off guest access |