13

I have and Android app with the view class (Fragment, Activity) observing its ViewModel.

The ViewModel exposes methods such as getUserName which returns Observable<String>. Although maybe there is a possibility to find a better name (maybe observeUserName), I'm happy with the current one - it is quite explanatory.

However, here starts the hard part: ViewModel also can tell the view to perform some operation - for example close itself, pop backstack etc. For this case ViewModel defines following method (and corresponging Subject):

class ViewModel {
   // other methods, fields

   // ViewModel can call returnToPreviousScreen.onComplete()
   CompletableSubject returnToPreviousScreen = CompletableSubject.create();

   Completable returnToPreviousScreen() { return returnToPreviousScreen; }
}

In my opinion, the method's name is terrible. Hovewer I can not find anything better. Something like observeWhenToReturnToPreviousScreen is maybe more explanatory but hard to read.

So, are there any recommendations or maybe commonly used practices for naming such methods?

Piotr Aleksander Chmielowski
  • 5,640
  • 7
  • 29
  • 45

1 Answers1

11

There's no universal answer to the naming problem, so the only thing you can get are opinions.

Rule of thumb

My approach to naming in rx-java usually looks at two things:

  1. Does it express a "stream" of emitted events (usually with a plural form of a noun)?
  2. Does it work well with other parts of rx java methods chain, and especially the subscribe method?

Both of the above can be usually simplified to trying to put the name of the method in this sentence:

This code subscribes to {name_of_the_method}.

Examples

A) getUserName

This code subscribes to getUserName.

The sentence does not really make sense because getUserName does not express the stream. Quite on the contrary, it suggests that there is one value that you can get.

getUserName().subscribe()

B) observeUserName

This code subscribes to observeUserName.

Although the method kind-of expresses the stream of events, it does not work well with subscribe. Method exposing the Observable is not a place for information about observing. The consumer of the method will be observing what that method returns.

observeUserName().subscribe()

C) userNames

This code subscribes to userNames.

This might work in some cases. It nicely expresses a stream of userName items being emitted and works well with subscribe. It really depends on a particular scenario, because it suggests that you can expect multiple userNames while you really want to observe how a single userName changes. 

userNames().subscribe()

C) userNameChanges

This code subscribes to userNameChanges.

This method nicely expresses that there is a stream of items ("change" events) and it works well with subscribe method.

userNameChanges().subscribe()

Return to previous screen

As far as your returnToPreviousScreen case goes, I think I would end up using something like:

This code subscribes to returnRequests().

or

This code subscribes to previousScreenRequests().

or even a singular form as there can only be one event emitted in the stream:

This code subscribes to previousScreenRequest().

(not a topic of a question but I think I would use a Single<Unit> rather than Completable, to express a singular event emission rather than a completion... but maybe that's just me).

Bartek Lipinski
  • 30,698
  • 10
  • 94
  • 132