4 ms·

> 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 hone

> 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.

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.