No title

Közösségi hálózatok integrálása Android platformon Inotay Krisztián / [email protected]

Napjainkban… • Az egyes szociális hálózatok meghatározó szerepet töltenek be a felhasználók életében • Nagy a felhasználói igény arra, hogy bármit megoszthassanak ismerőseikkel, minél gyorsabban • Az egyes szociális hálózatok integrálása potenciálisan új felhasználókat jelenthet bármilyen alkalmazás számára • A mobil alkalmazások fokozottan érintettek ebben • A fejlesztőknek is szükségszerű követni ezt a trendet

Mire használhatjuk egyáltalán? • Legalapvetőbb az SSO > A felhasználó regisztrál az alkalmazásba egy közösségi hálós fiókjával > A felhasználó belép az alkalmazásba ugyanezzel a fiókkal

• A felhasználó az alkalmazással előállított tartalmakat oszthat meg az ismerőseivel (esetleg a világgal) • Képeket tölthet fel • Eseményeket hozhat létre, ismerősöket hívhat meg rá • Ezeket a funkciókat programozottan megvalósíthatjuk

3 kiválasztott platform • Google+ • Facebook • Twitter • A továbbiakban a fenti 3-ról fogok részletesen beszélni

Első lépések • A legfontosabb: mindig olvassuk el az adott szociális hálózat szabályzatát (tudom, tudom…) • Aztán a fejlesztői dokumentációt, de legalább azokat a részeket, amiket használni szeretnénk • Mindhárom általam hozott platformnál ezek után létre kell hozni egy „alkalmazást” a platform fejlesztői oldalán. Ezen az alkalmazáson keresztül kommunikálunk a szociális hálózattal. Azonosítja a mi mobilos alkalmazásunkat.

Google+ alkalmazás • Ez technikailag egy Google API Project • A megszokott Google Developer Console-on lehet létrehozni • Package name és szignatúra azonosítja az alkalmazásunkat (Android public API key) • Engedélyezni kell a Google+ API-t • A felület Credentials része eléggé el van dugva, de ott lehet megadni a Google+ által a felhasználónak mutatott adatokat (app neve, ikon, etc) • Enélkül hibát fog dobni az API hívás… (nem, nem beszédeset)

Facebook alkalmazás • A Facebook developer oldalán regisztrálhatja olyan Facebook felhasználó, aki developernek is regisztrál • Valódi mobiltelefonszám kötelező, kódot küldenek rá • UX szempontjából az oldal egy katasztrófa (elsőre még ijesztő is lehet) • Cserébe 3-4 havonta lecserélik az egészet, de nem lesz jobb • Az alkalmazáshoz külön kell készíteni Android, iOS, web, etc, hozzáféréseket • Androidnál package name és egy SHA-1-es keyhash szükséges • A keyhash előállításához van példa a dev doksiban

Twitter alkalmazás • Na ők korrektek • A hagyományos módon a twitter developer oldalán lehet regisztrálni • API key-t és secretet adnak, azzal lehet kapcsolódni az API-hoz • Csak OAUTH2-vel lehet kommunikálni • Az új Fabric viszont automatikusan legenerálja ezt nekünk (erről bővebben kicsit később)

Mivel érjük el az API-kat? • Szerencsénkre mindhárom platformnak van már saját SDK-ja (bár a Twitteré még csak néhány hónapos) • A Google+ SDK a Google Play Services része • A Facebook SDK beszerezhető gradle-lel • A Twitterhez most két SDK létezik: > Twitter4j – Java-ra implementált nem hivatalos SDK, a közelmúltig csak ez létezett (vagy a kézi URL hívások ugyebár). JAR-ként szerezhető be. Viszont kell kódolnunk hozzá hívásokat, ugyanis ők nem ismerték az AsyncTask-ot > Fabric Twitter SDK – ez az új, hivatalos SDK, gradle-lel importálható. A Fabric automatán be is húzza a projektünkbe, ha megkérjük rá.

Google+ és a Google Play Services • Soha se felejtsük el ellenőrizni, hogy egyáltalán van-e Google Play Services a készüléken (GooglePlayServicesUtil) • Mindössze 1 metódushívás • Nem csak igen/nem lehet a válasz, hanem az is, hogy frissíteni kell a készüléken ezt a komponenst • Szintén egy metódussal lokalizált dialógust lehet generáltatni a felhasználónak, ahol részletesen le van írva a probléma oka, illetve tartalmaz Intent-et a GooglePlay-hez is, frissítéshez vagy letöltéshez • De ezt úgyis tudjátok ☺

Google+ SDK part 1 • Pillekönnyű a megvalósítás, csak néhány metódust tartalmaz • Az API client létrehozásakor listenereket és jogokat kell mindössze átadni. Aztán meghívni egy connect() –et, és kész a login • Az API a listenereken keresztül szépen jelez, de ha hiba van, akkor nem jön egyértelmű üzenet, kb soha • Nincs igazi példaalkalmazás. Csak pár metódushívást mutatnak be, de azok kidolgozatlanok. Például sehol nem kezelik benne, ha egy felhasználó nem-et nyomott, vagy bezárt egy, az API által létrehozott dialógust.

