Rolf-Smit
commented
2 years ago Ultimately we would like to detect inside Parley whether to use the fragment or activity method. So that it is less work to implement Parley for everyone.
But unfortunately the context of the view doesn't reveal if we are inside the fragment or not. So the suggested callback implementation will work for this. We'll add these instructions to the advanced configuration when releasing this.
Yes this would be really hard to do, therefore I also went with this approach instead. In the future I could see Parley being used in 2 ways:
- Through a Fragment (ParleyFragment) where a lot is automatically taken care of (internally uses the ParleyView).
- Through a View (ParleyView), that allows for more customization, but requires a bit more setup.
alexkok
Currently the Parley library is forcing us to handle Activity results or permission request results inside Activities. Workarounds to handle these results in Fragments can be done, for example getting the instance of the Fragment that hosts the ParleyView and passing the results to that Fragment from the Activity, however that is not a perfect solution and requires some very strictly coupled code between the Activity and Fragment. We prefer to keep our Activities and Fragments separated in such a way that they don't really know about each other.
This pull-requests adds a callback/listener that allows client applications to change how Parley launches Activities and permission requests. By allowing these to be intercepted, client applications can change whether the Activity starts these Activities or request, or whether a Fragment does this.
This is a minimal implementation from my side, if you have suggestions please let me know.