[RFC] Android-centric package structure

[omo]

What if we have rx.android.views, rx.android.context... instead of r.a.observables r.a.observables, etc?

Currently we are forced to make some internal classes public just because they are under separate packages. If we have r.a.views for example, ViewObservable and depending operators can fit into the single package. This allows those internal classes to have package-local visibility, without blowing up the number of classes in a single package.

Also, I feel this is more scalable than existing package structure. As we turn various Android APIs into reactive style, each package will become more crowded and less structured. The Android-centric package hierarchy doesn’t have that problem. After all, what RxAndroid care is about Android, not generic Rx abstraction.

We can move some major classes including AndroidObservables to the top level packages (rx.android) for convenience. The class can be a facade to more focused classes. For example, bindActivity() could just wrap (hypothetical) ActivityObservable#bind().

Although I’m not that confident this works well, some variations of package structure is probably worth considering before 1.0 release. I’d like to hear what you think.

[mttkay]

I like it! Maybe worth looking at how the other projects do it as well. I
remember I looked at rxjava-swing (yes that's a thing!) back then any just
followed what they did. That was a while ago though...
On Nov 20, 2014 8:15 PM, "Hajime Morrita" notifications@github.com wrote:

What if we have rx.android.views, rx.android.context... instead of
r.a.observables r.a.observables, etc?

Currently we are forced to make some internal classes public just because
they are under separate packages. If we have r.a.views for example,
ViewObservable and depending operators can fit into the single package.
This allows those internal classes to have package-local visibility,
without blowing up the number of classes in a single package.

Also, I feel this is more scalable than existing package structure. As we
turn various Android APIs into reactive style, each package will become
more crowded and less structured. The Android-centric package hierarchy
doesn’t have that problem. After all, what RxAndroid care is about Android,
not generic Rx abstraction.

We can move some major classes including AndroidObservables to the top
level packages (rx.android) for convenience. The class can be a facade to
more focused classes. For example, bindActivity() could just wrap
(hypothetical) ActivityObservable#bind().

Although I’m not that confident this works well, some variations of
package structure is probably worth considering before 1.0 release. I’d
like to hear what you think.

—
Reply to this email directly or view it on GitHub
#65.

[JakeWharton]

+1 to anything that hides more implementation details :D

Every public class should be an explicit decision. Every non-final class should be an explicit decision. Every public method should be an explicit decision.

[omo]

Thanks for your feedback!

I took quick look at other Rx family members. Besides per-language port, many are pretty young and have only a few classes. There are a few larger ones though:

• RxSwing follows RxJava structure, as @mttkay mentioned. https://github.com/ReactiveX/RxSwing/tree/0.x/src/main/java/rx
• RxNetty has its own structure. I'm not sure how this resembles Netty itself though: https://github.com/ReactiveX/RxNetty/tree/0.x/rxnetty/src/main/java/io/reactivex/netty

I'll experiment this idea and show you folks how it looks. I don't expect such a thing being landed immediately, but probably it's nice to have some concrete ground to discuss.

[mttkay]

Sounds good!
On Nov 20, 2014 9:00 PM, "Hajime Morrita" notifications@github.com wrote:

Thanks for your feedback!

I took quick look at other Rx family members. Besides per-language port,
many are pretty young and have only a few classes. There are a few larger
ones though:

• RxSwing follows RxJava structure, as @mttkay
  https://github.com/mttkay mentioned.
  https://github.com/ReactiveX/RxSwing/tree/0.x/src/main/java/rx
• RxNetty has its own structure. I'm not sure how this resembles Netty
  itself though:
  https://github.com/ReactiveX/RxNetty/tree/0.x/rxnetty/src/main/java/io/reactivex/netty

I'll experiment this idea and show you folks how it looks. I don't expect
such a thing being landed immediately, but probably it's nice to have some
concrete ground to discuss.

—
Reply to this email directly or view it on GitHub
#65 (comment).