Make ReactiveNetwork class singleton? about reactivenetwork

[pwittchen]

Creating additional static methods for creating Observables could be a good idea. It's definitely better than making the whole class a Singleton.

[pwittchen]

Hi,

First of all, thank you for asking the question.
I think, in this case, we should avoid Singleton. It's not only my opinion. Here's the quote, which explains this well:

What is so bad about Singleton?

Paraphrased from Brian Button:

1. They are generally used as a global instance, why is that so bad? Because you hide the dependencies of your application in your code, instead of exposing them through the interfaces. Making something global to avoid passing it around is a code smell.
2. They violate the single responsibility principle: by virtue of the fact that they control their own creation and lifecycle.
3. They inherently cause code to be tightly coupled. This makes faking them out under test rather difficult in many cases.
4. They carry state around for the lifetime of the application. Another hit to testing since you can end up with a situation where tests need to be ordered which is a big no no for unit tests. Why? Because each unit test should be independent from the other.

Source: http://stackoverflow.com/a/138012/1150795

I wouldn't avoid Singletons at all. There may be cases when they're useful, but I think, we shouldn't use them too much and try to avoid this pattern when possible.

In the case of an Android application, you have only one instance of Application class, which can be Singleton, so you can create a new object of ReactiveNetwork or anything else there to be sure that there's only one instance of this class. It may be useful when you are using instance this class in a different Activities and you don't want to create too many objects. It's better idea and more flexible solution than forcing library class to be a Singleton. If we have too many Singletons, the application will consume a lot of memory and we want to avoid that. Especially when an app is running on a mobile device, which has limited resources and battery life. Moreover, we are reducing app testability.

[jaychang0917]

I get your points. But for me, I prefer to use static factory method like create() or newInstance() according Effective Java - Item 1: Consider static factory methods instead of constructors. Just my two cents.

[pwittchen]

Yeah. In some cases, it may be good option, but I'd rather leave classical constructor without any singleton here. If you want or need to have a static factory method, you can optionally create additional wrapper class (facade) and create a static factory method for this library there.

[epicstar]

Why not make the ReactiveNetwork methods static like the normal rxjava.Observable classes?

[epicstar]

Shall I make an issue to do this? I think this should be a high priority since it would add some nice syntax parity to the rxjava project. That would also imply that you should add the @Deprecated tag to the public ReactiveNetwork constructors to tell users to use the static methods to instantiate an ReactiveNetwork object

[pwittchen]

Static methods are added in the similar manner like in RxJava library. They'll be available in the next release.