Forking gradle dependencies on Android

Question

I have not developed Android for a while and I am trying to do things right with the new features as the Gradle dependencies.

I am wondering what are the best practices when you need to modify one particular dependency for suiting you needs.

For example, let's say we have two libraries that extend the RecyclerView functionality by subclassing the Adapter:

Adapter --> AdapterA
Adapter --> AdapterB

Since Java does not support multiple inheritances, I guess the only way to make both libraries work together would consist on modifying one of them so the subclassing hierarchy looks like this:

Adapter --> AdapterA --> AdapterB

If I am correct and this is the way to go, what would then be the best way of modifying and integrating the library, here are the options I can think of:

1. Fork on GitHub and use JitPack to add the forked-modified library
2. Add library as a local module to the app and modify source

Please justify or suggest what is better and if there are any other alternatives to achieve this.

Humpage

Answer 1

I say just make a local module which depends on the other library and modify that. Don't forget to record which changes you've made. Ideally, you import the module as a separate commit in the VCS, and then you modify it in another commit.

This has the advantage that if you want to update the library, it will be fairly easy to do since all you have to do is copy over the source for the new version and then make the same modifications. However, if you take the other approach, then you'd also have to push all the changes to GitHub, which adds complexity, but little benefit unless you want to share your modifications with someone else.

Edgar

Answer 2

This seems like an unusual circumstance - Maybe an example would help
Also consider composition before resorting to forking libraries. https://en.wikipedia.org/wiki/Composition_over_inheritance

class YourAdapter {
    private AdapterA adapterA
    private AdapterB adapterB
}

Rabon

How would you use the composed adapters from the parent adapter (which isn't even an adapter)? – Swamper

Maybe the example described is an unusual circumstance, but I can imagine multiple situations where I'd like to fork and modify an existing dependency, from bugfixing to customization or adding features... – Humpage

@cricket_007 the parent adapter should extend the Adapter class and implement its methods. From there you'd be able to combine functionality from the children as per your requirements. This might work quite well in some cases but I agree that a fork might be inevitable in other cases. – Chalcography

@Chalcography Adapters are just not the type of classes which can be combined easily. So you delegate the necessary calls to both, they give the views to draw in the recycler view, and how are you going to reconcile that? Draw one on top of the other? I just don't see how this is useful in the current case. – Edgar

@Edgar I was thinking of MergeAdapter when I wrote my comment. It works for that particular case but you're absolutely right that composition probably isn't a good solution for most other cases. – Chalcography

@Chalcography If you refer to cwac-merge, that adapter simply takes the items from two adapters and shows them together in a single list. The items are still separate, which isn't what apascual is looking for if I understood the question correctly. – Edgar

@Edgar yes, I was referring to cwac-merge – Chalcography