4 ms·

What you described sounds a lot like what I used to do for years. It works fairly well, and you can tack a headless Fragment onto it for things that you don't w

by jc4p 10y ago

What you described sounds a lot like what I used to do for years. It works fairly well, and you can tack a headless Fragment onto it for things that you don't want directly connected to an activty's lifecycle (rotating the screen mid user sign-up shouldn't restart the HTTP call, etc). This works well, and I'm at the point where I develop it without thought while creating new apps, but I've been playing with a less constrained DI flow instead using Dagger 2. The more business logic and multiple copies of shared UI elements in different Fragments are directly connected to their parent Activity, the harder it is to re-arrange and re-use them. I've been working on migrating all core elements of our application into a shared library project, and that would've been impossible with a closely tied codebase.

jwatte 10y ago
Have you tried putting all logic into a service, and only using fragments and activities foot display?
- jc4p 10y ago
  To be honest with you all my experiences with Services have made me never want to use them.
  - christop 10y ago
    Binding services is pretty horrible, but I've very rarely had to do it. Using an IntentService is pretty straightforward and covers most use-cases of running something in the background. Though RxJava has quite reduced the amount of interaction I do with Android core components like Services.
bschwindHN 10y ago
> rotating the screen mid user sign-up shouldn't restart the HTTP call, etc This was the very first thing I struggled with when making my first (and to be honest, only) Android app. I was making an HTTP call in a background thread and when the screen rotated, the app crashed. Making this kind of basic functionality harder to program is such a big turn-off for the platform, and seriously lowers my confidence in the correctness of what I've written. I ended up writing this gross code (https://github.com/bschwind/skritter-android/commit/6fdffab111629cb79d732789b83a088e9c335eea https://github.com/bschwind/skritter-android/commit/6fdffab1...). That's probably not the recommended way to solve it now, or maybe it is. I don't know because everyone seems to have their own special solution to the problem, and we're lacking solid, idiomatic solutions to basic problems an app developer faces. For the small Android work I do now, I just stay in my own little NDK world. Edit: It also seems I was pretty frustrated with the android API at the time, lots of colorful print statements :)
- jc4p 10y ago
  I used to use AsyncTask way more, I now stick to other ways to doing background processing. What you have is pretty close to what I described as a "headless fragment", it's a pretty common (but ugly, imo) paradigm, from the looks of it you either made something similar to or followed this: http://www.androiddesignpatterns.com/2013/04/retaining-objects-across-config-changes.html http://www.androiddesignpatterns.com/2013/04/retaining-objec... Nowadays I've pretty much drunk the RxJava kool-aid. For this kind of thing, I would make the HTTP method exist inside of an Observable which would be observed on a shared single instance Looper provided via Dagger.
  - bschwindHN 10y ago
    Yep! I think that's the exact article I settled on after running into that problem. It's been 2.5 years since I wrote that code and I haven't done any significant Android programming since then. Next time I do, I"ll give RxJava a try.
- taneq 10y ago
  Likewise. Pulling the rug from your entire application because the user changed the device's orientation is a braindead action on the OS's part, and the justification (that it 'makes it easier for applications to handle orientation shifts') is pure bullshit. You can relay a layout without tearing down the associated Activity. I think the real reason they did it this way is to make developers deal more directly with Android's larger philosophical choice of "the system can start and stop any activity at any time". Which stinks, IMO - it's fine if you're displaying a property page or an image from a gallery but is a terribly hostile environment to any process which interacts with the (stateful) real world and necessarily must also be stateful.

by jc4p 10y ago

jwatte 10y ago

Have you tried putting all logic into a service, and only using fragments and activities foot display?

jc4p 10y ago
To be honest with you all my experiences with Services have made me never want to use them.
- christop 10y ago
  Binding services is pretty horrible, but I've very rarely had to do it. Using an IntentService is pretty straightforward and covers most use-cases of running something in the background. Though RxJava has quite reduced the amount of interaction I do with Android core components like Services.

bschwindHN 10y ago

> rotating the screen mid user sign-up shouldn't restart the HTTP call, etc This was the very first thing I struggled with when making my first (and to be honest, only) Android app. I was making an HTTP call in a background thread and when the screen rotated, the app crashed. Making this kind of basic functionality harder to program is such a big turn-off for the platform, and seriously lowers my confidence in the correctness of what I've written. I ended up writing this gross code (https://github.com/bschwind/skritter-android/commit/6fdffab111629cb79d732789b83a088e9c335eea https://github.com/bschwind/skritter-android/commit/6fdffab1...). That's probably not the recommended way to solve it now, or maybe it is. I don't know because everyone seems to have their own special solution to the problem, and we're lacking solid, idiomatic solutions to basic problems an app developer faces. For the small Android work I do now, I just stay in my own little NDK world. Edit: It also seems I was pretty frustrated with the android API at the time, lots of colorful print statements :)

jc4p 10y ago
I used to use AsyncTask way more, I now stick to other ways to doing background processing. What you have is pretty close to what I described as a "headless fragment", it's a pretty common (but ugly, imo) paradigm, from the looks of it you either made something similar to or followed this: http://www.androiddesignpatterns.com/2013/04/retaining-objects-across-config-changes.html http://www.androiddesignpatterns.com/2013/04/retaining-objec... Nowadays I've pretty much drunk the RxJava kool-aid. For this kind of thing, I would make the HTTP method exist inside of an Observable which would be observed on a shared single instance Looper provided via Dagger.
- bschwindHN 10y ago
  Yep! I think that's the exact article I settled on after running into that problem. It's been 2.5 years since I wrote that code and I haven't done any significant Android programming since then. Next time I do, I"ll give RxJava a try.
taneq 10y ago
Likewise. Pulling the rug from your entire application because the user changed the device's orientation is a braindead action on the OS's part, and the justification (that it 'makes it easier for applications to handle orientation shifts') is pure bullshit. You can relay a layout without tearing down the associated Activity. I think the real reason they did it this way is to make developers deal more directly with Android's larger philosophical choice of "the system can start and stop any activity at any time". Which stinks, IMO - it's fine if you're displaying a property page or an image from a gallery but is a terribly hostile environment to any process which interacts with the (stateful) real world and necessarily must also be stateful.