Best practices/strategies for a library project with activities, routing back to host activities?

Question

I'm working on a library project that includes a few activities. These activities would need to redirect back to activities in the host application based on input.

for example:

[host activity#1] -> [library activity] -> [host activity#1]
                                        -> [host activity#2]
                                        -> [host activity#3]

The issue I'm facing is providing a simple api for host applications to define which activity to route to in each scenario. I considered just allowing them to handle it in onActivtyResult, but some scenarios in the library may look like this:

[host activity#1] -> [lib activity#1] -> [lib activity#2] -> [host activity#1]
                                                          -> [host activity#2]

Is it normal/correct to create a static class in my library where the host application can define which activities are mean to handle each scenario?

Would it be appropriate to have them extend an interface in some static class that defines what to do in each scenario (the interface forcing them to define what happens in each possible case)?

I'm not quite sure how to phrase this question, and my assumption is that there is better terminology for this problem that would have assisted me in finding what I am looking for by searching.

Answer 1

The issue I'm facing is providing a simple api for host applications to define which activity to route to in each scenario. I considered just allowing them to handle it in onActivtyResult, but some scenarios in the library may look like this...

I don't see any issue with the onActivityResult approach, you can simply chain those calls and still return in to [host activity#1] which will decide where to navigate next.

If you are afraid about writing too much code (which I think you shouldn't), you can consider this workaround: create a base activity class which overrides onActivityResult(). It will have all navigation logic in one place, so all other activities will automatically get it by extending the base activity. Yes, you will have to write a bit ugly code like this:

if (this instanceof Activity1) {
    ...
} else if (this instanceof Activity2) {
    ...
}

Indeed, it does look a bit ugly, but it also solves the problem of having the code spread out across multiple activities. Having this code enclosed in one method looks totally fine for me from the maintainability point of view.

Is it normal/correct to create a static class in my library where the host application can define which activities are mean to handle each scenario?

No, I think this is not okay. The library shouldn't know anything about the host application, this is just a poor design. It also will require the host app to set activities to the library before using it, which will make the library less convenient to use.

Would it be appropriate to have them extend an interface in some static class that defines what to do in each scenario (the interface forcing them to define what happens in each possible case)?

Yes, that is perfectly fine and actually is the best way, I think. In this case the library only works through its own interface, it doesn't know anything about the host app. The interface doesn't have to be defined in a class though, I'd prefer defining it in a separate file. This way clients don't necessarily need to see the enclosing class.

I hope this helps. If I didn't answer the question, please provide more details and what you have tried so far.. Thanks, and good luck!