[Discussion] Code structure and convention about rxandroid HOT 4 CLOSED

For what it's worth, at SoundCloud we use the latter. We would have e.g. a tracks Observable. I prefer this for two reasons:

• I think of Observables as collections or streams. Giving them the name of what is being streamed seems natural.
• You can streamline creation of observables via operators/adaptors or those created by create. At the end of the day, all those methods return observables, so consistency in naming makes sense to me

from rxandroid.

I guess I can use this issue for further code structure and code convention questions.

I am relatively new to the RX and MVVM topic but have managed to build my first application using these technics (soon available). While doing so we stumbled across a lot of common issues when doing Android apps. I want to share the gathered experience with you as I would love to hear if I do something terribly wrong or if you solved it in a better a way.

• Adapters:

public class XXXItemViewAdapter extends ArrayAdapter<XXXItem, XXXItemView> {

    // Constructor

    public XXXItemViewAdapter(Context context, List<XXXItem> array) {
        super(context, array);
    }

    // ArrayAdapter

    @Override
    protected void onPrepareViewForReuse(XXXItemView view) {
        view.getViewModel().prepareForReuse();
    }

    @Override
    protected XXXItemView onCreateViewAtPosition(int position) {
        return new XXXItemView(getContext());
    }

    @Override
    protected void onBindValues(XXXItemView view, XXXItem item) {
        view.getViewModel().itemCommand.onNext(item);
    }
}

ArrayAdapter is a simple base adapter which abstracts reusing handling and getting data from an array. The main thing here is that I only need to implement 4 methods.

• 1. The constructor, which is super simple as we are just calling super.
• 2. onPrepareViewForReuse which is called by the super class adapter when a view is about to be reused.
• 3. onCreateViewAtPositionwhich is called by the super class adapter when a view needs to be created. Same as on "getView" if the input convertView is null.
• 4. onBindValues called when the view is created or reused. I simply send the new item to the item command. The view model then decides what needs to be displayed in the item view.

Pros:

• I don't need to test that code... (I need to test the "ArrayAdapter" once and the view model)
• It's pretty easy to create new adapters

Cons:

• Not optimal if you need different view types
• I think one could reduce the boilerplate code...

TBC

• ListItemView
• AbstractContextViewModel
• Navigation
• more more more

PS:
I really think we should update the wiki and create more examples, best practices etc. We could also create a markdown file on the main repo, and contribute to it by using pull requests. Just an idea :)

from rxandroid.

This has come up a few times before: classes implemented OnSubscribe used to be called "operators" in pre-release versions of RxJava, but with the arrival of Operator they got renamed bit by bit and are now all called OnSubscribe*. cf. for instance https://github.com/ReactiveX/RxJava/blob/1.x/src/main/java/rx/internal/operators/OnSubscribeCache.java

Unless anyone has objections, I think we should follow suit and rename our classes accordingly and adopt this convention going forward.

from rxandroid.

As part of #172 all of the inconsistent naming conventions have been removed. We will be absolutely mindful of this in the future as things get re-added. Consistency is a great thing!

from rxandroid.