erickok
commented
9 years ago I strongly agree with the separation into modules, as developers can pick themselves which parts to use. The only counter-argument can can think of is that most developers would use most modules anyway, in which case the split might not be as useful, but it wouldn't do much harm (code duplication) either.
I foresee a (4th?) separate module for compat-ui, which contains bindings like the ui module, yet for AppCompat classes. This would actually be another argument FOR the separation of code, as its dependency on appcompat could be restricted to actual users of it. (The same goes perhaps for the Android Design Support Library.)
I have been following the NotRxAndroid project and like the stronger consistency of the API and implementation. For future contributions I would hope to have an even stronger guideline. I have wanted to contribute but as every implementation seems to differ it is hard to fall in line with the correct style. For example, some view bindings allow broadcasting of the initial value and some not. Some allow multiple bindings (via an internal list of listeners) and some not. Would a binding emit the raw events or perhaps the objects that are affected?
mttkay
loganj
zsiegel
dlew
ronshapiro
Takhion
frapontillo
cantrowitz
JakeWharton
austynmahoney
xorgate
In an effort to stave off becoming either obsolete or a dumping ground (or both), a few of us have been talking through other channels about how best to approach the future of this library.
Everyone agrees that the current project is a dumping ground of utilities, operators, and helpers that were once useful to one or more people when working with RxJava on Android. These were contributed by a wide variety of people with little thought to what this library's identity would be—they just wanted to share useful code.
Android is an entire platform with vast APIs. Adapting or shimming all of its APIs with RxJava will result in a large, slow moving monolithic library. It would be very hard to dictate policy on naming, reference holding, and behavior across such a large adaptation. And finally, the ways with which developers interact with this large API surface area differs based on use-case, history, and opinion.
It is infeasible to build a single RxAndroid library.
This should come as no surprise as the repo currently doesn't even house a single RxAndroid library. The ill-defined 'framework' module splits functionality in an pre-emptive realization of all the points from above.
I am proposing a from-scratch, modularization of the library into re-usable and composeable modules. A few other notable contributors are in support of this and I'll let them voice their support, suggestions, and/or issues individually.
The APIs in RxAndroid which are fundamental to all RxJava use on the platform deals with threading. Android's hallowed main thread and the related handler-scheduler adapter are fundamental to all RxJava use in a non-trivial capacity. These will be part of the 'core' module.
The newly added plugin hooks are also something foundational with which other modules would leverage functionality. They will also be present in the 'core' module.
Finally, internal static helpers which will be used in all modules (such as the current preconditions/assertions classes) will be in the 'core' to reduce needless duplication.
The second subject on which I want to dedicate a module is binding to and from the UI controls which make up the
android.view.*andandroid.widget.*packages. This 'ui' module will feature observable factories for listening to UI changes and action factories for subscribing UI properties.The scope of this second module is too large for this issue as there are a lot of considerations to be made around naming, threading, reference keeping, etc. so I will create another issue for that once consensus is reached.
I'll try to preempt answers to some questions below:
This seems drastic. Is this really needed?
It has become very clear to the few of us that have been having conversations that this project is dying. If we do not undertake an effort to make drastic changes such that applications and libraries can confidently depend on it in a way that's useful to everyone then it will simply stagnate into uselessness.
The current offering covers Android APIs randomly, has varying implementations of correctness and efficient, and without a strong idea of an identity no one know what should go in.
Will this be done in an API-compatible way?
No. This will be invasive and destructive. Things will be moving.
What about deprecations?
No. There is no point. We can release
masteras a v0.25 which can be considered an instant deprecation of every API.Why from scratch?
This will allow front-loading discussions about naming conventions, implementation patterns, and nuances of things like references. It's much easier to evolve an approach used by all APIs than try to unify 10 different approaches. This does not mean that the existing code will be ignored. It might even be copied verbatim in places, just that it will be all new modules with consistency.
What about activity/fragment lifecycle binding?
That'll potentially be a third module. I personally don't use these so while they are not included in this issue, they will likely be scoped to the same effort.
What about (insert API not mentioned)?
Plan for it to disappear. Copy/paste its implementation into your source tree for continued use after modularization happens. There are plenty of APIs from this library that are used which are useful but have questionable applicability to the masses. If it's specialized enough, consider making a separate library on your personal or corporate GitHub account and depend on one of the modules we will be creating. The point of having small, composeable modules is for a la carte re-use across many libraries.
When will this happen?
If no compelling, well-reasoned, and majorly agreed-upon counter-argument to this approach is to be had we would like to start figuring out the 'core' module in one week. The final current-form release of the library as-is will happen in approximately the same timeline. Once the 'core' module is mostly agreed upon, implementation will start and discussion around the 'ui' module will begin (and will likely be a longer process to flesh out).
How can I help?
Get on board with the effort. Constructive comments, criticisms, and suggestions are welcome. Don't "+1" this issue (we'll see how many read this far). The easiest way to think about this effort is as a new, opinionated, well-designed library driven by a few people who really want it to succeed both in terms of usability to developers but also in being clear in what's appropriate and what's not appropriate for inclusion.