Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Great start #3

Open
jjhesk opened this issue Oct 17, 2016 · 1 comment
Open

Great start #3

jjhesk opened this issue Oct 17, 2016 · 1 comment

Comments

@jjhesk
Copy link

jjhesk commented Oct 17, 2016

Looks like you have committed to support this library. Keep up with the good work. Just a quick question. Whats the advantage from comparing to retrofit and otto bus? Are there any practical application you want to show case to use your architecture? That would be a good idea to illustrate some benchmarks in comparison on the similar libraries.

@janishar
Copy link
Owner

janishar commented Oct 17, 2016

If you see otto bus or event bus.

  1. You have to register the subscribers and then you must deregister them. In JPost you too have to add subscribers but even if you forget to remove the subscribers. It will not cause memory leak because the subscribers are held with weak reference.
  2. You cannot control the receivers on any basis in other libraries. For eg. If you had two pages in a view pager. These had a placeholderview or any parent view having child view classes. The child classes may have been instances of same class but doing different operation depending on parent.
    Now the parent only wants to send message to its child or one child only wants to communicate with its parent's children, then these could not be done with other libraries. All the subscribers in those libraries will get events in any case.
  3. If you want to execute any code asynchronously when the subscriber receives message. This could not be done in a straightforward way in other libraries. The thread that post events generally do processing of message, if it's the UI thread then the UI becomes less responsive at times. In JPost you can post messages async and then one of the pool thread will do the processing.
  4. Channel based event transmission/reception is more intuitive and practical.
  5. What you can achieve through this library is much more than a publish-subscribe pattern. You can design the entire framework for networking for example using private channels so that you retain the safe and decoupled code to the highest order.
  6. The functionality provided by other libraries are all handled by the default channel in JPost. All other modules in JPost are addition and expansion that such a library can provide. These requirement becomes more prominent when code grows and hundreds of classes are publishing and subscribing. It really becomes a huge challenge to control what is getting where.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants