6

I've seen a lot of projects that show how to implement login in MVP, but can't find anything related to Google/Facebook login.

What should we do in the case when login flow is strongly bound to Android components life cycle? I see the main benefit of MVP in that we build an abstraction above Context, but this abstraction will appear too complex when we need to follow, for example, Facebook login flow: you need to register FacebookCallback with CallbackManager, call logInWithReadPermissions() (passing Activity/Fragment to it), delegate onActivityResult() to callbackManager and this will trigger FacebookCallback's methods.

What I have on mind is to create something like

interface AuthInteractor {
    void doFacebookLogin();
    void doGoogleLogin();
}

whose implementation will know about Context and initialize GoogleApiClient. It will be injected in Presenter, but what with all this callbacks (especially in Facebook's SDK) things are going to become too complicated. Isn't it better to omit MVP in such cases?

Sufian
  • 6,405
  • 16
  • 66
  • 120
Yaroslav
  • 4,750
  • 3
  • 22
  • 33
  • Not so sure about your question, but I dont agree with the interface, IMHO I would create a FacebookLogin and GoogleLogin class that implements the same interface and abstract the particularity of each login flow. – jonathanrz Mar 19 '16 at 14:46
  • @jonathanrz yeah, I did the same in my previous projects and I am going to reuse this code, two managers can be members of AuthInteractorImpl. But I really don't like such architecture and better write this without MVP – Yaroslav Mar 19 '16 at 14:50
  • since the authentication flow should stay in the controller, I dont see why it breaks the MVP pattern. – jonathanrz Mar 19 '16 at 14:51
  • @jonathanrz if presenter is not an Activity - it doesn't have access to Context, but I need it to make several calls during the flow. – Yaroslav Mar 19 '16 at 14:53
  • 3
    the dependency of the context in Android is a huge problem. To avoid that, I usually keep an static reference to my Application class, with that I can get the context anywhere in code. Since your Application object will leave the complete lifecycle of your App, you dont need to worry leaking memory with the static reference – jonathanrz Mar 19 '16 at 14:56
  • Did you resolve this problem? I faced with the same problem few days ago. – Oleg Skidan Sep 23 '16 at 06:24
  • @OlegSkidan just didn't use MVP in LauncherActivity – Yaroslav Sep 23 '16 at 10:38
  • so sad... I think about something like this - https://github.com/yongjhih/RxFacebook – Oleg Skidan Sep 23 '16 at 11:16
  • @OlegSkidan I think it isn't worth effort. keep it simple – Yaroslav Sep 23 '16 at 14:50

1 Answers1

2

I guess you're asking this question because you're trying to merge two "ideas" to a single one in your head:

  1. Activity/Fragment are MVP views
  2. Third party SDKs depend on Activity (or, at least, Context) in order to get access to platform resources available to your application

I stumbled upon similar issues about two years ago when I researched MVP implementations in Android, and I came to a conclusion that the only way to settle all issues of this kind is to abandon the idea of Activity/Fragment being MVP views.

I posted a detailed discussion of this issue in this post: Why Activities in Android are not UI Elements

And there is also a tutorial on how to implement a better MVP in Android: MVP and MVC in Android

Vasiliy
  • 16,221
  • 11
  • 71
  • 127