Facebook test applicatie deployment

maart 22, 2009

Vooralleer aan de ontwikkeling van de facebook applicatie begonnen wordt, werd een test applicatie ontwikkeld. Deze testapplicatie had als doel uit uittesten van enkele nieuwe technologieën om de ontwikkeling van de gebruikersinterface te vergemakkelijken, alsook het localiseren van enkele knelpunten bij het ontwikkelen van de business logic en facebook interactie.  

Gebruikte technologieën

User interface

Uit vroegere ervaringen blijkt dat het ontwikkelen van een gebruikersinterface voor een website zeer onderhevig is aan de gebruikte webbrowser. Hiertoe werd dan ook geopperd een nieuwe technologie te gebruiken die toelaat om browseronafhankelijke html pagina’s te genereren. Het betreft hier de Google Web Toolkit technologie.

In essentie voorziet deze toolkit de mogelijkheid om websites te ontwikkelen in een java omgeving. Deze geschreven javacode zal omgezet worden naar enkele javascript bestanden. Deze scripts zullen ingevoegd worden in de gewenste html pagina’s en zijn zo gegenereerd dat deze browseronafhankelijke html code produceren.

Een tweede positief eigenschap van GWT is dat deze standaard een allegaartje aan standaard widgets voorziet. Het betreft hier allerhande panels, buttons, tables, pop-up,… Deze widgets kunnen aangemaakt worden als simpele java objecten en laten een makkelijke onderlinge interactie toe. Op deze manier is het mogelijk om op een eenvoudige manier een zeer interactieve gebruikersinterface te ontwikkelen.

Mijn eerste ervaringen met het ontwikkelen van de client zijde van de test applicatie waren dan ook zeer positief. Vooral de mogelijkheid om op een snelle manier een functionele interface uit de grond te stampen door het gebruik van enkele simpele widgets sprak me aan. Dat dit alles kon gebeuren in een vertrouwde java omgeving versterkte dit gevoel alleen maar.

Business logic

Java server

Aangezien de client zijde van de applicatie in java ontwikkeld wordt, lijkt het zeer aannemelijk deze lijn door te trekken naar de server kant. Hiertoe voorziet GWT een remote procedure call mechanisme. Deze server calls worden door de google omgeving vertaald naar asynchrone ajax oproepen.

Voor het realiseren van deze communicatie dienen echter enkele procedures gevolgd te worden. Het betreft hier de ontwikkeling van een service interface en bijhorende implementatie. Deze zal verantwoordelijk zijn voor het afhandelen van binnenkomende oproepen. Om de implementatie van de oproep te verwezenlijken dient een tweede interface, zeer gelijkaardig aan de service interface, gecreëerd te worden. Daarenboven moet nog een callback object aangemaakt worden dat het terugkerende resultaat zal verwerken. Al deze objecten dienen een stricte naamgeving en methode vormgeving te volgen waardoor deze werkwijze zeer onderhevig is aan fouten. Bovendien dienen voor de services nog xml configuratie bestanden aangepast te worden, wat het geheel nogal ongebruiksvriendelijk maakt.

Om de applicatie te testen kan deze gerund worden binnen een makkelijk te gebruiken testomgeving. Bij het deployen op een server echter laat de gebruiksvriendelijkheid van de toolkit te wensen over. Hierbij dienen namelijk class files van folders verplaatst, jars toegevoegd en nog meer xml bestanden aangepast te worden.

Bovenstaande factoren, en het feit dat voor de opdracht geen java server beschikbaar werd gesteld, hebben ertoe geleid op de server kant van de applicatie niet in java te realiseren.

PHP server & JSON 

Voor de server zijde van de applicatie werd gekozen om een PHP en MySQL omgeving te gebruiken. Deze technologieën zullen instaan voor het opslaan en ophalen van applicatie gegevens. De manier waarop dit gebeurt is als volgt. Een php-pagina zal de gewenste gegevens uit de database halen. Het PHP script zal de gegevens encoderen naar het JSON formaat en dit weergeven op de pagina. JSON staat voor JavaScript Object Notation en geeft een universele representatie weer van data die makkelijk naar een javascript object geparsed kan worden.

Aangezien GWT onderliggend gebruik maakt van javascript kan het uitlezen van de gewenste data op een eenvoudige manier gebeuren. Via een simpele asynchrone html request naar de php-pagina kunnen de gegevens in JSON formaat uitgelezen worden uit de response. Deze kan dan vervolgens geparsed worden naar javascript objecten.

