Hi folks. how do you deal with requesting permissi...

# android-architecture

[Sergey B]

Hi folks. how do you deal with requesting permissions in mvvm paradigm?

[streetsofboston]

Very similar in how you would handle regular Dialogs/DialogFragments when asking for some user-feedback (whether to continue or not, to save or cancel, etc).

[Ianmedeiros]

It’s a pain in the ass.

My recomendation: avoid injecting the activity as an interface in the view-model.

[Ianmedeiros]

Sadly, the framework imposes you to do the ping/pong between VM — ask permission --> UI --permissiongranted --> VM --updates --> Domain/Data

[Ianmedeiros]

I injected the activity as an interface PermissionRequester, but it forces me to clear the viewmodel store to avoid having a reference to a destroyed activity in the view-model when config changes

[Ianmedeiros]

The problem with the ping/pong is that it laks a lot of modularity. Every place you need to activate some feature that requires permission, you will need to copy/paste or use inheritance to handle this. Both are not desirable

[Ianmedeiros]

If you have a clever solution to it, I welcome you to share your solution

[ursus]

If you use conductor, you can have the controller reference inside your viewmodel (as an interface) and request directly, like a normal person 🙂

[ursus]

I personally check for permission in the viewmodel, if not then ask it, exit the function, then onPermissionrResult or whatever it is, I resolve the parameters at the view level, if permission is granted I call the same function again

[Sergey B]

thank you guys. I don' use conductor (probably I have to try). So probably I'll try the ping/pong between vm and my ui..

[Will Shelor]

I disagree with injecting the activity into the viewmodel- it has a huge possibility of leaking. Instead, I’d look at some sort of event stream to send subscribable events to the activity or fragment, and observe them. This should probably be done with SingleLiveEvent, Flowable, or Rx. The idea is that you want two mechanisms to get data into your activity - state (which is persistent) and actions (which are not)

[streetsofboston]

Note that subscribers/observers are often lambdas that capture your activity or fragment (as a reference to the implicit this). This also risks leakage of activities/fragment, if you are not careful to terminate/close/end the stream or cancel the scope.