Google+ SDK part 2 • Mindezek ellenére ha sikerül belőni, akkor könnyen használható • Legalábbis ha csak az alapvető funkciókat szeretnénk igénybe venni. • Viszont nincs belső session kezelés • Ha szerver oldali autentikáció is kerül a képbe, akkor megbolondul egy kicsit a történet: • A Google+ -os bejelentkezést követően egy olyan tokent kapunk, ami csak a mobil alkalmazáson belül érvényes… • Hoppsz…

Google+ Authorization Code • A GoogleAuthUtil osztállyal kérhetünk egy ilyen kódot magunknak (szintén dialógusos, engedélyköteles) • Ezt a kódot elküldhetjük a szerverünknek • Aki ezt becseréli egy token-re és egy refreshToken-re • A csere után az Authorization Code érvénytelenné válik • A token-nel a szerver már hozzáfér az adott felhasználó profiljához (jogosultságok megadhatóak) • Ha egyszer Androidon kérünk egy ilyet, akkor 15 percig mindig ugyanazt kapjuk vissza, hacsak kézzel nem forceoljuk, hogy törölje a cache-ből…

Google+ SDK bosszantó hibák • Ha egy képernyőn már hívtunk connect() –et, akkor disconnect() hívása után a connect() többé nem fut le… Soha… A megoldás a reconnect() hívása… Kösz! • (reconnect()-et viszont hívhatunk a connect() helyett) • Ha egy felhasználó először jelentkezik be, akkor a connectionFailed listeneren jön egy üzenet, hogy nincs engedély a felhasználótól. Ilyenkor egy Activity.startIntentSenderForResult()-tal kérhetünk egy engedélyező dialógust a felhasználónak. Viszont ehhez mindig kell activity context!

Facebook SDK alapok • LoginButton customView • CallbackManager • LoginManager

Facebook LoginButton • Felveszi a Facebook gomb dizájnját • Viszont lehet style-ozni • És nem mellesleg a háttérben kezeli a login flowt is, automatikusan • Fura, de ha mást nem használunk, ennek a gombnak kell beállítani a szükséges Facebook permission-öket is

Facebook CallbackManager • Korábban UiLifeCycleHelper néven futott • Az a feladata, hogy kezelje az onActivtyResult() ot • Nekünk csak azt kell biztosítani, hogy létezzen, és onActivityResult-ban meghívni ezt az egyetlen metódusát • Innentől kezdve ő maga kezeli a felugró dialógusokat, elnavigálásokat, amiket az SDK kezdeményez

Facebook LoginManager • Korábban Session volt • Programozottan kezelhetjük a felhasználó session-ét • Beléptethetjük, kiléptethetjük a felhasználót kódból, ha rendelkezünk a megfelelő engedélyekkel • Kezelhetjük a permission-öket • Nem utolsó sorban pedig, vele irathatunk fel listenert a login flow eseményeire

Facebook SDK hiányosságok • A tutorialokban többnyire elnagyolják a magyarázatokat • Gyakran hibás a tutorial, vagy a reference guide • Ha hozzáadjuk a gradle fájlhoz a tutorialban szereplő maven repot, akkor bizony az letölt nekünk 4 gigányi olyan libet, amit nem használunk semmire… • Gyakran szeretik megváltozatni az SDK metódusait

Twitter SDK part 1 • Nagyon friss • A Fabric Android Studio plug-in „teszi bele” a projektünkbe (ha akarjuk, lehet kézzel is) • Szintén van egy Login gombja, ez kezeli a felhasználó session-ét • Viszont itt ezzel iratkozhatunk fel az egyes eseményekre is • onActivityResult() – ot is neki kell átpasszolni

Twitter SDK part 2 • Tartalmaz UI kit-et is, vagyis komplett listákat, listaelemeket és ezekhez tartozó adaptereket is tweetek megjelenítéséhez • Valamint része egy tweet composer dialógus is • Mivel friss, viszonylag egyszerű, és kevés funkciót tartalmaz

Összefoglalva • Elmondhatjuk, hogy a G+ kicsit kilóg a sorból, mert a funkcionalitásának jórészét elfedi a Google Play Services • Az új Twitter SDK úgy néz ki, mintha a tervezői nagyon sokat nézegették volna a Facebook SDKt ;) (ez nekünk egyébként nem baj) • Viszont ha ezeket egyszerre akarjuk használni egy alkalmazásban… az nem egyszerű

Tippek • A szociális funkciók használatához mindegyik SDK-nál szükséges, hogy bizonyos metódusokat, osztályokat minden szociális funkciót használó nézeten implementáljunk • Ezért célszerű minimum egy ősosztályt gyártani, hogy ezeket az implementációkat egységesen tudjuk kezelni • Ha több szociális platformhoz is csatlakozunk egyszerre, jó ötlet lehet, egy egységes interfész kialakítása.

Tippek 2 • Legyünk nagyon türelmesek, mert sok probléma merülhet fel implementálás közben • Az SDK-k gyakran változnak, akár gyökeresen is, ezért is ajánlott a hozzájuk tartozó implementációkat külön kezelni, hogy könnyen lehessen akár az egészet kicserélni

Kérdések?

Inotay Krisztián / [email protected]