Applety Java

Applety Java
●
●
●
Są to komponenty stron WWW o ukrytym kodzie
Applety są pisane w zwykłej Javie i dlatego kompilowane
do pliku(ów) *.class, a nie interpretowane jak skrypty w
JavaScript
Aby przeglądarka odtwarzała applety, musi mieć JVM
–
●
dlatego w starszych wersjach MSIE przy uruchomieniu pierwszego
appletu konieczna była instalacja JVM
Applety są przykładem kodu Java wykonywanego
po stronie klienta, ale bez ujawnionej (jak w przypadku
skryptu) wersji źródłowej
Applety cd.
●
●
Zaletą appletu jest niedostępność jego źródeł,
wadą – skomplikowany proces przebudowy,
dłuższy od skryptu czas wykonywania
Applet można „zdisassemblować”
[JavaHome]\bin\javap
–
-c
plik_class
Odczytamy w ten sposób
–
–
–
ilość i nazwy klas
ilość i nazwy metod w tych klasach
ilość i miejsca wywołań tych metod
przykład
Klasy tworzące applet
ImageObserver,
MenuContainer,
Serializable
java.lang.Object
| +--java.awt.Component
| +--java.awt.Container
| +--java.awt.Panel
| +--java.applet.Applet
public class MyApplet
JApplet – ew. na bazie pakietu javax.swing
Jak działa applet ???
paint(Graphics)
repaint()
Funkcje klasy Applet
●
Sterujące wyglądem appletu
–
●
Współpraca ze stroną WWW
–
–
●
isActive();showStatus(String);getDocumentBase()
getParameter(); getImage(URL)
Multimedialne
–
●
resize(int,int); resize(Dim); paint(Graphics)
newAudioClip(URL); getAudioClip(URL); play(URL)
Zarządzające komponentami i zdarzeniami (dziedziczone z
Container)
– add(komponent); addItemListener(pojemnik)
Funkcje specjalne
●
●
●
Funkcje specjalne – zarządzające cyklem życia appletu;
„called by the browser” (wg dokumentacji)
void init( ) – przydział pamięci
dla zmiennych, przypisanie wartości pocz.
void paint(Graphics g) (maluj ) – rysowanie zawartości okna
apletu, obowiązkowa redef.
–
●
repaint() – odświeżenie okna appletu
Inne start(),stop(),destroy(), run()-zarządzanie wątkami
Tyloch, rozdział 2.6
Przykłady: Holzner, Clickers, Checkers, Dauber, Sandwich, itd.
–
Aplikacje interaktywne
Pojęcia podstawowe , Tyloch rozdz. 2.6.3
●
Zdarzenie – dowolne działanie użytkownika
w systemie/aplikacji; kliknięcie, ruch myszą, użycie
klawisza itp.
●
Komunikat – sygnał przekazujący do aplikacji parametry
zdarzenia, np. który „button” kliknięto,
jakie są nowe współrzędne położenia kursora myszy, kod
użytego klawisza itp.
●
Handler (ang. handle, obsługiwać) – fragment kodu
wykonywany w przypadku pojawienia się komunikatu,
odpowiedź na zdarzenie
Przykłady handlerów
●
C/C++:
OnButton1Click(....) //MFC 4.2
OnMouseMove(.....)
{
// funkcja jest składową jednej z
klas interfejsu, np. klasy okna aplikacji,
klasy widoku itp.
}
●
JavaactionPerformed(ActionEvent e)
if (e.getSource() == button1)
{...}
}
Zasada akcja-reakcja
{
Pętla obsługi zdarzeń
N
Czy zaszło
zdarzenie ?
N
Czy w aplikacji
jest handler?
Nasłuchuj dalej...
T
T
Odczytaj parametry zdarzenia
handler()
Wygeneruj komunikat
T
handler()
Czy w sys.op.
jest handler?
N
Ctrl+Esc
Corel
Pętla obsługi zdarzeń cd.
●
Wyjście z pętli na poziomie aplikacji następuje
po wywołaniu handlera „exitApplication” (w aplikacji
aktywnej)
–
●
Alt+F4, kliknięcie krzyżyka, menu „Zakończ” itp.
Wyjście z pętli obsługi zdarzeń na poziomie systemu
następuje w przypadku zamknięcia systemu
Relacja zdarzenie-handler
●
Jeden handler może być wywołany dla kilku różnych
zdarzeń
–
Ctrl+S, Menu File-Save, kliknięcie „dyskietki” na toolbarze
<Ctrl+S>
OnFileSave()
Jedno
zdarzenie może mieć przypisany tylko jeden handler
 Wiele do jednego
Klasyczny i delegacyjny model
obsługi zdarzeń Tyloch, rozdz. 2.6.3
Model klasyczny (tradycyjny)
Handler jest składową obiektu przyjmującego zdarzenie (najczęściej
odziedziczoną po klasie nadrzędnej)
Handler jest osobną funkcją wyspecjalizowaną w obsłudze konkretnego
zdarzenia (1 funkcja – 1 zdarzenie )*
public class MouseOperations extends Applet
{
public boolean mouseUp(Event event, int x ,int y)
public boolean mouseDown(Event event, int x ,int y)
public boolean mouseDrag(Event event, int x ,int y)
.................................
}
{......}
{......}
{...... }
Wady modelu tradycyjnego
●
W modelu tradycyjnym klasa gotowa przyjąć zdarzenie musi mieć
handler „na każdą okazję”
– duży rozmiar kodu źródłowego – zob. w dokumentacji
– konieczność dziedziczenia wszystkich potencjalnych handlerów
do klas, które nie zamierzają z nich korzystać;
zmniejsza to przestrzeń nazw metod
● java.applet.Applet
dziedziczy te wszystkie funkcje
po java.awt.Component
dokumentacja
– brak realizacji zasady enkapsulacji – obsługę zdarzeń
można by przenieść do klasy wyspecjalizowanej tylko
w odpowiadaniu na zdarzenia
● przykład z Tylocha rozdz. 2.6.3
Model semi-delegacyjny MFC 4.2
●
Microsoft Foundation Class
–
●
Analogicznie – JFC
MFC 4.2 – (model semi-delegacyjny) zdarzenie
trafia do kolejnych klas aplikacji (lub ich
przodków) wg ustalonego porządku: widokdokument-ramka-aplikacja
Model delegacyjny w Javie (1)
• Od kwietnia 1997, JDK 1.1
•
• Handler jest funkcją lub fragmentem funkcji
zadeklarowanej w implementowanym interfejsie
• Obiekt obłsugujący zdarzenie nie musi mieć
• Zdarzenie można obsłużyć w dowolnej innej
klasie, czyli „oddelegować” je.
Przykład: Tyloch, rozdz. 2.6.3
Model delegacyjny w Javie (2)
Java – zdarzenie trafia do klasy aplikacji, stamtąd delegowane jest do metody
zarejestrowanego interfejsu w tej lub w innej klasie
●
Zasady obsługi zdarzeń w modelu delegacyjnym.
1. Deklaracja klasy (przeznaczonej do obsługi)
implementującej odpowiedni interfejs nasłuchujący
2. Rejestracja dla danego komponentu obiektu klasy
nasłuchującej
czyli ''kto odpowiada za obsługę kliknięcia przycisku?''
– Przykład z tą samą klasą: Holzner/clickers
● kontrolka.addCośtamListener(this)
– Przykład z klasą wyspecjalizowaną: Tyloch
● kontrolka.addCośtamListener(ob_z_handlerami)
3. Implementacja metod z interfejsu nasłuchującego.
●
Warianty obsługi zdarzeń
w modelu delegacyjnym
Dotyczy punktu 2. z poprzedniego slajdu
Klasa wyspecjalizowana w obłsudze zdarzeń może być
●
Tą samą klasą której komponent przyjmuje zdarzenie
●
Klasą zewnętrzną względem przyjmującej zdarzenie
●
Klasą wewnętrzną względem przyjmującej zdarzenie
●
Klasą anonimową (!!!) (JCreator, v. 3.1 i nowsze)
●
Klasą adaptacyjną skojarzoną z danym interfejsem
– wewnętrzną lub zewnętrzną