God praxis – riktlinjer för utveckling av SWF-program

Vilket som är det bästa sättet att skapa Animate-program beror på programmet du skapar och vilken teknik du använder för att konstruera programmet.

I ett onlineprogram kan en användare påverka en webbplats genom att interagera med den. Programmet kanske samlar in information från användaren (till exempel ett användarnamn och ett lösenord för registrering), information kan läggas till på webbplatsen (som på ett forum) eller så kan användaren interagera med andra webbplatsbesökare i realtid (som i ett chattrum eller på en interaktiv anslagstavla). Resultat från servern visas ofta i SWF-filen, beroende på interaktionen. Följande exempel är program som involverar användaren och olika typer av serverinteraktion. En webbplats som inte använder besökarinformation eller besökardata är inte ett program (till exempel en webbplats med en portfolio, en tecknad animering eller statisk information). Animate-program innehåller en interaktiv process mellan användaren, ett webbprogram och en server. Grundprocessen är följande:

När du skapar ett program måste du välja ett protokoll som ska användas för att överföra data. Protokollet meddelar programmet när data skickas och tas emot, i vilket format data överförs och hur serverns svar ska hanteras. När data har tagits emot i SWF-filen måste de ändras och formateras. Om du använder ett protokoll behöver du inte oroa dig för att data kan vara i ett oväntat format. När du överför data med namnvärdespar kan du kontrollera hur data är formaterade. Kontrollera att dina data har rätt format så att du inte får XML-formaterade data och så att SWF-filen vet vilket dataformat den ska arbeta med.

Samla in och formatera data

Program kräver att användaren interagerar med en SWF-fil. Detta sker ofta genom att användaren skriver in data i formulär. Det finns många sätt att ange och formatera data i Animate-program. Denna flexibilitet beror på möjligheten till animeringar, kreativ kontroll över gränssnittet och felsökning och validering med ActionScript.

Fördelarna med att skapa formulär för datainsamling med Animate är bland annat:

• ökad designkontroll

• minskat eller inget behov av att uppdatera sidan

• återanvändning av vanliga resurser.

   Spara information från användaren i ett delat objekt på användarens dator. Delade objekt gör att du kan spara data på användarens dator på ungefär samma sätt som med en cookie. Mer information om delade objekt finns under klassen SharedObject i Språkreferens för ActionScript 2.0 eller Referenshandbok för ActionScript 3.0 i Adobe Flash Professional CS5.

Skicka och behandla data

Oftast måste du behandla informationen innan den skickas till servern så att den har ett format som servern förstår. När servern tar emot dina data kan de manipuleras på ett antal sätt och skickas tillbaka till SWF-filen i ett format den kan ta emot, vilket kan vara allt från namnvärdespar till komplexa objekt.

 Din programserver måste ha MIME-typen för utdata inställd på application/x-www-urlform-encoded. Om MIME-typen saknas kommer resultatet oftast att vara oanvändbart när det kommer fram till Animate.

I följande tabell visas flera alternativ för att skicka data till en server och ta emot data med Animate:

Lägga till datainläsning och validering

Validera all information du hämtar innan du skickar några data till en server. Det minskar belastningen på fjärrservern eftersom den inte behöver hantera lika många svar om användaren inte fyller i obligatoriska fält. Förlita dig aldrig på enbart validering på klienten i något program. Validering måste även göras på servern.

Även om du skapar ett enkelt formulär för registrering eller inloggning måste du kontrollera att användaren har angett namn och lösenord. Gör valideringen innan du skickar begäran till skriptet på fjärrservern och vänta på resultatet. Förlita dig inte enbart på validering på servern. Om användaren bara anger användarnamn måste skriptet på servern ta emot begäran, validera skickade data och returnera ett felmeddelande till Animate-programmet som säger att både användarnamn och lösenord krävs. Liknande problem uppstår om valideringen bara görs på klientsidan (i SWF-filen). Användaren kan hacka SWF-filen, förbigå valideringen och försöka skicka felaktiga data till servern.

Validering på klientsidan kan vara något så enkelt som att se till att ett formulärfält är minst ett tecken långt eller att användaren anger ett numeriskt värde och inte en sträng. Du kan till exempel validera en e-postadress genom att kontrollera att textfältet i Animate inte är tomt och innehåller ett snabel-a (@) och en punkt (.). För validering på serversidan lägger du till mer komplicerad validering och kontrollerar att e-postadressen tillhör en giltig domän.

Du måste skriva ActionScript-kod som hanterar de data som läses in i SWF-filen från servern. När alla data lästs in i en SWF-fil kan de användas från den platsen. Kontrollera om alla data har lästs in med ActionScript. Du kan använda återkopplingsfunktioner eller avlyssnare för att skicka en signal om att data har lästs in i dokumentet.

När du läser in data kan de formateras på flera sätt:

• Om du läser in XML använder du metoderna och egenskaperna i klassen XML för att tolka och använda data. Om du använder namnvärdespar blir paren variabler och du kan manipulera dem som variabler.

• Du kan hämta data från en webbtjänst eller från Animate Remoting.

I båda dessa fall kan du hämta komplicerade datastrukturer, till exempel arrayer, objekt eller registeruppsättningar, som du måste tolka och binda på lämpligt sätt.

Använda felhantering och felsökning

Programmet måste vara stabilt nog för att kunna förutse vissa fel och hantera dem på lämpligt sätt.

Ett av de bästa sätten att hantera fel i ActionScript 2.0 är att använda try-catch-finally-blocken som du kan använda för att skapa och hantera anpassade fel. Om du skapar anpassade felklasser kan du återanvända kod i hela programmet utan att behöva skriva om felhanteringskoden. Mer information om hur du skapar anpassade fel finns i Error-klassen i Språkreferens för ActionScript 2.0. Mer information om try-catch-finally-blocken finns i try..catch..finally i Språkreferens för ActionScript 2.0.

