11

aaaaaghh fucking Handlers man. Android is so fucking full of shit, i wonder why am i still doing it. love is pain.

Why can't there be one mother fucking solution to all lazy ass asynchronous programming? handlers, threadpools, asynctask, executers, Broadcasts, intentService, coroutines, rxjava,.... i don't what new stuff are people snorting these days.

Ok , leave everything. A handler is class- no sorry, Handler, alongside some fucking Looper clss (and maybe some more stuff i don't know) other classes is a way of handling inter thread communication. Handlers can:

-send data to ui thread
-recieve data from ui thread
-send "messages" to ui thread
-recieve "messages" from ui thread.
- can be attached to ui thread
- can be attached to any child thread
- can be accessed anonymosly via any view
- can be present in multiple places, working together
- can kill night king with a dagger
- can do porn better than johnny sins
- can run for president of the whole fucking world
- do some more shits that i have yet to discover

And where do i find this? buried deep insides some medium articles or in some guy's horrible accent video.
Is background processing really this much of a toughnut to crack?
earlier i was all about using asynctask or foreground/background services, because these are the most easy to understand abstraction of a fairly difficult topic.
But as i see more projects, i see underlying apis like handlers, threadpools , executers , being directly used.
Why cant there be a fucking single abstraction, that could be "lightly tweaked" to handle every ugly case.

Comments
  • 2
    Pssst.. underneath, it's just a Linux, and it has pthreads available once you get to the NDK. No bullshit, just pure C will do.
  • 1
    Yup. Handlers are the Way to do things...

    I much prefer an eventbus+background thread, as it decouples evertyhing.
  • 0
    I agree, there is so many options that I am never sure if I'm using the correct one or not.
  • 1
    @cafecortado It all depends on your experience, and the specific needs of the app.
    Standalone (no server), simple - local broadcast reciver
    Standalone, complicated - eventbus, or handlers.
    Low dependency on network, simple -> loaders.
    Low dependency on network, Complicated -> eventbus+background thread.
    High dependency on Network, simple -> loaders
    High depndency on network, Complicated -> multiple threads+eventbus, loadeds, and multiple handlers.
  • 1
    @magicMirror if am not wrong, eventbus is the library by greenrobot, right?

    Am hearing this word a lot. Usually i don't prefer using libraries for my personal projects and rather try to look deeper into the default components provided by the android sdk for such things.

    But eventbus looks like something more like a core component that one should know. Doesn't Android sdk have its any non library alternative?
  • 2
    @TitanLannister yes. they are called intents/localrecivers.
    but for a heavy work load, they are high resource cost.
    And you might consider using more 3rd party libs, they will make your dev work much faster.
Add Comment