EventBus: What are some of the differences between streaming modes?

According to the EventBus doc, there are 4 types of streams that it EventBus

uses to deliver streams:

  • onEvent()

    • PostThread
    • Good for simple tasks
  • onEventMainThread()

    • MainThread
    • aka User interface
    • Good for changing the user interface.
  • onEventBackgroundThread()

    • BackgroundTread
    • Using a single thread to deliver events sequentially.
    • Good for a moderate amount of execution.
  • onEventAsync()

    • Asynchronous
    • Using separate streams.
    • Good for longer run times

Question

  • What are some criteria that I should consider before using onEventBackgroundThread()

    over onEventAsync()

    or vice versa? What would be examples of using one over the other with obvious benefits?

  • Which stream modes should each of the following functions use?

    • Getting device status - GPS device location (i.e. android.location

      ), Internet connection status (i.e. ConnectivityManager

      , NetworkInfo

      ).

    • Making simple HTTP requests to get text (like JSON) taking 1000ms to 5000ms, with an average of 2000ms.

    • Making simple HTTP requests to download images with file sizes ranging from 50kb to 1500kb (exact sizes are unknown to the client before making requests to the server).

    • Caching data in an internal database (e.g. SharedPreferences

      , SQLite

      etc).

+3


source to share


1 answer


What are some criteria I should consider before using onEventBackgroundThread () over onEventAsync () or vice versa? What would be examples of using one over the other with obvious benefits?

Well, that's pretty much like sketching bullets. If you don't mind queuing, processing once per second (or perhaps want it for easier thread protection) use onEventBackgroundThread()

. If you need to execute several of them in parallel, especially if they involve I / O binding, you should use onEventAsync()

.

Which stream modes should each of the following functions use?

GPS location of the device (e.g. android.location)

None of the above. LocationManager

and the smooth-location APIs have their own asynchronous parameters; I would use them. Once you get the location passed to you, you can post an event with the location data, but then the streaming is dictated by the subscribers to that event, not the poster.

Internet connection status (i.e. ConnectivityManager, NetworkInfo)

None of the above, since AFAIK is getNetworkInfo()

not an expensive call.



Making simple HTTP requests to get text (like JSON) taking 1000ms to 5000ms, with an average of 2000ms.

None of the above. I would use Retrofit or another HTTP client library that offers asynchronous options. If for some reason you absolutely need to do HTTP I / O yourself, that will depend on how often it happens. If, for example, you can fall behind because you are quickly dropping a few of them, use onEventAsync()

so they can run in parallel.

Making simple HTTP requests to upload images with file sizes ranging from 50kb to 1500k (exact sizes are unknown to the client before sending requests to the server).

None of the above. Use Picasso, Universal Image Loader or any other library to load images as they all have asynchronous parameters and you still need these algorithms for image processing. If for some reason you absolutely need to do HTTP I / O yourself, it will follow the same rules I described for the previous item.

Caching data to an internal database (e.g. SharedPreferences, SQLite, etc.).

Assuming you're not using any wrapper library here that might suggest an asynchronous operation, it might be possible to handle it with onEventBackgroundThread()

. It will also give you the advantage of ensuring consistent performance.

+4


source







All Articles