Använd flash.errors-klassen för att fånga upp fel i ActionScript 3.0.

Mer information finns under "Hantera synkrona fel i ett program" i Programmering med ActionScript 3.0.

Organisera filer och spara kod

Tänk på följande innan du börjar organisera filer och spara kod:

• Ska du dela upp SWF-filen i flera SWF-filer och hur ska de i så fall interagera?

• Vilka resurser kan delas av SWF-filer?

• Vilka filer ska du läsa in dynamiskt?

• Hur och var ska du spara ActionScript?

  När du utvecklar ett program sparar du kod och filer på servern i en logisk katalogstruktur som liknar den i ett ActionScript-paket. Om du ordnar koden på det här sättet kan du hålla den välorganiserad och minska risken för att koden skrivs över.

  För större program kapslar du in kommunikation och tjänster mellan klient och server i klasser. Att använda klasser har följande fördelar:

• Du kan återanvända koden i mer än en SWF-fil.

• Du kan redigera koden på en central plats och uppdatera alla SWF-filer genom att publicera om dem.

• Du kan skapa ett enda API som kan manipulera olika gränssnittselement och andra resurser som har liknande funktion.

Använda designmönstret MVC

Designmönstret MVC används för att separera information, utdata och databehandling i programmet. Programmet är uppdelat i tre delar: modell, vy och kontrollenhet. Varje element hanterar en separat del av processen.

Modellen innehåller programmets data och regler. En stor del av programmets behandling sker i den här delen av designmönstret. Modellen innehåller också eventuella komponenter (CFC:er, EJB:er och webbtjänster) och databasen. Data som returneras är inte formaterade för programmets gränssnitt (den synliga delen) i den här delen av processen. Returnerade data kan användas i olika gränssnitt (eller vyer).

I vyn hanteras den synliga delen av programmet (gränssnittet som användaren interagerar med) och modellens innehåll visas. Gränssnittet specificerar hur modellens data presenteras och visar vyn för användaren så att användaren kan använda och ändra programmets data. Om modellen ändras uppdateras vyn så att ändringarna reflekteras genom att data antingen skickas eller begärs. Om du skapar ett hybridwebbprogram (till exempel ett där Animate interagerar med andra program på sidan) utgör de olika gränssnitten en del av vyn i designmönstret. Designmönstret MVC stöder hantering av ett antal vyer.

Kontrollenheten hanterar modellens och vyns krav på behandling och visning av data. Den innehåller oftast mycket kod. Den anropar någon del av modellen, beroende på vad användaren gör i gränssnittet (eller vyn) och innehåller kod som är specifik för programmet. Eftersom koden är programspecifik går den oftast inte att återanvända. Designmönstrets andra delar kan däremot återanvändas. Kontrollenheten behandlar inga data och ger inga utdata, men den tar emot användarens begäran och avgör vilken del av modellen eller vyn som ska anropas, var data ska skickas och vilken formatering som ska utföras på de data som returneras. Kontrollenheten ser till att vyer kan komma åt de delar av modellens data som ska visas. Kontrollenheten överför och svarar vanligen på ändringar som har att göra med modellen och vyn.

Varje del av modellen är skapad som en fristående komponent i den övergripande processen. Om du ändrar en del av modellen (du kanske till exempel omarbetar gränssnittet) behöver processens andra delar oftast inte ändras, vilket minskar eventuella problem. Om designmönstret är skapat på rätt sätt kan du ändra vyn utan att omarbeta modellen eller kontrollenheten. Om designmönstret MVC inte används i programmet kan ändringar var som helst få spridda effekter överallt i koden så att du måste göra mycket fler ändringar än om du hade använt ett specifikt designmönster.

En viktig anledning att använda mönstret MVC är att separera data och logik från användargränssnittet. Genom att separera dessa delar kan du ha flera olika grafiska gränssnitt som använder samma modell och oformaterade data. Det innebär att du kan använda programmet med olika Animate-gränssnitt, till exempel ett gränssnitt för Internet, ett för Pocket PC, ett för mobiltelefoner och kanske en HTML-version där Animate inte används alls. Att separera data från resten av programmet kan avsevärt minska tiden det tar att utveckla, testa och till och med uppdatera mer än ett klientgränssnitt. På samma sätt blir det lättare att lägga till nya synliga komponenter för samma program om det finns en befintlig modell att använda.

Använd bara MVC om du bygger ett stort och komplicerat program, till exempel en e-handelswebbplats eller ett e-utbildningsprogram. Arkitekturen kräver planering och förståelse för hur Animate och designmönstret fungerar. Tänk noga igenom hur de olika delarna interagerar med varandra. Detta inbegriper vanligtvis testning och felsökning. När du använder MVC är testning och felsökning svårare än med vanliga Animate-program. Om du skriver ett program där du behöver den extra komplexiteten kan det vara bra att organisera arbetet med MVC.

Skapa säkra program

Oärliga användare kan försöka hacka programmet, oavsett om du bygger en liten portalwebbplats där användare kan logga in och läsa artiklar eller en stor webbutik. Därför bör du göra följande för att programmet ska bli säkert:

• Använd HTTPS för data som behöver vara säkra. Kryptera värdena i Animate innan du skickar dem till en fjärrserver för behandling.

   Spara aldrig information eller kod i en SWF-fil som du inte vill att användarna ska se. Det är lätt att demontera SWF-filer och visa deras innehåll med program från andra tillverkare.

• Lägg till en korsdomänsprincip som förhindrar att obehöriga domäner får åtkomst till dina resurser.