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  Programowanie RMSBG na Facebooka cz. 3 - komunikacja klient - serwer

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  Sztuka pisania oprogramowania

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ą.

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.

Czytaj podobne  Komu zlecić projekt programistyczny

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ż

Najlepsza książka do Pythona Nie wiesz, z jakiej książki/ebooka uczyć się programowania w języku Python? Postanowiłem zrobić zestawienie 10 książek z Heliona na ten temat, abyś mó...
Komplet 28 ebooków i kursów, aby zostać programist... Od jakiegoś czasu dostaję zapytania na temat tego jakie książki, kursy i ebooki polecam. W związku z tym postanowiłem przygotować dzisiaj zestaw, któr...
120 tapet programistycznych za darmo do pobrania Trochę mi się nudziło, więc przygotowałem zestaw 120 tapet dla programistów. Możesz go pobrać. Tapety są w rozdzielczości 1366x768. Podzielone ...
10 fiszek do nauki programowania w Pythonie Uczysz się programowania w Pythonie? Pobierz te 10 fiszek, które ułatwią Ci zapamiętanie funkcji wbudowanych* w Pythona! Programowanie potrafi ...
Napisano w Kolumna Tagi: , , , , , , , , , , , , , , , ,

Menu