Het werken met deze technologie biedt enkele voordelen. Enerzijds biedt deze werkwijze de mogelijkheid om te werken binnen de voorziene omgeving. Anderzijds kan op een makkelijke manier data omgezet worden naar javascript objecten. Met deze objecten kan binnen GWT gewerkt worden als gewone objecten. Dit draagt bij tot de makkelijke ontwikkeling van de client in een object georiënteerde omgeving. Als laatste voordeel kan aangestipt worden dat facebook ondersteuning biedt voor applicaties ontwikkeld in een php omgeving. Wenst men een applicatie in java te deployen zal men echter moeten berusten op third party api’s. Bij het opvragen van facebook gegevens van de ingelogde gebruiker biedt deze werkwijze echter enkele nadelen, waarop later wordt teruggekomen.

Facebook integratie

Deployment

Een van de belangrijkste aandachtspunten bij het integreren van de applicatie binnen facebook is het aanpassen van de render methode. Standaard wordt een facebook applicatie gerenderd binnen de facebook omgeving. Deze rendering laat het gebruik van de FBML tags toe waardoor op een makkelijke manier gebruikers gegevens getoond kunnen worden. Aangezien de door GWT ontwikkelde pagina’s berusten op javascript zou een rendering binnen de facebook omgeving echter niets spectaculairs opleveren. Daarom moet de render methode ook veranderd worden naar iframe rendering. Hierdoor wordt de methode eerst gegenereerd op de hostende server en vervolgens geïnclude in de facebook omgeving.

Opvragen van gegevens 

Zoals hierboven aangehaald werd is het tonen van gegevens via de standaard FBML tags onmogelijk. Facebook voorziet echter een api waarmee gebruikersgegevens kunnen opgevraagd worden. Een eerste poging om gegevens van de gebruiker weer te geven werd als volgt benaderd. Een php-pagina werd gecreëerd die de gewenste gegevens via de facebook api opvraagt. Deze gegevens worden in JSON formaat weergegeven. Vanuit de gewenste pagina wordt een request gestuurd naar deze php-pagina en vervolgens verder gebruikt.

Tijdens de uitvoering van dit procédé deed zich echter een probleem voor. Wanneer gegevens worden opgevraagd aan facebook vinden namelijk een aantal berichtuitwisselingen plaats tussen facebook en de applicatie. Bij het versturen van de request naar de php-pagina bestond de response dan ook niet uit de gewenste JSON uitprint, maar uit een script dat uitgevoerd dient te worden om de gewenste pagina te renderen, waardoor het opvragen van gegevens via de api onmogelijk gemaakt werd. 

Oplossing

Aangezien het tussenvoegen van een renderengine binnen de applicatie als een niet haalbare optie bestempeld werd, werd een andere oplossing bedacht. Alle toegang tot de applicatie dient nu te gebeuren via een index pagina. Op deze pagina worden de gewenste gegevens van de gebruiker opgevraagd via de facebook api en opgeslagen in de MySQL database. Hierna wordt de gebruiker doorverwezen naar de eigenlijke applicatie.

Wanneer dan ergens binnen de applicatie de gegevens van de gebruiker nodig zijn, zal een request gestuurd worden naar een àndere pagina. Deze pagina zal echter niet gebruik maken van de facebook api, maar een database verbinding maken om de gegevens uit te lezen en weer te geven in JSON formaat. Op deze manier kan toch gebruik gemaakt worden van de gebruikersgegevens en wordt het probleem omzeild. Het nadeel van deze oplossing is echter dat alle communicatie via de index pagina moet gebeuren en dat een duplicaat van de gegevens dient gemaakt te worden. 

Conclusie

Dankzij het afwegen en uittesten van beschikbare technologieën worden de knelpunten op voorhand gesignaleerd en verholpen. Dit laat een snellere ontwikkeling toe van de eigenlijke facebook applicatie in een later stadium. Bovendien werd dankzij de ontwikkeling enige vertrouwdheid gekweekt met een voordien onbekende  technologie. 

 

 

 

 

 

 

One Response to “Facebook test applicatie deployment”

  1. erikduval Says:

    Ik ben niet helemaal overtuigd dat het een goed idee is om GWT te gaan doen voor een facebook app. Maar ik zal met aandacht jullie argumenten bekijken…


Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s

%d bloggers op de volgende wijze: