bluelinelabs / bluelinelabs/Conductor
Allow registerForActivityResult() be able to register multiple controllers
- Dominant language
- Java
- Stars
- 3.9k
- Forks
- 338
- PR merge metrics
- No merged PRs in 30d
Description
Current behavior:
```kotlin
class Controller1 {
init {
registerForActivityResult(SOME_REQUEST_CODE)
}
}
// ========
class Controller2 {
init {
registerForActivityResult(SOME_REQUEST_CODE)
}
}
// ========
class Controller3 {
fun someFunction() {
startActivityForResult(SOME_REQUEST_CODE, SomeActivity::class.java)
}
}
```
in this situation only `Controller3` will receive `onActivityResult()` callback invocation.
It is not the first time I get caught up in situation where I expect that former two controllers would be "subscribed" too (documentation of `registerForActivityResult()` doesn't clearly suggest otherwise)
This happens because each request code is internally mapped to only **one** Controller - the latest one:
```java
public void registerForActivityResult(@NonNull String instanceId, int requestCode) {
activityRequestMap.put(requestCode, instanceId);
}
```
Do you think that this can be extended so that a list of controller `instanceId`s would be held there?
It would seriously simplify some situations, where several controllers must react to some external activity result. Otherwise one would have to use a similar mechanism where the controller which started that activity propagates a result to several controllers (`setTargetController`?)
Or do you see this as a bad pattern? Or maybe it would fit badly in library design?
Objections or suggestions are welcome. If you have nothing against this, I could submit a PR.
Contributor guide
Research direction
Start by locating registerForActivityResult and the activityRequestMap implementation shown in the issue. Trace how request codes are dispatched and inspect any related tests or callback handling. Done means establishing and documenting a supported design in which multiple registered controllers can receive the same activity-result callback, or clearly rejecting that design.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, java
- Domain
- mobile-dev
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100