Hacker News Reader

Comment by jc4p | Hacker News Reader

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.

View on HN

> 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/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 :)

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

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.

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.

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

To be honest with you all my experiences with Services have made me never want to use them.

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.

Reply on news.ycombinator.com