Any experienced developer will tell you that their best code isn’t code they wrote. It’s code they took from someone else’s work.

Yes, we developers are innovative problem-solvers, but many of the problems we encounter have already been solved—and the remedies packaged into libraries available to anyone. Why reinvent the wheel when free wheels are everywhere?

Android is no exception. The ultimate source for code reuse is the Android SDK itself, which comes with great constructs and services that will do a lot of your work for you.

But where the SDK runs short, the Android community has created some top-of-the-line libraries that can save you tons of coding work, replacing it with highly tuned, vetted, and tested implementations. I’m not talking about the obvious libraries—Android Support Library, Android Design Support Library, Gson. I’m referring to tools you may not know about. And even if you do, you’re probably not using them yet.

One of the major differences between a standard and master developer is the correct use of third-party libraries. A master developer will roughly accomplish the same task three times faster than a novice, and usually with shorter code. A good deal of this comes from knowing which third-party libraries to use and how to correctly embed them within your project.

I’ve been developing, mentoring, and leading Android teams for years, and I’ve studied and used dozens of external tools and libraries. (I’ve even been known to read their implementation code and discuss their internals with the developer.) Many have been highly effective in helping me get the job done, but the truth is, most were not.

That’s why I’ve put this guide together. Lean on my experience, as well as that of other mobile developers, to make sure you’re using the best libraries. I’ve picked seven. I suspect they’ll be some of your favorites very soon too.

Selecting the Right Android Library

When choosing a library, I look for four key features:

  • It provides a consistent and high-quality solution for a real and non-trivial problem.
  • It uses as simple an API as possible.
  • It does not force any changes in my overall architecture.
  • It has a large user base and, preferably, an active developer community.

The first three features are deal-breakers. If they’re not present, I move on or start hand-coding.

Android Libraries

The libraries I cover below pass all four tests. They also solve some of the most challenging aspects of mobile development.

ButterKnife: The Ultimate Dependency Injection Tool

This is the ultimate dependency injection library for Android. Simple, robust, super fast (no reflection!), and capable of doing away with a lot of your app’s boilerplate code.

Some would argue that ButterKnife is what Android’s layout to Java mapping should have been in the first place.

Android Butterknife dependancy injection

Gone is the need to directly bind each of your views via a call to findViewById(); instead, there’s an annotated view that gives you direct access to code.ButterKnife also eliminates the need for boilerplate UI events such as onClick, onTouch, and so on, and replaces them with auto-injected code.

But enough chitchat, let’s see the code.

View field binding:

class MyButterKnifeActivity extends Activity {
  @BindView( TextView name;
 @BindView( TextView address;

  @Override public void onCreate(Bundle savedInstanceState) {
    ButterKnife.bind(this);   // MUST BE CALLED BEFORE ACCESSING UI FIELDS
    name.setText(“etc etc”);

Resource binding:

class ExampleActivity extends Activity {
  @BindString(R.string.username) String username;
  @BindDrawable(R.drawable.graphic) Drawable graphic;
  @BindColor(R.color.bg_color) int bgColor;
  @BindDimen(R.dimen.lower_padding) Float lowerPadding;
  // and no need for getResources().getString()/getDrawable/getColor()

UI event binding:

public void clickHandler(View view) {
  // onClick logic goes here

AndroidAnnotations: Taking Dependency Injection to the Next Level

A close second to ButterKnife when it comes to dependency injection, AndroidAnnotations uses a slightly different approach: auto-generated classes, which, once you get the hang of them, are extremely simple. Even more useful is that it allows you “name-based” dependency injection. For example, @ViewById ListView myUserList; instructs the library to assign this field with a layoutListView by the same name.

AndroidAnnotations is also blazing fast, but it achieves that in a somewhat different manner than ButterKnife. Instead of runtime binding dependency injection, AndroidAnnotations creates a build time duplication of all affected activities and pushes its connection logic into them, thus allowing you to get the same performance you would with hand-coded logic.

But AndroidAnnotations’ injection capabilities go even further than that. You can inject both state and layout into an activity.

AndroidAnnotations implementation:

public class MyActivity extends Activity { 

     ListView customerList;  // auto-binded to

     MyApplication app; // auto-binded to app object
      Animation fadeoutAnimation; 

     void updateUI() {
          // main thread action


The last annotation requires a bit more explaining: A common task for a multi-threaded Android app is switching from background (or worker) threads to the forward (or main or UI) thread, which is the only one that allows access to UI components. This task, while not complex, is often required and involves some messy coding:

      new Handler(Looper.getMainLooper()).post(new Runnable() { logic goes here } );   // NO ANNOTATIONS

In AndroidAnnotations, all you need to do is annotate your function with @UiThread, and it’s now guaranteed to always execute:

          @UiThread void updateUI() {..}   // WITH ANNOTATIONS

Note that this annotation applies to standard Android component classes (activities, services, and so on). But what happens when I also want to annotate my own classes?

Here, AndroidAnnotations comes up with a new concept, that of the EBean. All you have to do is to mark your class as such using @EBean, and you’re good to go:

public class MyNonComponentClass {

  NotificationManager notifManager;

  MyOtherClass dependency;

  void updateUI() {
        // main thread work goes here

EventBus: Cross-Component Communication Made Easy

EventBus library turns a problem that’s haunted Android developers for years into a walk in the park. Cross-component communication has never been simpler—use a simple pub/sub model to communicate between any two parts of your system.

EventBus animation

Using the event bus will result in more robust code, as it forces you to decouple your components from one another.

Your background polling service no longer needs to be aware of your fragments to feed them with change events.

EventBus usage is straightforward.

a. Create event classes. Working with POJOs here is best:

           class NewUserEvent {
                  String fullname;
                  String address;
                  String role;
                 // add getters and setters 

b. Create event handling methods in the class—any class that you wish to subscribe for these events:

         class MySubscriber { 

            public void newUserHandler(NewUserEvent event) {
                       // handle NewUserEvent

            public void newUserHandler(AnotherEvent event) {
                       // handle AnotherEvent

But hey, any half-experienced Android developer would stop and ask at this point: What’s the threading model of these handlers? And can I force a handler to run off the main thread if, say, it involves UI component access? Good question…

By default, all handler methods run on a worker thread taken from a thread pool that’s allocated and maintained by EventBus itself. If you need a handler method to run on the main thread, expand your subscription annotations as follows:

                  @Subscribe(threadMode = ThreadMode.MAIN)
                  public void runOnMainThreadHandler(AnotherEvent event) { … }

Warning: Do not overuse this feature! Long-running operations should never be executed on the main thread, and even with quick operations, be careful. Overwhelming the main thread is the surest way to make your app slow, jumpy and basically less fun to your users.

c. Manage the EventBus registration lifecycle of your subscriber class—that is, when does it connect and when does it disconnect from the bus? A reasonable registration flow for an activity would be:

class MySubscriberActivity extends Activity { 

     public void onStart() {
         EventBus.getDefault().register(this); // START RECEIVING EVENTS HERE
    public void onStop() {
        EventBus.getDefault().unregister(this); // NO MORE EVENTS

The above is, of course, just an example. You can perform the (un)registration anywhere you choose.

d. And finally, actually fire an event:

        EventBus.getDefault().post(new MyEvent(“I’m here”));

There’s a lot more to know about using EventBus: multicasting events (the default behavior), using sticky events, delivery threads, priorities, and more. But the above is enough for you to get started with this simple, yet powerful, technology.

OkHttp: Android's HttpClient on Steroids

This is the way Android’s HttpClient should have been written. Very simple, very smart. The OkHttp library internally takes care of the retry loop, payload auto compression, Http/2 support, connection pooling, and response caching so you can avoid unnecessary network access.

OkHttp library animation

OkHttp usage is a no-brainer.

Http POST:

     OkHttpClient client = new OkHttpClient();
     MediaType JSON = MediaType.parse("application/json; charset=utf-8");

     RequestBody body = RequestBody.create(JSON, json_str);
     Request request = new Request.Builder()
    Response response = client.newCall(request).execute();
    return response.body().string();

Http GET:

      OkHttpClient client = new OkHttpClient();
      Request request = new Request.Builder()
      Response responses = client.newCall(request).execute();
      String jsonData = responses.body().string();

OkHttp also supports such useful features as asynchronous networking, request redirect route query, local cache query, and more. Feel free to use them where needed. Most developers use OkHttp as a smarter replacement for Android’s default HTTP client, HttpURLConnection. In fact, this entire project started as a private fork for HttpURLConnection.

I love its robustness—it immediately adds to your network layer.

With just a few lines of code, OkHttp makes your app behave like you spent nights debugging and optimizing your network layer.

Picasso: There's a Good Reason Google Uses It Too!

Picasso is the simplest and most robust way of managing image download, caching, resizing, and cropping.

This statement:


Will do this for you:

  • Connect to a remote URL.
  • Download an image.
  • Store it in a local LRU cache which it will also manage for you.
  • Resize the original image before loading it into memory.
  • Run all of the above on a thread pool managed by Picasso.
  • Use the resized image to populate your imageView.
  • Before any future runs, check the local cache to ensure a network round trip is really necessary.

Building the above set of tasks would require many hours of work, even for a master developer. And that assumes you remembered everything. What if you forgot, say, the resize part?

Picasso Android library animation

Well, on the average Android device, an app gets no more than 50 to 60 Megabytes of RAM, and the pixels-to-bytes factor for most Android devices is 4. This means attempting to load a 13-megapixel image from the SD card would require 52 Megabytes of RAM. In other words, your app would immediately crash.

This is just one example of the strength of Picasso. One of the first things I do when optimizing/debugging a media-intensive legacy project is switch all image loading to Picasso. You’d be surprised the impact this one simple step has on app quality.

One of the strongest testaments to the power of this library: Many of Google’s own Android code samples from the past two years employ Picasso for image loading.

ActiveAndroid: ORM Sans Performance Overhead

ORM, short for object relational mapping, was made popular in the days of J2EE. It allows you to store your POJOs in, and retrieve them from, a database without having to convert them into separate fields.

ActiveAndroid ORM

Is it helpful? Very much so, as it allows you to write a large portion of your app without coding any SQL statement.

It’s also very efficient. In the old days, ORM platforms massively relied on reflection and were notorious for being slow. Modern platforms, including ActiveAndroid, are much faster and for most practical requirements, will not suffer from performance overheads over raw SQL coding.

No hand-coded SQL statements, no performance overhead!


a. Initialize in application object by extending a custom Application class:

   public class MyApplication extends extends  {

b. Create POJO, derived for a model class, with classes for each of the records you plan to store in the database. Each such POJO can reside in its own table. Annotations should be used to specify the DB fields’ name for each stored member:

     @Table(name = "Categories")
     public class UserDetails extends Model { 
          @Column(name = "Name")
          public String name;
          @Column(name = "Address")
          public String address;
          @Column(name = "Age")
          public int age;

If you wish to set an index for a member, use the following annotation:

          @Column(name = "ID", index = true)
           public String userID;

c. To prevent the library from iterating over all of your classiest startup time, which is the default behaviour, it is highly recommended you specify all of your model classes in the following manifest section:

        android:value=“com.myapp.MyModelA, com.myapp.MyModelB" />

Note: Model classes not appearing in this list will not be recognised by ActiveAndroid.

d. Write to database:

      UserDetails usr = new UserDetails();;  // RUNS ON A BACKGROUND THREAD

If multiple writes are needed, a more efficient way would be to batch them in a single transaction:

    try {
        for (UserDetails u: userList) 
   finally {

e. Read POJOs from database:

   new Select()
         .where("name = ?", usr.getName())

ORM was a must-have tool during my days as a server-side developer. It had a somewhat late entry into the Android domain. But, at last, here it is: database programming as simple as it gets. Enjoy it.

LibStreaming: Painless Video Streaming

Real-time video streaming used to be a major pain because of non-documented APIs, cross-SDK version differences, reflection usage, and more.

libStreaming library animation

Luckily, libStreaming changed all this by encapsulating most of the streaming complexities and exposing a simple and friendly API that allows you to write a basic streaming app in a matter of hours.

In a nutshell, it streamlines video streaming.

To use it for H.264 and AAC, you need to do the following:

a. Initialize a session object at your main activity’s onCreate method. Session objects represent media streaming to a peer:

 protected void onCreate(Bundle savedInstanceState) {
        mSession = SessionBuilder.getInstance()
           .setAudioQuality(new AudioQuality(16000, 32000))
           .setVideoQuality(new VideoQuality(320,240,20,500000))

b. Actually start the session:


c. Halt the session when done:


Now, please do not misunderstand. Real-time streaming is messy by nature and libStreaming does not take away this complexity. However, it does a really good job hiding it from you most of the time. In some cases, you will need to deal with the complexity, such as when selecting peer signalling policy, choosing camera encoding (you’d typically want to use MediaCodec/surface-to-buffer), or dealing with packetization.

Still, you will find that the good guys behind libStreaming went the extra mile in merging these complexities smoothly into a simple-to-use API.

LibStreaming supports most encoders used by Android apps, including H.264, H.263, AAC, and AMR.

I’ve reaped great results with this library. Several of the most popular streaming apps use it as a part of its infrastructure. If you ever encounter the need, I’m certain it’ll make your media streaming experience far smoother.

LeakCanary: Detect Memory Leaks in a Line of Code

Let’s start with the motivation behind this library: memory leaks. Android apps are prone to them, especially if you’re not careful with your coding. In fact, creating memory leaks is very simple. All you need to do is to store an activity reference outside of its context. In fact, even storing a reference to a single view object outside of its activity’s context will create a leak.

Why? Because a view—all views, in fact—internally store a context reference to its containing activity. As long as a reference to the view is kept, its containing activity—along with what’s inside it, including drawables, view hierarchy, and resources—cannot be reclaimed by the garbage collector.

Keeping a reference to a leaking activity is not always obvious as a static parameter. Whenever you create an inner class or spawn a thread inside an activity, a reference to that activity will be created and the activity may not be reclaimed until that inner class or thread are completed.

Leaks are of course not unique to Android, but being a mobile system with limited memory resources, the impact is more immediate.

Leaking a reference to a single resource-intensive activity is sometimes enough to crash your app with an “Out of memory” exception.

LeakCanary library

How can you protect against them? Start with rigorous coding practices, of course. But not all of us are experienced Android developers, and even the experienced devs sometimes forget the rules.

Periodical code reviews with an emphasis on memory leaks may be helpful, but they take time. Also, some leaks are real sneaky and hard to detect by mere code review.

Using the DDMS’ memory tool is a great way of knowing, over time, if your app is leaking. You should definitely use it. However, it will not tell you what’s causing the leak.

Here comes leakCanary to the rescue. It’s the best memory leak detector out there, and it provides automatic — as in one or two lines of code — leak detection for all your activities.

To use it simply initialize leakCanary with your app’s object onCreate():

     public class MyApp extends Application {

          @Override public void onCreate() {
                 // more initialisations

And you’re done. LeakCanary will monitor for memory leaks, and send a notification if it detects one.

LeakCanary achieves this magic by auto-injecting an object called ActivityRefWatcher into all of your activities and monitoring their ref count after onDestroy() has been called. A > 0 ref count on a destroyed activity can only mean a leak.

Important: Leak detection only works for debug mode applications. Never test for leaks (well, not with LeakCanary) in a release mode APK.

But what if I want to test other parts of my system for leaks? Here, LeakCanary offers an object called refWatcher, which is in fact the return value of the initialization call:

            refWatcher  = LeakCanary.install(this);

It can be used to watch values that are soon to be reclaimed. More precisely, values that I think are soon to be reclaimed. To do that, call:

The library will let you know if this object has not been released a short time after the watch call.

I could not find the value of this “short time” anywhere, but it’s probably not that important. With leakCanary, things just work. Priceless.


Experienced developers cut days and weeks off their coding and debugging phases using these libraries, so there is no reason you can’t do the same.

To sum up, here’s what my selection of Android libraries can do for you:

  • ButterKnife – Auto-injected code will help you do away with much of your app’s boilerplate code. It’s the ultimate code injection for Android. Need I say more?

  • AndroidAnnotations – Use blazing fast auto-generated classes and name-based code injection to save time with no performance penalty over hand-coded logic.

  • EventBus – Decouple components for more robust code, cross-component communication has never been simpler.

  • OkHttp – A clever replacement for HttpURLConnection, with support for asynchronous networking, request redirect route query, local cache query, and more.

  • Picasso – Streamlined image manipulation that’s so good it’s now used by Google. It’ a major time-saver in media heavy projects and certain legacy projects.

  • ActiveAndroid – ORM made easy with no performance overhead.

  • LibStreaming – Real-time video streaming, used by major streaming apps.

Are these the only Android libraries worth your time? Certainly not. But I promise you this: Using any of them on your next project will make you a much better developer. If you want to see them in action, take a look at my GitHub.

If you are already using some or all of them, or if you are using alternative libraries, I urge you to share your experiences in the comments below.

About the author

Gilad Haimov, Israel
member since March 11, 2015
Gilad is an expert blockchain/cloud developer who has served as technology adviser to leading Israeli mobile technology companies. He brings over 18 years of experience in developing complex and innovative Ethereum/Solidity, server-side, and communication systems. [click to continue...]
Hiring? Meet the Top 10 Freelance Android Developers for Hire in May 2019


Adam J. Mendoza
Is there an Android library to trigger events with Geofencing when the app is in the background?
I'd like to add that if you are using RxJava, adding an event bus library may not be the best idea. By leveraging its pubsub nature, a bus-like system can be added with virtually no effort and without adding another library.
André Miranda
Nice article, anyone wishing to find more useful libraries, google: awesome-android Awesome-* lists on general are great for popular languages and platforms.
Asad Waheed
I would like to share some libs that i use which serves as alternative to some of them. For okhttp i use httprequest. For picasso i use glide bcoz its more memory efficient.
Maher Nabeel
So far I've worked with OkHttp and Picasso. Things are really pretty and neat. When it comes to networking I can't see another simpler, more efficient way than OkHttp. Picasso library has solved a performance problem in one of my apps with single line. One limitation I think of Picasso is that it doesn't support of loading a Drawble OBJECT into ImageView (or I may not know the way yet). I haven't used ButterKnife yet, although I read about it couple of time, and looking forward to using it in my next app.
Son Nguyen Kim
Very useful article!
Gilad Haimov
Yep, that matches my own (and many other's) experience. Regarding drawable load by Picasso, I assume you mean non-resource images e.g. a picture from sdcard To do that just convert the pict path into a url: Uri uri = Uri.fromFile(new File(imgFilePath)) and then load the picture using Picasso's standard loading procedure: Picasso.with(activity).load(uri).resize(DX, DY)...
Gilad Haimov
Go to github and filter projects by Android & Geofencing. You will find several library projects. Never tried any of them though
Gilad Haimov
RxJava and event bus are, of course, different in nature - Event bus is a simple vehicle for component-to-component communication - RxJava more or less forces you to redesign your entire architecture around a data-centric model.
Nice article, and the idea of using libraries itself too. I personally prefer Glide over Picasso as well, but I guess both are ok. However, the biggest timesaver for me was replacing Java itself with Kotlin :). It makes the code so much easier to read and write, and the lazy loading kind of replaces the complicated dependency injection too. Definitely worth a try!
A very powerful framework named Declex contains most of these libraries, and includes features to make applications really fast, reducing the amount of code needed to write an application up to 90%... I recommend you all have a look at it (
Pankaj Arora
Great Article, however i feel some of these libraries have the best alternative like picasso can be replaced by glide (As it is more efficient than picasso in terms of memory & performance & size too), also you missed some important libraies like dagger2, retrofit etc..hope to have that in your next articles.
Nevin Sunny
"Be Lazy, but a productive developer " using these libs, as libraries saves a lot of time & efforts by simply exposing some methods, we call them & got best results. Sir, many thanks for sharing this, as i am a beginner in android & this article help me to understand so many things that i can use in my current project.
Amit Kumar
Very meaningful & helping article for developers to save time and learn new things. the way you described these libraries is really very clean! Well, can you please write about dagger2 & retrofit, nowadays, these two are on very high demand.
Gilad Haimov
I've tried Glide few times but still would recommend Picasso. I have seen no humanly-visible difference in load time compared to Picasso, even when tested with _very_large images. With regard to memory footprint differences - just look at the memory usage panel in the DDMS. Here too you'll see no visible difference between the two, So why Picasso? Because way more developers use it. Smart image loading is an error prone task, and I want the tools that I'm using to have as much trenches time as possible.
Gilad Haimov
Thanks Amit. I had very good experience with Retrofit in a several projects. I might write on it in one of my future articles.
Oved Yavine
Nicely written article Gilad, I personally used Picasso, EventBus and ButterKnife and love them... Thanks for the summary. as for a network client, i personally like to use Retrofit which does a very nice job. But I will give OKHttp a try :)
Retrofit and OkHttp is like apples and oranges. If you are getting a json as the response and want to parse it, definitely go with retrofit. OkHttp is for other network requests, if you are not downloading an image or json.
Oved Yavine
@tibbbi:disqus not sure the difference is clear to me. you did not explain what "other network requests" OKHttpHttp is good for and why
Im using OKHTTP at those requests, where Im not awaiting any response, or I want to append some POST parameters, tweak the timeout, tweak cache etc.
Gilad Haimov
My 2 cents: OKHTTP is a superior replacement for Android's own http client i.e. for ANY type of http requests, with or without an answer. Retrofit is an higher level network abstraction whose main strength is auto conversion of (annotated) POJOs into http requests. The two can and do coexists without any problem.
Great article and all (despite its misleading title), but those libraries are NOT for "dependency injection". Dagger2 is a dependency injection library, and it is not mentioned here.
Urja Pawar
very well written, nicely explained! it would be great if you add some more code chunks into it.
Kaustubh Bhagwat
Very nice article, however i feel there are so many other libs too, that developers must know about. it would be great if you write something interesting about the libs that we can use in UI/UX part.
Vipul kumar
Very nice article, however i feel there are so many other libs too, that developers must know about. it would be great if you write something interesting about the libs that we can use in UI/UX part.
Gilad Haimov
Retrofit does support authentication token. See explanation here:
Gilad Haimov
Thanks. Code samples for this article may be found in
Likhit Singhal
The way you explained these libs with images is amazing, well these all are coding related libs, nowadays, developer are getting challenging UI/UX, if possible write something about UI/UX libs too.
Ashish Tomer
Very Interesting article and quite valuable. thanks for sharing.
Neha Tyagi
Awesome tutorial...helped me explore libraries that I didn't knew about. I am looking forward to implement these in my projects for better coding experience.
Shachar Silbert
Great article, I'm always afraid of the overheads, though, that these kinds of libs (mainly not Picaso) have on my system. But I guess soon enough it wont even matter, with extended GPU capabilities and octal-core mobile devices. Thanks for the great insight!
Great piece ! This is some serious top quality stuff. I think LeakCanary deserves much more recognition in the Android community. I didn't know about this EventBus library, it surely looks very interesting.
Guy Doron
Great Article Gilad.
Manmohan Badaya
Incredible article. It answered some questions I've had burning in my mind and given me much to think about
Gilad Haimov
My own reservation if more about reaching the multi-dex limit (64k function, if memory serves me right) after which builds becomes slower. Most-to-all of the libraries mentioned in this article are tight in the sense that their function count is will contained. You can probably use most of the *together* in a single (small) project without having to go multidex. This is a big thing for many.
Zoha naz
Your article was very well explained, it would be great if you also talk about its alternatives like Picasso and retrofit in your next article. Developers looking for efficient libraries can take a leaf out of this article.
Harsh Chaudhary
Picasso is awesome, however Glide is more then awesome. it will be good if you explain about glide too, as so many developers are using glide in their projects.
Alok Sharma
Can you please write about multipart upload (Video/Audio/image) using retrofit. in retrofit 2.0 i am facing so many issues in multipart
Gilad Haimov
Retrofit 2.0/Multipart can get a big tricky. Try reading this: especially the MultipartBody.Part explanation.
All I can say is, this is a must read for all developers, as all these improve performance of apps
Dev Carlsberg
Nice approach of explaining things with gif images.So many people asking about dagger2 here, for them I must say dagger2 can reduce boiler plate code, however it will reduce app performance.
Gilad Haimov
It really depends on your needs. Glide is a great piece of software but it is 4 times larger than Picasso, some 5 times larger in terms of method count (which brings you way closer to the dreaded multi-dex limit) and has a ridiculously small cache size - which is a minus is many cases. Putting aside hype and social proof, Picasso is still an awesome tool to use. Many of us do it on a daily basis.
Mateus Gondim
Great article, congrats! I just would like to say that the the default EventBus threading behavior is to call the subscriber method on the same thread where the event was posted, and not on a worker thread, as stated in the article. Reference:
Gilad Haimov
Thanks, Mateus. As the article you have shared clearly states : "EventBus uses a thread pool to efficiently reuse threads from completed asynchronous event handler notifications." This only holds for ASYNC mode, which is the only EventBus I use (and recommend others to use).
Mateus Gondim
Your article says "By default, all handler methods run on a worker thread taken from a thread pool that’s allocated and maintained by EventBus itself." I'd suggest making explicit that you are talking about ASYNC mode, because without that information a reader can only conclude that you are talking about EventBus default behavior, when in fact you are talking about the default behavior of a non-default mode(default mode is POSTING). I noticed that because I was using your article as a guide to try out EventBus, and was surprised to get an exception due to my subscriber method running on the main thread by default(as that was the posting thread).
Mrunal Khatri
There are going to be many libraries for all platforms of programming. As android is no different and there will be lots of libraries for the it for sure.
comments powered by Disqus
Free email updates
Get the latest content first.
No spam. Just great articles & insights.
Free email updates
Get the latest content first.
Thank you for subscribing!
Check your inbox to confirm subscription. You'll start receiving posts after you confirm.
Trending articles
Relevant Technologies
About the author
Gilad Haimov
Java Developer
Gilad is an expert blockchain/cloud developer who has served as technology adviser to leading Israeli mobile technology companies. He brings over 18 years of experience in developing complex and innovative Ethereum/Solidity, server-side, and communication systems.