Sprawdzone procedury — wskazówki dotyczące tworzenia aplikacji SWF

Wybór metody tworzenia aplikacji Animate zależy od typu aplikacji oraz stosowanej technologii.

Aplikacja online pozwala użytkownikom wpływać na zawartość odpowiednich stron internetowych. Na przykład, pewna aplikacja może zbierać informacje od użytkowników (takie jak nazwiska czy hasła), a następnie umieszczać te informacje na odpowiednich stronach (np. stronach forum); inna aplikacja może obsługiwać wymianę informacji między użytkownikami w czasie rzeczywistym (np. za pośrednictwem tablicy interaktywnej). Zależnie od rodzaju interakcji z aplikacją, wyniki zwracane przez serwer mogą trafiać do pliku SWF. Jak widać z przytoczonych przykładów tworzone aplikacje mogą zapewniać różnego rodzaju interakcje użytkowników z serwerem i innymi użytkownikami. Witryna internetowa, która nie wchodzi w interakcję z użytkownikami nie może zostać nazwana aplikacją. Wszystkie aplikacje Animate muszą dopuszczać interakcje między użytkownikiem, innymi aplikacjami internetowymi i serwerem internetowym. Podstawowe kroki tworzenia aplikacji są następujące:

Podczas tworzenia aplikacji trzeba wybrać protokół przesyłania danych. Protokół decyduje o tym, że do aplikacji docierają informacje o wysłaniu lub odbiorze danych, że jest znany format przesyłanych danych oraz jest znana odpowiedź serwera. Gdy dane trafią do pliku SWF, muszą zostać odpowiednio przetworzone i sformatowane. Jeśli jest używany odpowiedni protokół, nie trzeba się zajmować formatem danych. Jeśli dane są przesyłane w postaci par nazwa-wartość, można sprawdzić ich format. Należy sprawdzić, czy dane są sformatowane poprawnie. Pozwala to uniknąć odbierania danych w formacie XML, a rodzaj danych przekazywanych do pliku SWF jest przewidywalny.

Zbieranie i formatowanie danych

Sposób działania aplikacji zależy od interakcji użytkownika z plikiem SWF. Często też zależy od danych wprowadzanych przez użytkownika w formularzach. Program Animate zapewnia wiele możliwości wprowadzania i formatowania danych w aplikacjach. Bogactwo to wynika z faktu, że program ma rozbudowany interfejs, różnorodne funkcje do tworzenia animacji oraz pozwala implementować różne funkcje w języku ActionScript.

Zalety stosowanie programu Animate podczas tworzenia formularzy do gromadzenia danych:

• Lepsza kontrola nad projektem.

• Ograniczone zapotrzebowanie na odświeżanie stron.

• Możliwość stosowania typowych zasobów.

   Informacje zbierane od użytkowników należy zapisywać na ich komputerach, w postaci obiektów udostępnianych. Obiekty udostępniane, które pozwalają przechowywać dane na komputerach użytkowników, przypominają pliki cookie. Więcej informacji o obiektach udostępnianych (obiekty typu Shared) można znaleźć w podręcznikach ActionScript 2.0 Language Reference i ActionScript 3.0 Language and Components Reference, w rozdziałach dotyczących klasy sharedObject.

Wysyłanie i przetwarzanie danych

Przed wysłaniem informacji na serwer należy je odpowiednio przetworzyć i sformatować. Serwer dokonuje na danych dalszych operacji, odpowiednio je formatuje i odsyła do pliku SWF. Odsyłane dane mogą mieć bardzo różny format: począwszy od par nazwa-wartość aż do bardzo złożonych obiektów.

Na serwerze aplikacji musi być ustawiony następujący typ MIME danych wyjściowych: application/x-www-urlform-encoded. Jeśli typ MIME jest nieokreślony lub jest określony błędnie, dane wynikowe są dla programu Animate bezużyteczne.

W poniższej tabeli wymieniono różne sposoby wysyłania danych na serwer i odbierania danych z serwera za pośrednictwem programu Animate:

Wczytywanie i sprawdzanie poprawności danych

Przed wysłaniem danych na serwer należy sprawdzić ich poprawność. W ten sposób ogranicza się obciążenie serwera, który nie musi obsługiwać wszystkich żądań związanych z wprowadzaniem danych przez użytkowników. Nigdy, w przypadku żadnej aplikacji, nie należy poprzestawać na sprawdzaniu poprawności danych po stronie klienta; zawsze należy sprawdzać ich poprawność na serwerze.

Nawet jeśli jest używany specjalny formularz logowania lub specjalna procedura rejestrująca, należy sprawdzać, czy użytkownik wprowadził dane identyfikujące i hasło. Trzeba to sprawdzić przed wysłaniem żądania do skryptu na serwerze zdalnym. Nie należy też polegać wyłącznie na sprawdzaniu danych po stronie serwera. Jeśli zostanie wprowadzona tylko nazwa użytkownika (bez hasła), serwer musi odebrać żądanie, sprawdzić poprawność wysyłanych danych i zwrócić do aplikacji Animate komunikat o błędzie. Komunikat ma informować o tym, że trzeba wprowadzić i nazwę użytkownika, i hasło. Gdyby natomiast cała procedura sprawdzania poprawności danych była wykonywana tylko po stronie klienta (wewnątrz pliku SWF), to użytkownik mógłby wykraść plik SWF, ominąć operację sprawdzania poprawności i wysłać na serwer niepożądane dane.

