My most recent example of this problem was using G...

# android

[arkadiy]

My most recent example of this problem was using Google Play Services Location api and requesting user to enable GPS.

The method that does it has following signature:
fun startResolutionForResult(activity: Activity, requestCode: Int): Unit
In order to obtain the result of the user decision I have to override onActivityResult() method, thus I'm unable to abstract away from Activity the logic behind enabling GPS and keeping user preferences about it.
I also now have to keep the code about user preferences either in activity, thus completely violating Activity responsibilities, or as a separate object, hence creating unnecessary complex interaction between Activity, GPS request and user preferences as well as pretty tight coupling between all 3 of them.

What I really would like to do is just have a parameter of type UserLocationSettings in my Activity constructor and with a method like fun requestLocationUpdates(onEnabled: () -> Unit, onDisabled: () -> Unit): Unit. Thus I am able to easily unit test both my Activity and GPS request logic separately, as well as not maintain any real coupling between them.

Bus is exactly what I'm saying about reinventing the wheel and having only a distinct resemblance of a decent architecture if it is used for passing objects for component interaction.