Friend finder

[abmargb]

Friend finder integration in the android client.

[abmargb]

Aim

• Find friends from other networks using the friend finder service https://github.com/buddycloud/buddycloud-friend-finder/blob/master/README.md
• Publish hashes from the address book, facebook and google accounts
• New activity that displays a list of networks to fetch contacts from and then display a list of respective channels.

Assumptions

• Uses generic channel fragment to show results

Tasks

• Fetch contacts from the phone and generate hashes
• Get ids from facebook and google accounts
• Communicate with the pusher
• Design and display friend finder activity

Flow

Main flow

MainActivity -> Friend finder activity -> MainActivity

Inside activity flow

Show network list -> Show channel list -> Finish activity

[imaginator]

Please also detail how you propose the UX for this to work.

[abmargb]

https://buddycloud.mybalsamiq.com/projects/android/Friend%20Finder%20Screen

[imaginator]

Have you considered:

• edge cases (no Twitter account/ or other accounts?)
• error messages
• where does this get called from in the app
• how does this return to the main app?
• how you follow the channel (it's not clear that you need to view it to
  follow it)
• Twitter and Facebook have a quick-follow button next to each name - why
  do you choose to not do this?
• What happens when the service is down but users request this page?

On 16 January 2014 22:22, Abmar Barros notifications@github.com wrote:

https://buddycloud.mybalsamiq.com/projects/android/Friend%20Finder%20Screen

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/142#issuecomment-32548371
.

Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
goo.gl/tQgxP

[abmargb]

I was reading (and trying to implement something) about integration with other SDKs (such as facebook's) before writing this down.

Due to the external auth process, I think that allowing the user to select multiple networks will make the whole procedure more complicated, UX-wise, thus I'm removing the checkboxes.

Generally, selecting one of those accounts will lead the user to an external auth dialog, which will return back a response code and an auth token, in case of success. In case of errors (SDK exceptions or connectivity issues), we could display a toast containing the error description and then go back to the first screen.

This activity should be launched from the action bar, and the back button, as expected, should get the user back to the main activity.

Currently, since we're using the generic channel fragment, the user has to click on the channel and then follow it, but I've got nothing against adding a follow button beside the channel item.

I've updated the mockups to comply with this discussion:
https://buddycloud.mybalsamiq.com/projects/android/Friend%20Finder%20Screen

[imaginator]

Good update.

• Are you proposing to write oauth providers for Twitter, Facebook and
  Google? (and others in the future?) Do you think users are going to trust a
  random app with their google password? I'm not convinced.
• Path was hammered for uploading the entire address book in cleartet -
  Your interface will also need to handle telling the user that we don't
  upload their address book in cleartext/just hashes.
• IMHO your first version should a) use the address book b) use the
  account manager
  https://developer.android.com/reference/android/accounts/AccountManager.htmlto
  match the account name (hash thereof)

[abmargb]

• The SDKs provide their own auth implementations, so we don't need to
  reimplement the auth process, it's just a matter of integrating them. And
  we don't handle passwords, the auth process redirects the user to the
  network's login activity, eg.: com.facebook.LoginActivity.
• I was going through StackOverflow answers regarding using the
  AccountManager vs. other networks' SDKs, and the majority leans towards
  using the SDKs:

http://stackoverflow.com/questions/4593061/how-to-retrieve-an-facebook-authtoken-from-the-accounts-saved-on-android
http://stackoverflow.com/questions/12972760/retrieving-auth-token-for-facebook-account-configured-in-mobile-via-account-mana

On Fri, Jan 17, 2014 at 2:03 PM, Simon Tennant notifications@github.comwrote:

Good update.

• Are you proposing to write oauth providers for Twitter, Facebook and
  Google? (and others in the future?) Do you think users are going to trust a
  random app with their google password? I'm not convinced.
• Path was hammered for uploading the entire address book in cleartet -
  Your interface will also need to handle telling the user that we don't
  upload their address book in cleartext/just hashes.
• IMHO your first version should a) use the address book b) use the
  account manager

https://developer.android.com/reference/android/accounts/AccountManager.htmlto
match the account name (hash thereof)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/142#issuecomment-32623739
.

Abmar Barros
MSc in Computer Science from the Federal University of Campina Grande -
www.ufcg.edu.br
OurGrid Team Leader - www.ourgrid.org
Buddycloud Dev - www.buddycloud.org
Paraíba - Brazil

[imaginator]

Same for Twitter and Google?

Please add this flow to the dev Readme so that it's clear for other client
developers.

S.

[imaginator]

• This is helping find friends already on buddycloud - for 99.99% of users
  this is "nobody"
• We're still missing a way for users to (probably first via) the address
  book to invite friends in.

On 17 January 2014 18:30, Simon Tennant simon@buddycloud.com wrote:

Same for Twitter and Google?

Please add this flow to the dev Readme so that it's clear for other client
developers.

S.

Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
goo.gl/tQgxP

[abmargb]

• The SDK approach works for Facebook. Twitter or Google or whatever may
  work differently as long as we don't handle the user credentials (login,
  password). I've written a ContactMatcher interface
  https://github.com/buddycloud/buddycloud-android/blob/master/src/com/buddycloud/fragments/contacts/ContactMatcher.javathat
  abstracts that logic.
• Contact matching deserves a new section on the readme file, which will be
  written as soon as this is ready.
• Yeah, most of the people won't find anyone in bc by using this.
• Invitations is something else.

On Sat, Jan 18, 2014 at 5:22 AM, Simon Tennant notifications@github.comwrote:

• This is helping find friends already on buddycloud - for 99.99% of users
  this is "nobody"
• We're still missing a way for users to (probably first via) the address
  book to invite friends in.

On 17 January 2014 18:30, Simon Tennant simon@buddycloud.com wrote:

Same for Twitter and Google?

Please add this flow to the dev Readme so that it's clear for other
client
developers.

S.

Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
goo.gl/tQgxP

—

Reply to this email directly or view it on GitHubhttps://github.com//issues/142#issuecomment-32677209
.

Abmar Barros
MSc in Computer Science from the Federal University of Campina Grande -
www.ufcg.edu.br
OurGrid Team Leader - www.ourgrid.org
Buddycloud Dev - www.buddycloud.org
Paraíba - Brazil