Procedura sprawdzania poprawności danych po stronie klienta może być tak prosta, jak np. sprawdzenie, czy w danym polu wpisano co najmniej jeden znak, albo sprawdzenie, że użytkownik wprowadził liczbę, a nie ciąg znaków. Typowy przykład to sprawdzanie poprawności adresów e-mail: należy sprawdzić, czy dane pole tekstowe w aplikacji Animate nie jest puste, czy zawiera przynamniej jeden symbol @ i przynajmniej jedną kropkę (.). Procedura sprawdzania poprawności danych na serwerze jest bardziej skomplikowana, bo obejmuje sprawdzenie, czy adres e-mail należy do właściwej domeny.

Dane wczytywane z serwera do pliku SWF muszą być obsługiwane za pomocą odpowiedniego skryptu ActionScript. Po zakończeniu wczytywania danych do pliku SWF dane stają się dostępne. Za pomocą odpowiedniego skryptu ActionScript należy sprawdzić, czy dane zostały wczytane do końca. Po wczytaniu danych do dokumentu należy wygenerować odpowiedni sygnał, co umożliwia specjalny detektor lub funkcja sprzężenia zwrotnego.

Wczytywane dane mogą być różnie sformatowane:

• Mogą mieć format XML. W takim wypadku należy stosować do nich właściwości i metody klasy XML. Jeśli dane mają postać par nazwa-wartość, pary te są zamieniane na zmienne i można przetwarzać je tak, jak zmienne.

• Dane mogą pochodzić z usługi internetowej lub z aplikacji Animate Remoting.

W obydwu wypadkach mogą być stosowane złożone struktury danych (takie jak tablice, obiekty i zestawy rekordów), które trzeba odpowiednio analizować i wiązać z obiektami.

Obsługa błędów i debugowanie

Tworzone aplikacje powinny być wyposażone w funkcje przewidywania i obsługi możliwych błędów.

Jedna z najlepszych metod obsługi błędów w kodzie ActionScript 2.0 polega na stosowaniu bloków try-catch-finally, które umożliwiają zgłaszanie i wychwytywanie błędów niestandardowych. Wprowadzając własne, niestandardowe klasy błędów, można korzystać ze standardowych procedur obsługi błędów (stosując je po prostu do nowych klas). Aby uzyskać więcej informacji usuwaniu niestandardowych błędów, zapoznaj się z opisem klasy o tych obiektach, zobacz sekcję Error w podręczniku Dokumentacja języka ActionScript 2.0. Aby uzyskać więcej informacji o blokach try-catch-finally, zapoznaj się z opisem funkcji try..catch..finally w podręczniku języka ActionScript 2.0.

W języku ActionScript 3.0 do obsługi błędów służy klasa flash.errors.

Więcej informacji na ten temat zawiera rozdział „Obsługa błędów synchronicznych aplikacji” podręcznika Programowanie w języku ActionScript 3.0.

Porządkowanie plików i przechowywanie kodu

Przed rozpoczęciem porządkowania plików i zapisywania kodu należy rozważyć następujące kwestie:

• Czy plik SWF będzie dzielony na mniejsze pliki SWF, a jeśli tak, to jak będą one ze sobą współdziałać?

• Jakie zasoby będą współużytkowane przez pliki SWF?

• Jakie pliki będą wczytywane dynamicznie?

• Jak i gdzie będzie przechowywany kod ActionScript?

  Kod i pliki tworzonej aplikacji powinny być uporządkowane na serwerze w odpowiednio dobranej, drzewiastej strukturze katalogów — przypominającej układ katalogów kodu ActionScript. Dane muszą być uporządkowane według przejrzystych reguł oraz tak, aby zminimalizować ryzyko ich nadpisania.

  W przypadku większych aplikacji komunikację między serwerem a klientami należy zorganizować przy użyciu klas. Korzystanie z klas daje następujące korzyści:

• Kod można wykorzystywać wielokrotnie, w różnych plikach SWF.

• Kod może być edytowany w jednym miejscu; pliki SWF są aktualizowane przez ich ponowne publikowanie.

• Można utworzyć jeden interfejs API, który będzie obsługiwał różne elementy interfejsu użytkownika lub zasoby dotyczące podobnych funkcji.

Korzystanie ze standardu MVC

Standard MVC wyznacza podział projektowanych aplikacji na trzy części: ich zawartość informacyjną, moduły do przetwarzania danych oraz moduły do wizualizacji danych. Nazwa standardu MVC, a dokładniej jej kolejne litery, odpowiada trzem wyodrębnianym elementom: modelowi (ang. model), widokowi (ang. view) i kontrolerowi (ang. controller).

