Czy da się stworzyć jedną aplikację na wiele Facebooków?

Facebook, Grono, Mixi i wiele innych serwisów społecznościowych ma API i można do nich pisać aplikacje. W tej sytuacji trochę bez sensu jest już pisać aplikacje tylko na jedną z tych platform. Jak w takim razie stworzyć aplikację, która będzie działać na wszystkich możliwych platformach społecznościowych? Nawet takich, które jeszcze nie istnieją?

Dzisiaj nie będzie łagodnego wstępu wprowadzającego w temat. Ten wpis przeznaczony jest przede wszystkim dla programistów. Sytuacja jest podobna do tego jak niegdyś było z systemami operacyjnymi. Tylko że wtedy było trudniej jednym kodem obsługiwać wiele środowisk. Teraz jest to możliwe i chciałbym pokazać jak to osiągnąć tym samym zapewniając aplikacji pełną elastyczność.

Pytanie jest o tyle zasadne, że oprócz Facebooka i Grona możliwe że już niedługo GG zaskoczy nas serwisem społecznościowym z API, z informacji od Naszej Klasy wynika, że i ten serwis za kilka lat otworzy API dla biznesu, czyli dla takich zwykłych programistów jak ja pewnie za 20 lat, oprócz tego mamy V Kontakte, które wprowadza polską wersję językową i ma już od dawna API i inne serwisy, które pewnie już prowadzą prace w tym kierunku.

Social Network Services with API - world

Skopiowanie kodu i struktur bazodanowych nie ma zbytnio sensu w odniesieniu do zasady DRY, więc od razu ten wariant odrzucam.

Każde API udostępnia specjalne tagi pozwalające na wykonywanie określonych akcji. Podstawowe dwie akcje dostępne we wszystkich społecznościówkach z API na świecie to: wrzucanie aktywności na ścianę i zapraszanie znajomych do wykonania jakiejś akcji. Aktywność na ścianie składa się z obrazka aktywności, tytułu, opisu i linka do jakiejś strony np. podstrony aplikacji z której pochodzi aktywność.

Czytaj podobne  Facebook kasuje profile firm i organizacji. Ustrzeżcie się zanim będzie za późno

Zaproszenie znajomych polega na wyświetleniu w reakcji na określony tag listy znajomych, z których możemy wybrać kilku i wysłać im obrazek z tytułem prośby, tekstem i linkiem gdzie chcemy ich skierować.

W przypadku Quizzów użytkownik może zaprosić swoich znajomych do wypełniania Quizzu, który mu się podobał albo umieścić na ścianie aktywności wynik wypełnionego quizzu. Są to dwa podstawowe sposoby komunikacji w społecznościówkach.

Można więc napisać interfejs komunikacji z serwisem społecznościowym z metodami np. InviteFriends i SendActivity i zaimplementować go oddzielnie dla Facebooka, oddzielnie dla Grona itd. zgodnie ze specyfikacją tych serwisów.

Kolejny problem to dane. Mamy obiekty wygenerowane przez użytkowników – w przypadku aplikacji “Quizzy” są to krotki z kolejnymi quizzami.  Trzeba podjąć decyzję czy użytkownicy Facebooka zobaczą quizzy Gronowiczów i odwrotnie. Jestem zdania, że taka interakcja nie powinna mieć miejsca ponieważ aplikacja z założenia ma ograniczać się do użytkownika i jego znajomych.

Nie ma sensu, żeby widzieli oni obiekty innych użytkowników (jak już to w ramach ciekawostki) a co dopiero ludzi z innego serwisu społecznościowego. Aplikacja daje użytkownikom poczucie prywatności, którego wytworzenie pozwala im na łatwiejsze interakcje ze znajomymi. Świadomość publiczności powoduje stres i zniechęca do większej aktywności o czym warto pamiętać.

Wyjątkiem są dane pośrednie a więc np. dane algorytmów. W ich przypadku czym więcej osób zgromadzimy tym lepszy będzie rezultat algorytmu.

Poza rozwiązaniem takich rzeczy jak skalowalność i wersje językowe (o czym napiszę też wkrótce) nie pozostaje nic innego jak uporać się z identyfikatorami użytkownika.

Każdy użytkownik społecznościówki ma swój identyfikator który reprezentuje jego osobę w serwisie. Dlatego, aby obsłużyć wiele serwisów dobrze jest przygotować tabelę z parą identyfikator, identyfikator serwisu społecznościowego i w innych tabelach wiązać do id krotki w tej tabeli (np. users_socials) zamiast do identyfikatora w określonym serwisie bezpośrednio.

Czytaj podobne  Cheaterzy opanowali grę społecznościową

Oprócz tego jest jeszcze problem wszystkich nietypowych zachowań które wymusza konkretna społecznościówka, jak na przykład autoryzacja użytkownika i autoryzacja zapytań czy pochodzą od serwisu społecznościowego (antyphishing). Wbrew pozorom jednak można i te zachowania uspójnić w interfejsie. Na podobnej zasadzie jak da się sparametryzować dostęp do wszystkich API mikroblogów (o czym też napiszę wkrótce).

Standardowe akcje jak InviteFriends i SendActivity nie tylko rozpowszechnią się wśród typowych społecznościówek pokroju FB, Mixi itp. ale też przeniosą się w społecznościówki tematyczne itd. Ponieważ wyznaczają one pewien standard zachowań na tego typu serwisach i wygląda na to, że odpowiadają za podstawowe społeczne interakcje jakie ludzie chcą realizować w Internecie. Według mnie można o takich podstawowych zachowaniach na serwisach społecznościowych mówić już jako o pewnym standardzie podobnie jak o standardzie budowy aplikacji desktopowych gdzie podstawowy zestaw kontrolek: przyciski, listy rozwijane był wspólny jest wspólny dla większości aplikacji. Dlatego dobrze jest już teraz implementować interfejsy do obsługi takich zachowań od strony aplikacji.

Dodatkową zaletą takiego podejścia jest możliwość łatwego “osadzania”  aplikacji u klienta który nie jest serwisem społecznościowym. Klient chce mieć na stronie sklepu możliwość wypełniania quizzu dotyczącego poziomu obsługi.  Nie ma problemu – wystarczy zemulować po stronie klienta zachowania społecznościówki. Tak samo można więc aplikację osadzić na własnej stronie tworząc swój serwis ze wszystkimi aplikacjami bez potrzeby rejestracji przez użytkownika na żadnym portalu społecznościowym, przez co zafektuje większą szybkością działania. Można też za pomocą mechanizmów takich jak Prism stworzyć z aplikacji webowej aplikację “desktopową”. Pomysły na wykorzystanie takiego mechanizmu pewnie jeszcze się pojawią.

Czytaj podobne  Jak stworzyć aplikację na Facebooku

Raz napisany kod będzie mógł służyć na wiele różnych sposobów wszędzie na świecie bez wiązania się z jedną platformą SNS. Użytkownicy wybierają społecznościówki na podstawie mody. Jednego roku modny jest jeden serwis (MySpace) a drugiego inny (Facebook), u nas tak było z Eplusem i Fotką, teraz trendy (jazzy etc.) jest NK i Facebook i pewnie wkrótce GG. Jest to trochę smutna rzeczywistość dla twórców społecznościówek. Programista aplikacji nie powinien uniezależniać się od jednego serwisu. Kod powinien być wykorzystywany – używając prawniczego żargonu – na wielu polach eksploatacji.

Wieża Babel uczy programistów czym jest ulotność kodu

Wiele wartościowego kodu zostało już zmarnowanego z powodu wieży Babel języków programowania, zmian technologii, bibliotek i środowisk programistycznych. Wejście na ten poziom abstrakcji daje większą szansę, że raz napisany kod będzie służył wielokrotnie.

Przeczytaj też

Programowanie gier społecznościowych na Facebooka ... W czym pisać kod gry? W PHP czy w JS? No i gdzie trzymać dane o rozgrywce i grach? Dowiedz się! W poprzednich częściach omówiłem kwestię wyboru ser...
Programowanie RMSBG na Facebooka cz. 5 – host gry... Kim jest host gry i czy powinien znajdować się na serwerze czy powinien nim być jeden z graczy? W poprzednich częściach ustaliliśmy środowiska prog...
Programowanie RMSBG na Facebooka cz. 4 – typ... Jakie typy komunikacji trzeba uwzględnić w pisaniu gry RMSBG? W poprzednich częściach założyliśmy, że robimy grę planszową RMSBG (Realtime Multipla...
Programowanie RMSBG na Facebooka cz. 3 – kom... Jak klient w JS może komunikować się z serwerem w PHP przez HTTP? W poprzednich częściach omówiłem rozwiązania klienckie i serwerowe dla gier RMSBG...
Programowanie RMSBG na Facebooka cz. 2 – Jęz... Jakie języki programowania trzeba znać, żeby pisać RMSBG na Facebooka? Dowiedz się. W poprzedniej części poruszyłem temat decyzji czy aby napisać R...
Napisano w Społecznościowe Tagi: , , , , , , , , , , , , , , , ,