Określa dane i zasady działania aplikacji. Bardzo wiele własności aplikacji zależy od modelu. Model określa również wszystkie składniki (np. CFC, EJB i usługi internetowe) oraz bazę danych. Na etapie przetwarzania określonym przez model dane nie są formatowane dla potrzeb interfejsu. Zwracane dane mogą być stosowane w różnych interfejsach (lub widokach).

Określa wygląd aplikacji po stronie użytkownika (czyli interfejs użytkownika) oraz metodę wizualizacji danych modelu. Interfejs odpowiada za sposób prezentacji danych wyjściowych na komputerach użytkowników, a ponadto zapewnia użytkownikom dostęp do danych aplikacji. Każda zmiana modelu powoduje uaktualnienie widoku (w celu uaktualnienia są żądane i wysyłane dane). Jeśli jest tworzona hybrydowa aplikacja internetowa (na przykład kontrolująca interakcje między programem Animate a innymi aplikacjami na stronie), warto zaprojektować kilka interfejsów użytkownika w ramach wzorca projektowego widoku. Standard MVC umożliwia obsługę wielu widoków, czyli interfejsów.

Odpowiada za przetwarzanie i wyświetlanie danych zgodnie z wymaganiami modelu, zwykle zawiera dużo kodu. Zależnie od żądań użytkowników przekazywanych za pośrednictwem interfejsu (lub widoku) kontroler może odwoływać się do dowolnej części modelu. Ponieważ kod kontrolera jest zależny od aplikacji, zwykle nie można wykorzystać go do innych zadań. Inne składniki aplikacji mogą jednak być ponownie stosowane. Sam kontroler nie przetwarza ani nie wyświetla żadnych danych. Pełni funkcje decyzyjne: odbiera żądania użytkowników, decyduje, które składniki modelu lub widoku należy wywołać, a ponadto określa, gdzie należy wysłać dane i jaki format należy zastosować do zwracanych danych. Kontroler sprawia, że interfejs ma dostęp do tych części modelu, które muszą być wyświetlone. Kontroler zwykle odpowiada za przekaz danych o zmianach modelu i widoku.

Poszczególne części modelu stanowią odrębne i niezależne całości. Zmiana pewnej części modelu (np. zmiana zasad działania interfejsu) zwykle nie pociąga za sobą konieczności zmian w innych częściach. Jeśli aplikacja jest tworzona poprawnie, jej interfejs (czyli widok) można modyfikować bez konieczności wprowadzania zmian w modelu i kontrolerze. Jeśli aplikacja nie jest zgodna ze standardem MVC, to wszelkie zmiany jej elementów mają ogromny wpływ na kod, to znaczy staje się konieczna zmiana wielu fragmentów kodu.

Jedna z najważniejszych zalet standardu MVC polega na oddzieleniu danych i zasad działania aplikacji od interfejsu użytkownika. Dzięki takiemu rozdziałowi wiele różnych interfejsów graficznych może obsługiwać ten sam model i te same, niesformatowane dane. Oznacza to, że jedna aplikacja może współpracować z kilkoma interfejsami Animate, na przykład internetowym, dla komputera Pocket PC, dla telefonów komórkowych oraz HTML (całkowicie nieużywającym programu Animate). Oddzielenie danych od reszty aplikacji pozwala istotnie skrócić czas tworzenia, testowania czy nawet uaktualniania interfejsów użytkownika. Podobnie, w ramach już określonego modelu o wiele łatwiej jest projektować nowe interfejsy.

Standard MVC sprawdza się najlepiej w przypadku dużych i złożonych aplikacji, takich jak programy do obsługi elektronicznych witryn handlowych czy programy do nauczana na odległość (e-learning). Poprawne stosowanie standardu wymaga umiejętnego rozplanowania poszczególnych czynności oraz znajomości zasad działania programu Animate. Należy bardzo precyzyjnie określić zakres możliwych interakcji między różnymi składnikami aplikacji; zwykle wymaga to testowania i debugowania kodu. Gdy jest używany standard MVC, testowanie i debugowanie jest zwykle dużo trudniejsze niż w przypadku zwykłych aplikacji Animate. Jeśli jednak aplikacja ma realizować złożone funkcje, należy ją zaprojektować z wykorzystaniem standardu MVC.

Tworzenie bezpiecznych aplikacji

Niezależnie od tego, czy dana aplikacja obsługuje niewielki portal internetowy czy rozbudowany sklep online, zawsze istnieje ryzyko włamań, czyli pokonania zabezpieczeń aplikacji. Z tego powodu warto przestrzegać następujących zasad bezpieczeństwa:

• Dane, które powinny być bezpieczne, należy przesyłać z wykorzystaniem protokołu HTTPS. Prze wysłaniem danych na serwer zdalny należy zaszyfrować je w programie Animate.

   Żadnych ważnych informacji ani cennego kodu nie należy przechowywać w pliku SWF. Plik SWF bardzo łatwo zdezasemblować i obejrzeć jego zawartość.

• Należy utworzyć regułę zabezpieczeń międzydomenowych chroniącą ważne zasoby przed dostępem z nieautoryzowanych domen.