Cel slajdu: zapowiedź trzeciej prezentacji cyklu - zestawu opisanych przykładów aplikacji.
Strona tytułowa
Tytuł: Przykłady aplikacji w App Inventor - od powitania do quizu i stopera.
Tytuł: Przykłady aplikacji w App Inventor - od powitania do quizu i stopera.
Prezentacja trzecia ma charakter praktyczny. Zamiast teorii pokazujemy kolejne, coraz trudniejsze aplikacje. Przy każdym przykładzie zwracamy uwagę na cel aplikacji, użyte komponenty, budowę interfejsu, logikę bloków, testowanie i możliwe rozszerzenia.
Taki schemat ułatwia studentowi samodzielne odtwarzanie przykładów i rozwijanie ich o własne pomysły.
Kolejność prezentowanych przykładów nie jest przypadkowa i ułożono ją tak, aby każde kolejne zadanie rozwijało umiejętności zdobyte wcześniej. Pierwsze aplikacje są minimalne i pokazują tylko jeden nowy mechanizm, dzięki czemu nic nie rozprasza uwagi. Dopiero końcowe programy, takie jak tabliczka mnożenia czy quiz, łączą kilka mechanizmów naraz. Dzięki takiej stopniowości student płynnie przechodzi od prostych reakcji po coraz bardziej rozbudowane programy. Szczególną rolę w tym procesie odgrywa testowanie na własnym telefonie, które zamienia każdy błąd w cenną lekcję.
Lista ośmiu przykładów została ułożona według rosnącej trudności, a nie tylko w kolejności chronologicznej. Dzięki temu student przechodzi od prostego powitania do quizu i stopera, obserwując, jak te same mechanizmy powracają w coraz bardziej rozbudowanej formie. Taki porządek sprawia, że każdy kolejny przykład odwołuje się do wiedzy zdobytej w poprzednich częściach.
Każdy wpis na liście prowadzi bezpośrednio do właściwego slajdu, co znacznie ułatwia powtórki i szybkie dotarcie do wybranego zagadnienia. Odnośniki działają także w drugą stronę, bo nawigację można prowadzić zarówno z menu, jak i z poziomu spisu treści. Warto korzystać z tych odnośników podczas samodzielnej nauki, zamiast przewijać całą prezentację w poszukiwaniu jednego omawiania.
Ostatnie dwa punkty nie dotyczą konkretnej aplikacji, lecz ogólnej metody pracy, dlatego traktujemy je jako wskazówki do dalszych ćwiczeń. Podsumowanie porządkuje natomiast całą wiedzę i przygotowuje grunt pod czwartą prezentację cyklu. Na tym etapie student powinien już samodzielnie przewidywać, jakie komponenty i bloki będą potrzebne w kolejnych przykładach.
Cele wiedzowe W1-W4 opisują konkretne umiejętności techniczne, które można sprawdzić wprost w środowisku AI2. Ich wspólnym mianownikiem jest samodzielne wykonanie aplikacji, a nie tylko zapamiętanie nazw komponentów i bloków. Dlatego podczas ćwiczeń tak ważne jest odtwarzanie każdego przykładu własnymi rękami, a nie tylko obserwacja prowadzącego.
Cel kompetencyjny K1 wykracza poza odtwórstwo, bo wymaga modyfikacji istniejącego programu i uzasadnienia wprowadzonych zmian. Taka forma pracy rozwija krytyczne myślenie i przygotowuje do dalszych etapów kursu, w których student będzie tworzył własne projekty. Ocena tego celu opiera się na jakości uzasadnienia, a nie wyłącznie na tym, czy aplikacja w ogóle działa.
Lista celów jest jednocześnie prostą listą kontrolną umożliwiającą samodzielną weryfikację postępów. Przed rozpoczęciem kolejnej prezentacji warto wrócić do tego slajdu i uczciwie zaznaczyć, które umiejętności zostały już opanowane. Dzięki temu braki są widoczne od razu, zanim staną się przeszkodą w trudniejszych zadaniach.
Podobny schemat pracy nad przykładem pomaga zachować porządek i skupić uwagę na aplikacji. Student poznaje kolejność myślenia: najpierw cel, potem elementy składowe, następnie ich ustawienia i wreszcie zachowanie. Taka sekwencja odpowiada naturalnemu tokowi pracy programisty, który najpierw zastanawia się, co ma powstać.
Kroki od celu do logiki bloków tworzą logiczny łańcuch, w którym każdy etap wynika z poprzedniego. Testowanie pokazuje, czy decyzje podjęte wcześniej były trafne, a rozszerzenia uczą myślenia o przyszłości projektu. Nie każdy przykład ma osobny slajd testowy, ale przy każdym warto sprawdzić działanie na telefonie lub emulatorze, bo tam najczęściej ujawniają się pomyłki.
Podobny schemat sprawdza się również jako algorytm samodzielnej pracy nad własnym pomysłem. Student, który opanuje te kroki, potrafi uporządkować nawet całkiem nowe, nieznane zadanie. Ten nawyk przekłada się na umiejętność planowania większych projektów w późniejszych prezentacjach.
Aplikacja Powitanie ilustruje najprostszy możliwy dialog między użytkownikiem a programem, w którym dane przepływają tylko w jedną stronę. Taki mini-trening pierwszej interakcji jest niezbędny, zanim przejdziemy do zadań zbierających tekst od użytkownika. Bez zrozumienia tego mechanizmu trudno przejść do bardziej złożonych programów.
Kluczowe jest tu rozróżnienie dwóch stron aplikacji: wyglądu tworzonego w Designerze oraz zachowania programowanego w Blocks. Komponenty Button i Label stanowią na razie tylko szkielet, który dopiero bloki ożywiają. Zdarzenie Click jest natomiast sygnałem, na który program ma zareagować określoną czynnością.
Choć przykład jest trywialny, wprowadza trzy pojęcia, które powrócą we wszystkich następnych aplikacjach. Właściwość Text przechowuje aktualną zawartość komponentu, zdarzenie informuje o fakcie kliknięcia, a metoda wykonuje zadaną operację. Gruntowne zapamiętanie tej trójki pojęć zwróci się przy każdym kolejnym slajdzie.
Budowa interfejsu przebiega wyłącznie w oknie Designer, gdzie komponenty są przeciągane z palety do podglądu ekranu. Przy tak prostym przykładzie wystarczą dwa widoczne komponenty i tylko tyle powinno znaleźć się na ekranie. Dodanie zbędnych elementów na tym etapie zaciemniłoby obraz tego, co dzieje się w programie.
Właściwość Text przycisku jest zmieniana w panelu właściwości, a nie pisana w kodzie, co dobrze pokazuje różnicę między projektowaniem a programowaniem. Etykieta pozostaje początkowo pusta, bo jej zawartość ma się pojawić dopiero po kliknięciu. Zwiększenie czcionki to z kolei zabieg czysto ergonomiczny, ułatwiający dostrzeżenie efektu.
Świadome pozostawienie domyślnych nazw Button1 i Label1 ma cel dydaktyczny i nie jest oznaką złego stylu. W małych programach takie nazwy nie wnoszą nieporozumień, natomiast w dużych projektach utrudnią orientację. Zasada, którą należy zapamiętać, brzmi: nazwy wybiera się tak, aby jednoznacznie opisywały rolę komponentu.
Logika bloków pokazuje, czym w projektowaniu wizualnym jest programowanie reakcji na zdarzenie. Blok wywołania zdarzenia pełni rolę swoistego kontenera, wewnątrz którego układamy wszystkie akcje. Bez tego kontenera pozostałe bloki nie mają kontekstu, w którym mogłyby się wykonać.
Blok ustawiający tekst etykiety jest przykładem przypisania wartości do właściwości komponentu. Wartość tekstu można wpisać bezpośrednio, ale w praktyce coraz częściej będzie to wynik innych bloków. Złączenie obu bloków tworzy kompletny program składający się z dwóch elementów.
Opisywanie logiki słownie to natomiast cenny nawyk, który zmusza do precyzyjnego nazywania zdarzeń i akcji. Formuła KIEDY i USTAW pozwala przetłumaczyć dowolny program blokowy na zrozumiałe zdanie po polsku. Ćwiczenie takiego tłumaczenia ułatwia potem czytanie cudzych programów i rozmowę o własnym kodzie.
Testowanie w App Inventor opiera się na połączeniu projektu z urządzeniem, które odbywa się przez aplikację Companion lub emulator. Komunikacja ta działa w czasie rzeczywistym, dzięki czemu zmiany w blokach zwykle aktualizują się na telefonie bez ręcznego przeładowywania aplikacji; niektóre zmiany mogą jednak wymagać ponownego uruchomienia lub połączenia. Taki tryb pracy skraca cykl poprawiania z minut lub godzin do kilku sekund.
W wariancie Wi‑Fi komputer i telefon muszą znajdować się w tej samej sieci; dostępne są też inne sposoby połączenia (np. USB, kod parowania) zależne od wersji środowiska i urządzenia. Dlatego przed zajęciami warto sprawdzić dostępność sieci oraz wersję zainstalowanej aplikacji Companion. Gdy połączenie zawodzi, pomocny bywa emulator, choć w niektórych przypadkach zachowuje się inaczej niż fizyczny telefon.
Testowanie po każdej zmianie to podstawowa zasada pracy z AI2, która chroni przed piętrzeniem się błędów. Drobna modyfikacja jest o wiele łatwiejsza do cofnięcia niż duża przebudowa wykonana jednym ruchem. Ten nawyk szybkich pętli prób i poprawek jest wiernym odzwierciedleniem pracy zawodowych programistów.
Pierwsza propozycja rozbudowy dodaje pole tekstowe, dzięki któremu aplikacja przestaje być programem pokazowym i zaczyna przyjmować prawdziwe dane. Wpisane imię jest przechowywane we właściwości Text pola i może być odczytane w dowolnym momencie. To naturalny krok w stronę spersonalizowanych aplikacji, które dobierają komunikat do użytkownika.
Dodanie drugiego przycisku, który czyści etykietę, uczy projektowania zadań odwzorowujących codzienne czynności. Zmiana koloru tła natomiast zwraca uwagę na to, że właściwości graficzne można modelować w czasie działania programu. Te drobne modyfikacje nie wymagają nowych pojęć, a znacząco wzbogacają sposób odbioru aplikacji.
Wariant z komunikatorem Notifier stanowi alternatywę dla stałej etykiety, przydatną, gdy komunikat ma być chwilowy. Warto przy tym pamiętać o zachowaniu równowagi między formą a treścią, aby atrakcyjna grafika nie przesłoniła logiki programu. Każde rozszerzenie jest okazją do przemyślenia, czy wybrane rozwiązanie naprawdę służy użytkownikowi.
Blok join należy do grupy bloków tekstowych i pełni funkcję zlepiania dwóch lub większej liczby fragmentów w jeden wspólny napis. Dzięki rozsuwanemu otworowi można do niego doczepić kolejne sloty, przez co sprawdza się także przy łączeniu większej liczby elementów. Jest to jedna z najczęściej używanych konstrukcji w całym środowisku.
Łącząc tekst stały z zawartością pola, tworzymy komunikat, którego nie dało się przewidzieć na etapie projektowania. Odczyt tekstu następuje przez wpięcie bloku zwracającego właściwość Text bezpośrednio do jednego ze slotów join. Dzięki temu program buduje napis dopiero w momencie kliknięcia, a nie wcześniej.
Zwrócenie uwagi na spacje jest ważną lekcją precyzji, ponieważ w napisie Witaj Anna po imieniu nie może pojawić się zbędny odstęp. Poprawny szablon powinien zawierać spację po słowie Witaj, co łatwo przeoczyć w pośpiechu. Takie drobne szczegóły uczą zwracania uwagi na dokładną postać tworzonego tekstu.
Wniosek o parze zdarzenie-akcja jest najważniejszym elementem całego przykładu i stanowi fundament programowania zdarzeniowego. W uproszczeniu aplikacja nie wykonuje sekwencji od początku do końca, lecz reaguje na sygnały wysyłane przez użytkownika. Właśnie ta cecha odróżnia programy mobilne od klasycznych skryptów uruchamianych w całości.
Możliwość zmiany właściwości z poziomu bloków pokazuje, że interfejs nie musi być statyczny i może ewoluować w trakcie działania. Odczyt danych z pól tekstowych jest z kolei podstawą każdego programu, który przyjmuje dane od człowieka. Połączenie tych dwóch możliwości daje w praktyce nieograniczone pole do tworzenia interaktywnych ekranów.
Blok join oraz testowanie w czasie rzeczywistym dopełniają obraz tego, jak w praktyce wygląda praca z AI2. Szybka weryfikacja pomysłów na prawdziwym sprzęcie sprawia, że nauka staje się bardziej angażująca. Student, który zrozumiał i odtworzył ten przykład, ma solidną bazę pod wszystkie kolejne aplikacje.
Kalkulator jest pierwszym przykładem realizującym pełny schemat wejście-przetwarzanie-wyjście, charakterystyczny dla programów przetwarzających dane. Wartości wprowadzane przez użytkownika są przetwarzane zgodnie z regułą i dopiero potem prezentowane jako wynik. Ten sam schemat powróci w tabliczce mnożenia, quizie i wielu innych aplikacjach.
Ważną lekcją jest rozróżnienie między tekstem, który zapamiętuje pole wprowadzania, a liczbą, na której można wykonywać działania. Bez świadomości tej różnicy student często nie rozumie, dlaczego program mimo poprawnych bloków nie liczy dobrze. AI2 automatycznie rozpoznaje tekst przypominający liczbę w działaniach arytmetycznych, ale pusty tekst albo niedozwolone znaki zwykle kończą się błędem wykonania; dlatego przed działaniem warto sprawdzać puste pole.
Wybrane komponenty, czyli dwa pola liczbowe, przycisk i etykieta wyniku, w zupełności wystarczą do realizacji celu. Dodanie elementu wyboru działania od razu porządkuje fakt, że jeden wspólny interfejs potrafi obsłużyć cztery różne operacje. Taka rozbudowa prowadzi naturalnie do wprowadzenia zmiennych i warunków.
Ustawienie właściwości NumbersOnly jest prostym, a zarazem skutecznym zabezpieczeniem przed błędami typograficznymi ze strony użytkownika. Pole ułatwia wprowadzanie liczb, ale nie gwarantuje znaku minus ani separatora dziesiętnego (zależy od urządzenia). Należy jednak pamiętać, że właściwość ta dotyczy wyłącznie znaków wprowadzanych z klawiatury, a nie przyszłej interpretacji wartości. Przed dalszym przetwarzaniem trzeba jawnie sprawdzić, czy pole zawiera poprawną liczbę.
Etykieta początkowa wyniku powinna mieć czytelny stan spoczynkowy, na przykład zero, aby użytkownik wiedział, gdzie odczytać rezultat. Podpisy przy polach znacznie ułatwiają obsługę, a w projekcie dydaktycznym pomagają też opisać, które pole jest pierwsze. Układ pionowy porządkuje elementy na ekranie i pomaga zachować czytelny układ na różnych ekranach.
Komponent układu, taki jak kontener pionowy lub poziomy, pełni rolę porządkowania widoków na ekranie. Warto od początku przyzwyczajać się do używania układów, bo bez nich elementy mogą być trudniejsze do kontrolowania. Dobrze zaplanowana struktura ekranu to połowa sukcesu każdej aplikacji mobilnej.
Program kalkulatora składa się w praktyce z trzech etapów: odczytu wartości, wykonania działania oraz zapisania wyniku. Odczyt polega na pobraniu właściwości Text z obu pól, natomiast dodawanie wykonuje dedykowany blok matematyczny. Uzyskany rezultat trzeba jeszcze umieścić w etykiecie, aby użytkownik mógł go zobaczyć.
Zmienna pełni rolę trwałego pojemnika na wartość, która może być potrzebna więcej niż raz w dalszej części programu. W tym przykładzie przechowuje ona wynik działania, ale w kolejnych aplikacjach będzie też służyć do liczników i stanów. Rozróżnienie między zmienną globalną a lokalną zależy od zakresu, w jakim wartość ma być dostępna.
Świadomość konwersji typów jest cenną umiejętnością; AI2 zamienia tekst przypominający liczbę na liczbę automatycznie w wyrażeniach matematycznych, ale pusty tekst albo niedozwolone znaki zatrzymują obliczenie błędem wykonania. Gdy w przyszłości pojawi się wyrażenie złożone, warto wcześniej zwalidować każdy składnik. Dobrym nawykiem jest też nadawanie zmiennym nazw jednoznacznie wskazujących na przechowywaną wartość.
Walidacja danych wejściowych to zbiór technik sprawdzających, czy informacja podana przez użytkownika nadaje się do dalszego przetwarzania. W najprostszej postaci sprowadza się do pytania, czy pole nie jest puste, zanim odczytamy z niego wartość. Dzięki temu program nie powinien próbować obliczyć wynik na podstawie niepełnych danych.
Warunek if działa jak rozgałęzienie w toku programu: gdy warunek jest spełniony, wykonywana jest jedna ścieżka, a w przeciwnym wypadku druga. Niezależnie od wybranej ścieżki całe zdarzenie kończy się w sposób kontrolowany, unikniemy typowego błędu wykonania. Komunikat Notifier daje użytkownikowi zrozumiałą informację, co zrobić dalej.
Obsługa błędów nie jest ozdobą, lecz obowiązkowym elementem poprawnie napisanego programu. Puste pole to tylko jeden z możliwych przypadków błędnych danych, które w dalszej części kursu będą rozszerzane o kolejne. Nawyk sprawdzania danych przed ich użyciem to jedna z cech przyszłego profesjonalnego programisty.
ListPicker pozwala użytkownikowi wybrać jedną opcję z gotowej, z góry zdefiniowanej listy, co eliminuje błędy ręcznego wpisywania. Tego typu komponenty są wszechobecne w prawdziwych aplikacjach mobilnych, bo ograniczają użytkownika do zatwierdzonych wartości. W tym przykładzie lista czterech działań w pełni wystarcza do zademonstrowania tej techniki.
Krytyczne znaczenie ma zapamiętanie wyboru w zmiennej, zanim zostanie on wykorzystany do obliczeń. Zdarzenie AfterPicking informuje program o dokonanym wyborze i to wewnątrz niego należy ustawić zmienną. Gdy przyjdzie czas na obliczenia, warunki sprawdzają wartość tej zmiennej i uruchamiają właściwą gałąź.
Rozbudowa listy działań wymaga jedynie dodania opcji oraz nowego warunku, co dobrze pokazuje skalowalność takiego rozwiązania. Miejsce w kodzie, w którym podejmowana jest decyzja, staje się jedynym punktem zarządzania zachowaniem aplikacji. Ta centralizacja logiki jest zdecydowanie lepsza niż budowanie czterech osobnych przycisków.
Dzielenie przez zero nie ma wyniku w matematyce. W typowych operacjach matematycznych AI2 zwraca wartość Infinity lub NaN; dalsze użycie tej wartości może spowodować błąd wykonania. Taka sytuacja jest typowym przykładem przypadku brzegowego, którego nie da się wykryć na podstawie wyglądu ekranu. Projektant aplikacji musi zatem przewidzieć ten scenariusz i obsłużyć go w kodzie.
Warunek sprawdzający, czy dzielnik jest równy zero, działa jak zabezpieczenie umieszczone tuż przed samym działaniem. Zamiast dzielenia program wyświetla wtedy czytelny komunikat, dzięki czemu sesja użytkownika nie zostaje przerwana. Ta prosta ochrona jest pierwszym przykładem myślenia o odporności oprogramowania.
Rozważanie przypadków brzegowych to umiejętność, która odróżnia szkic aplikacji od jej solidnej wersji. Zanim program trafi do rąk użytkownika, warto sporządzić krótki spis skrajnych sytuacji i sprawdzić je wszystkie. Nawyk takiego planowania testów procentuje w każdej kolejnej, nawet znacznie większej aplikacji.
Przycisk czyszczenia porządkuje interfejs i daje użytkownikowi kontrolę nad stanem po zakończonym obliczeniu. Obsługa liczb ujemnych i dziesiętnych wymaga natomiast przemyślenia walidacji oraz formatu wyświetlanego wyniku. Każde takie rozszerzenie wymaga powrotu do testowania, co podkreśla cykliczność pracy.
Zapis historii obliczeń w TinyDB wprowadza pierwsze dane trwałe, które nie znikają po zamknięciu aplikacji (w wersji zainstalowanej na urządzeniu; odinstalowanie aplikacji usuwa zapisane dane). Komponent ten służy do zapisywania prostych par klucz-wartość i świetnie sprawdza się przy najróżniejszych wynikach i ustawieniach. Dzięki niemu student uczy się, że dane mogą żyć dłużej niż pojedyncze uruchomienie.
Wniosek o zmiennych i warunkach zamyka cały temat kalkulatora w dwóch pojęciach, które będą użyteczne wszędzie. Od tego momentu student powinien traktować zmienne jako naturalny element każdego większego programu. Budowa klawiatury z przycisków to z kolei inspiracja do tworzenia własnych, nietypowych interfejsów.
Aplikacja do zmiany kolorów pokazuje, że wygląd ekranu nie musi być ustalony raz na zawsze w Designerze. Właściwości graficzne, takie jak kolor tła, można modyfikować w trakcie działania programu, reagując na działania użytkownika. To otwiera drogę do personalizacji, motywów i wizualnej informacji zwrotnej.
Mechanizm pozostaje dokładnie taki sam jak w powitaniu: zdarzenie kliknięcia uruchamia przypisanie nowej wartości do wybranej właściwości. Różnica polega jedynie na tym, że tym razem modyfikowana jest cecha wizualna, a nie tekst. Dzięki temu student powtarza schemat i jednocześnie widzi jego nowe zastosowanie.
Ta aplikacja jest też dobrą okazją do poznania palety kolorów oraz możliwości budowania własnych wartości RGB. W dalszej części kursu losowy dobór kolorów zostanie wykorzystany w grach do podkreślania stanów i zdarzeń. Traktowanie koloru jako zwykłej wartości to ważne przejście od projektowania do programowania.
Trzy przyciski o kolorach zgodnych z nazwą tworzą interfejs, który komunikuje swoje przeznaczenie bez dodatkowych opisów. Użytkownik od razu wie, który przycisk da zamierzony efekt, co ułatwia testowanie i obsługę. Ta prosta zasada, znana jako dopasowanie sygnału do znaczenia, jest szeroko stosowana w projektowaniu mobilnym.
Wyśrodkowanie komponentów porządkuje kompozycję i ułatwia odczytanie wszystkich opcji za jednym razem. Etykieta informująca o aktualnym kolorze pełni rolę czytelnego pola stanu, dzięki któremu aplikacja potrafi komunikować się z użytkownikiem. Takie małe elementy w istotny sposób podnoszą jakość aplikacji.
Prosty interfejs nie oznacza jednak prostego myślenia, bo każdy z przycisków jest osobnym komponentem z własnym zdarzeniem. Struktura ekranu przekształca się w mini-sieć powiązań wizualnych i logicznych. Jej opanowanie przygotowuje studenta do projektowania bardziej złożonych układów w kolejnych aplikacjach.
Dla każdego przycisku powstaje osobne zdarzenie, które wykonuje akcję zmieniającą kolor tła ekranu. Mimo że bloki w poszczególnych zdarzeniach wyglądają niemal identycznie, każdy wstawia inną wartość koloru. To dobry moment, by zauważyć, że kolor wybiera się z gotowej palety sekcji Colors.
Możliwość zmiany koloru etykiety pokazuje, że ta sama właściwość występuje w wielu komponentach wizualnych. W praktyce oznacza to, że raz nauczonego wzorca nie trzeba uczyć się drugi raz dla każdego elementu. Wykorzystanie tej samej właściwości do kilku celów to cecha dojrzałego i elastycznego programu.
Charakterystyczny dla tego slajdu jest fakt, że kod nie wymaga żadnych zmiennych ani warunków, a mimo to wykonuje realną pracę. Cała logika sprowadza się do trzech niezależnych reakcji na kliknięcia. Myślenie o aplikacji jako o zbiorze reakcji jest naturalnym krokiem w programowaniu zdarzeniowym.
Zastąpienie trzech przycisków jednym ListPickerem pokazuje, jak można zmniejszyć liczbę opcji bez utraty funkcji. Właściwość Elements zawiera listę wyborów, spośród których użytkownik wybiera jedną pozycję. To rozwiązanie świetnie sprawdza się wtedy, gdy opcji jest więcej, a ekran zaczyna być zatłoczony.
Zdarzenie AfterPicking uruchamia się po zamknięciu listy i dokonaniu wyboru, dając programowi dostęp do wskazanej wartości. Odczytanie tej wartości odbywa się przez właściwość Selection, która przechowuje ostatnio wybrany element. Dzięki temu jeden blok zastępuje bezpośrednio trzy osobne zdarzenia kliknięcia.
Krótszy kod nie oznacza, że jest on mniej funkcjonalny, lecz właśnie łatwiejszy do rozbudowy i utrzymania. Dodanie nowego koloru to dopisanie pozycji na liście oraz jednej gałęzi bloku if then else, zamiast tworzenia nowego przycisku. Ta zaleta decyduje o tym, że twórcy aplikacji chętnie sięgają po komponenty wyboru w prawdziwych projektach.
Losowanie liczby za pomocą bloku random integer tworzy nieprzewidywalną wartość, która za każdym kliknięciem może być inna. W połączeniu z listą kolorów liczba ta staje się indeksem, czyli numerem wskazującym konkretny element listy. W ten sposób jedna zmienna steruje wyborem koloru, co jest eleganckim wzorcem.
Blok select list item pobiera z listy element o podanym numerze, podobnie jak odczytuje się komórkę w tabeli. Przygotowana lista powinna mieć dokładnie tyle elementów, ile wynosi górny zakres losowania, aby uniknąć odwołania do nieistniejącej pozycji. Zachowanie spójności między zakresem losowania a długością listy jest kluczowe dla poprawności.
Losowość zastosowana w ten sposób jest w rzeczywistości kontrolowana, bo wynik zawsze pozostaje w zbiorze przygotowanych kolorów. Ten sam mechanizm sprawdzi się w grach przy losowaniu wartości z określonego zakresu. Dzięki temu prostemu ćwiczeniu student poznaje wzorzec, na którym opiera się wiele aplikacji edukacyjnych i rozrywkowych.
Dynamiczna zmiana właściwości z bloków to umiejętność o bardzo szerokim zastosowaniu, wykraczająca poza kolory. Ta sama technika posłuży później do przełączania ekranów, widoczności elementów i wielu innych aspektów. Wiele aplikacji, które reagują na użytkownika zmianą wyglądu, korzysta z tego wzorca.
Listy uczą grupować dane w jedną strukturę, dzięki czemu zamiast wielu zmiennych trzymamy jeden uporządkowany zbiór. Odczytanie wybranej wartości przez właściwość Selection pokazuje, skąd pochodzi dana do dalszych kroków. Te dwa mechanizmy, lista i wybór, będą towarzyszyć studentowi w wielu projektach.
Wprowadzenie losowości przygotowuje grunt pod gry i quizy, gdzie nieprzewidywalność bywa pożądana. Zamiast szczegółowego kodowania każdej sytuacji, program polega na losowym wyborze z przygotowanej puli. Tak zaprojektowane aplikacje mogą być krótsze i łatwiejsze do rozbudowy o kolejne elementy.
Syntezator mowy przenosi aplikację z płaszczyzny wizualnej w stronę zmysłu słuchu, co znacząco rozszerza możliwość komunikacji. Komponenty z grupy Media udostępniają wygodny interfejs do dźwięku, obrazu i właśnie mowy. W praktyce oznacza to, że telefon potrafi przeczytać tekst na głos bez żadnych zewnętrznych bibliotek.
Metoda Speak przyjmuje tekst jako argument i zamienia go na wypowiedź głosową, korzystając z zainstalowanego w systemie silnika mowy. Parametry takie jak język i tempo pozwalają przystosować syntezator do potrzeb użytkownika. Dzięki temu ta sama aplikacja może służyć do nauki języków obcych albo pomocy osobom słabowidzącym.
Ważna wskazówka płynie z doświadczenia z emulatorem, w którym syntezator bywa zawodny i nie mówi po polsku. Dlatego ten przykład najlepiej testować na prawdziwym smartfonie z zainstalowanym odpowiednim głosem. Wspomniany wniosek jest także lekcją krytycznego podejścia do narzędzi testowych.
Komponenty niewidoczne, takie jak TextToSpeech, nie pojawiają się na ekranie urządzenia, choć w pełni działają w tle. Ich ustawienia konfiguruje się tak samo jak widocznych komponentów, w panelu właściwości albo z poziomu bloków. Ta cecha uwidacznia ważne rozróżnienie między elementami widoku a logiką aplikacji.
Ustawienie języka i kraju od razu na etapie projektowania oszczędza pracy, bo wypowiedź od pierwszego uruchomienia brzmi poprawnie. Język polski wymaga podania odpowiedniego kodu i wariantu, które w niektórych telefonach nie są dostępne bez dodatkowych pakietów. Wartość tych właściwości można zmienić w każdej chwili również w oknie Blocks.
Odpowiedni rozmiar czcionki pola tekstowego poprawia komfort wpisywania, zwłaszcza na ekranach o różnej gęstości pikseli. Podpowiedź umieszczona w polu naprowadza użytkownika, co ma wpisać, bez długich instrukcji. Takie drobne zabiegi ergonomiczne składają się na jakość odczuwalną przy codziennym użytkowaniu.
Wywołanie metody w blokach przypomina funkcję z klasycznych języków: ma nazwę, przyjmuje argumenty i wykonuje zadanie. Argumentem metody Speak jest tekst odczytany z pola, który program przekazuje syntezatorowi. Wypowiedź zwykle rozpoczyna się po krótkim czasie, ale opóźnienie zależy od urządzenia i silnika mowy.
Przed samą wypowiedzią program może jeszcze dostroić parametry głosu, ustawiając język i tempo za pomocą bloków. Taka dynamiczna konfiguracja pozwala na przykład przełączyć syntezator na inny język po wyborze użytkownika. Dzięki temu zachowaniem aplikacji steruje się w jednym, spójnym miejscu.
Układ bloków pozostaje bliski temu poznanemu wcześniej, co pokazuje, że za każdym razem powtarza się ten sam wzorzec zdarzeniowy. Podobieństwo wzorców pozwala szybko interpretować nowe komponenty przez analogię. Utrwalenie schematu wywołania metody przyspiesza pracę z kolejnymi elementami środowiska.
Właściwości syntezatora mowy odpowiadają za naturalność i zrozumiałość wypowiedzi, dlatego warto poznać ich znaczenie. Język określa sposób wymowy, a kraj uściśla wariant lokalny. Użycie właściwych wartości ma szczególne znaczenie przy tekście z polskimi znakami diakrytycznymi.
Wysokość oraz tempo wypowiedzi pozwalają modelować charakter komunikatu, na przykład wolne tempo dla dzieci i uczniów. Parametry te są wyrażane wartościami liczbowymi, które można też zmieniać w trakcie działania programu. Ta elastyczność sprawia, że syntezator staje się wszechstronnym narzędziem komunikacyjnym.
Metoda Stop przerywa bieżącą wypowiedź, co bywa przydatne, gdy użytkownik zmienia zdanie albo przewija treść. Zarządzanie takimi przejściami jest ważne w architekturze aplikacji obsługujących dźwięk. Znajomość pełnego zestawu właściwości i metod pozwala projektować zachowania, a nie tylko wywoływać pojedyncze funkcje.
Rozbudowa o wybór języka i wariantu regionalnego przez listy wyboru łączy syntezator z wiedzą o komponencie ListPicker. Użytkownik może wtedy przełączać język w samej aplikacji, co doskonale nadaje się do nauki słówek. Taka funkcja wyróżnia aplikację i czyni ją rzeczywiście użyteczną w praktyce.
Połączenie syntezatora z losowaniem otwiera drogę do aplikacji powtarzających losowo wybrane słówka do nauki. Wariant do nauki języków naturalnie łączy mowę z ćwiczeniami, tworząc prosty system edukacyjny. Każde z tych rozszerzeń da się zrealizować przy pomocy zapamiętanych już pojęć.
Zapowiedziane rozpoznawanie mowy uzupełnia obraz komponentów Media o kierunek odwrotny, czyli zamianę mowy na tekst. W piątej prezentacji to podejście zostanie wykorzystane w praktycznych aplikacjach i grach. Wnioski tej sekcji podpowiadają, że dźwięk i mowa znacząco podnoszą atrakcyjność aplikacji mobilnych.
Symulacja rzutu kostką przenosi na grunt mobilny najprostszy mechanizm losowości używany w grach i decyzjach. Wartość od jednego do sześciu jest generowana w sposób nieprzewidywalny za każdym uruchomieniem. Tak rozumiana losowość stanowi fundament tysiąca różnych aplikacji rozrywkowych.
Do przedstawienia wyniku wystarczą przycisk, etykieta z liczbą oraz opcjonalnie obrazek ścianki kostki. Wybór między tekstem a grafiką jest dobrą okazją do przemyślenia sposobu komunikowania wyniku użytkownikowi. Dzięki tej decyzji student poznaje zależność między danymi a ich wizualizacją.
Ten przykład w naturalny sposób łączy się z poprzednią wiedzą: losowaniem kolorów, zmiennymi i blokiem join. Powtarzanie tych samych mechanizmów w nowej oprawie jest istotą dobrej dydaktyki. Utrwalone wzorce będą później podstawą przy budowie bardziej złożonych gier losowych.
Interfejs aplikacji pozostaje celowo minimalistyczny, bo jego zadaniem jest wyeksponowanie wyniku losowania. Obraz i etykieta są rozmieszczone na górze, a przycisk na dole, co tworzy naturalny porządek odczytywania. Taki układ sprawdza się zarówno na małych, jak i dużych ekranach smartfonów.
Przygotowanie sześciu obrazków w sekcji Media wymaga zwrócenia uwagi na ich rozmiar i proporcje, aby dobrze wyglądały na ekranie. Nazwy plików powinny być proste i przewidywalne, co w następnym kroku wykorzysta blokowa konstrukcja nazwy. Gotowe zasoby można wgrać raz i wielokrotnie odwoływać się do nich w blokach.
Użycie komponentu obrazu zamiast samego tekstu nadaje aplikacji charakter gry i mocniej angażuje użytkownika. Umieszczenie obrazu nad etykietą liczbową daje podwójną reprezentację tego samego wyniku. Tego rodzaju spójne interfejsy są przykładem dobrych praktyk w aplikacjach mobilnych.
Blok random integer z zakresem od jednego do sześciu generuje liczbę całkowitą, którą przypisujemy do zmiennej wyniku. Przypisanie do zmiennej oddziela moment losowania od momentu prezentacji wyniku. Dzięki temu ten sam wynik może posłużyć do ustawienia tekstu i obrazka bez ponownego losowania.
Ustawienie etykiety na wynik zamyka pierwszy etap, a opcjonalne ustawienie obrazka zamyka etap wizualny. W ten sposób jedna operacja steruje dwoma komponentami, co ilustruje wspólną rolę zmiennej. Dopiero skojarzenie tekstu i grafiki daje użytkownikowi pełny obraz wylosowanej wartości.
Uwaga na spójność zakresów dotyczy również warunków, w których zakres losowania musi być zgodny z liczbą przygotowanych wariantów. Taka dbałość o szczegóły chroni przed rzadkimi, ale przykrymi błędami w losowaniu. Za każdym razem warto przetestować kilkanaście losowań, aby wykryć nieprawidłowości.
Konstruowanie nazwy pliku za pomocą bloku join pozwala spiąć liczbę z wzorcem tekstowym i rozszerzeniem. Dla wyników od jednego do sześciu otrzymujemy nazwy kostka1.jpg, kostka2.jpg i tak dalej. Ta technika jest szczególnie cenna, gdy mamy do wykonania wiele podobnych nazw.
Żeby konstruowana nazwa zadziałała, każdy z plików musi istnieć w zasobach projektu, a pisownia musi być identyczna co do każdego znaku. Systemy plików bywają przy tym wrażliwe na wielkość liter i kodowanie. Dlatego obowiązuje zasada prostych nazw bez polskich znaków i spacji.
Wzorzec budowania nazw z wartości liczbowej spotkamy jeszcze wielokrotnie, między innymi przy odtwarzaniu dźwięków i miejsc w grach. Pozwala on programowi wykonać część pracy za twórcę, uwalniając go od ręcznego dopisywania każdego elementu. W ten sposób sterowanie danymi przechodzi z poziomu ręcznej konstrukcji do poziomu jawnego przetwarzania.
Zmienna globalna liczby rzutów pełni rolę akumulatora, czyli pojemnika, który zwiększa swoją wartość przy każdej akcji. Tego typu konstrukcja jest powszechna w statystykach, licznikach i punktacjach wszystkich aplikacji. Wzorzec ten student poznał już wcześniej i tutaj powtarza go w nowym kontekście.
Zwiększenie licznika o jeden sprowadza się do odczytania bieżącej wartości, dodania jedności i zapisania z powrotem. Wyświetlenie licznika w osobnej etykiecie czyni z tych wewnętrznych obliczeń widoczny dla użytkownika element. Taka widoczność ułatwia też wykrywanie błędów w trakcie testów.
Rozszerzenie o sumę oczek i średnią pokazuje, jak z jednego źródła danych można wyliczać kolejne użyteczne metryki. Student uczy się w ten sposób, że wartości pomocnicze da się wyprowadzić z już zebranych danych. Każda dodatkowa statystyka wzbogaca aplikację bez istotnych zmian w logice.
Generator liczb losowych okazuje się narzędziem o fundamentalnym znaczeniu dla całej grupy aplikacji rozrywkowych. Bez niego nie zbudujemy gry opartej na zdarzeniach losowych, animacji ani quizu z wymieszanymi pytaniami. Dlatego opanowanie tego bloku jest warunkiem dalszych sukcesów w kursie.
Połączenie wyniku losowania z obrazkami uczy modelowania spójnych i czytelnych komunikatów bez dodatkowej pracy ręcznej. Zmienne umożliwiają prowadzenie statystyk, które nadają tym losowym zdarzeniom wrażenie rzetelności. Blok join z kolei spina teksty i nazwy w jedno, co było już wielokrotnie podkreślane.
Metaforycznie rzecz ujmując, rzut kostką jest miniaturą każdej gry losowej, od loterii po gry fabularne. Mechanizm wygląda identycznie: wylosuj, zapisz, wyświetl, zaktualizuj stan. Z tego powodu studenci często wracają do tego przykładu przy budowie własnych gier.
Program do trenowania tabliczki mnożenia łączy losowanie zadań z automatyczną oceną odpowiedzi, tworząc miniaturowy system edukacyjny. Użytkownik wpisuje wynik działania, a aplikacja informuje, czy jest on prawidłowy. Taka forma nauki przez natychmiastową weryfikację jest skuteczna i przyjemna w odbiorze.
Mechanizm opiera się na prostych zmiennych: dwa czynniki stanowią zadanie, a ich iloczyn jest wzorcem odpowiedzi. Przechowywanie wzorca w zmiennej pozwala porównać go z danymi wpisanymi przez użytkownika. Dzięki temu rozdzielenie pytania i oceny jest w programie doskonale widoczne.
Punktacja i seria poprawnych odpowiedzi przenoszą trening w stronę gry z elementem rywalizacji. Zapowiedziana w czwartej prezentacji pełna wersja programu rozbuduje ten pomysł o dodatkowe funkcje. Już teraz jednak widać, jak z małego pomysłu można zbudować pełnowartościowe narzędzie edukacyjne.
Ekran treningu składa się z czytelnego układu, w którym pytanie, pole odpowiedzi i przyciski są od siebie wyraźnie oddzielone. Ustawienie pola odpowiedzi w trybie tylko liczb upraszcza weryfikację i przyspiesza pisanie na klawiaturze mobilnej. Dobra kompozycja przestrzeni sprawia, że użytkownik intuicyjnie wie, co ma zrobić.
Dwa przyciski mają różne role: jeden ocenia bieżącą odpowiedź, a drugi generuje nowe zadanie. Rozdzielenie tych funkcji zapobiega przypadkowemu pomieszaniu zadań i ocen. Zależności między przyciskami są przy tym naturalne i nie wymagają tłumaczenia tekstem.
Etykieta wyników zbiera punkty i informację zwrotną, dzięki czemu postęp użytkownika jest widoczny od razu. Czytelna czcionka i odpowiednie odstępy są szczególnie ważne przy aplikacji przeznaczonej dla dzieci. Każdy z tych drobnych elementów jest częścią spójnej strategii interfejsu.
Losowanie dwóch czynników z zakresu od jednego do dziesięciu tworzy zróżnicowane zadania, które można powtarzać w nieskończoność. Wartości trafiają do zmiennych przechowujących dane bieżącego pytania. Obliczenie ich iloczynu daje gotowy wzorzec do późniejszego porównania odpowiedzi.
Budowa treści pytania z fragmentów tekstu, liczb i symbolu mnożenia to kolejne zastosowanie bloku join. Tak skonstruowany napis staje się bezpośrednio treścią etykiety wyrażającą pytanie. Dzięki temu pytanie zawsze odzwierciedla aktualne wartości zmiennych, nawet po wielu zmianach.
Utrzymanie powiązanych wartości w zmiennych ułatwia późniejsze modyfikacje i testowanie. Wartości te pozostają spójne, bo powstają w jednym, wspólnym miejscu programu. Takie jednorodne źródło danych jest dobrym przykładem przejrzystej architektury małej aplikacji.
Warunek porównujący tekst wpisany przez użytkownika z zapamiętanym iloczynem jest sednem całego programu. W AI2 porównanie może zostać wykonane automatycznie z zamianą typu, ale świadome rozumienie tej operacji chroni przed pomyłkami. Poprawna odpowiedź wchodzi na ścieżkę gratulacji, a błędna na ścieżkę podpowiedzi.
Reakcje na dwie możliwe odpowiedzi są rozdzielone konstrukcją if, która podejmuje decyzję i wykonuje właściwy zbiór bloków. Użytkownik otrzymuje przy tym natychmiastową, czytelną informację o wyniku swojej odpowiedzi. Taki komunikat zwrotny jest niezbędnym elementem atrakcyjnego treningu.
Porównywanie liczb wpisanych jako tekst bywa źródłem subtelnych błędów, gdy w polu pojawią się spacje albo dodatkowe znaki. Zaleca się w związku z tym jak najwcześniejsze kontrolowanie czystości wprowadzanych danych. Dzięki temu porównanie dotyczy zawsze oczekiwanych wartości liczbowych.
Punktacja przekształca trening w grę, w której każda poprawna odpowiedź zwiększa liczbę zdobytych punktów. Seria natomiast premiuje ciąg bezbłędnych odpowiedzi, co dodatkowo motywuje do skupienia. Oba mechanizmy opierają się na tych samych umiejętnościach gromadzenia wartości.
Zerowanie serii przy błędnej odpowiedzi wymaga jawnego wyzerowania zmiennej w ścieżce porażki. Taka logika uczy rozgałęzień, w których każda ścieżka ma prawo modyfikować stan. Zasady gry są w ten sposób wyeksponowane w jednym miejscu kodu.
Po osiągnięciu progu dziesięciu punktów aplikacja potrafi pogratulować użytkownikowi, co dodaje radości osiągnięciom. Zapis rekordu w TinyDB pozwala zachować najlepszy wynik nawet po zamknięciu aplikacji. Ten krótki przegląd rozszerzeń pokazuje, jak niewielkim nakładem pracy uzyskuje się grywalną aplikację.
Przykład tabliczki mnożenia spina w jednym programie losowanie, pracę z tekstem i ocenę warunkową. Pokazany zestaw bloków stanowi gotowy szablon dla wszelkich gier edukacyjnych i quizów. Dzięki niemu student odtwarza wzorzec, który w czwartej prezentacji zostanie rozbudowany do pełnego programu.
Budowanie pytania z wielu składników za pomocą join oraz porównywanie odpowiedzi to umiejętności stale powracające w praktyce. Punktacja, jako praktyczne zastosowanie zmiennych, uczy zarządzania stanem aplikacji. Wszystkie te mechanizmy są już znane, a w zestawieniu dają coś zupełnie nowego.
Wartość tego przykładu tkwi w tym, że prostota układu nie ogranicza możliwości rozwoju. Gotowy wzorzec można rozbudowywać o nowe zakresy liczb, rodzaje działań czy dodatkową grafikę. Dzięki temu ćwiczenie stanowi źródło inspiracji przed trudniejszymi zadaniami w dalszej części kursu.
Quiz stanowi uniwersalny szkielet aplikacji, w którym pytania i odpowiedzi można wymienić na dowolną tematykę. Ta sama struktura obsłuży historię, biologię, języki obce czy wiedzę techniczną. Dzięki temu jedno opanowane rozwiązanie można przerabiać na niekończące się wersje tematyczne.
Podstawą działania są zbiory danych uporządkowane w listy pytań i odpowiedzi oraz zmienna indeksu. Indeks określa, które pytanie jest aktualnie wyświetlane, i steruje przejściem do następnego. Tak zaprojektowany przebieg quizu jest prosty w implementacji i łatwy do modyfikacji.
Zapis wyników w TinyDB nadaje aplikacji charakter prawdziwego produktu, pamiętającego osiągnięcia gracza. Quiz posiada również przejrzystą ścieżkę zakończenia oraz możliwość restartu po kolejnych próbach. Wszystkie dotychczas poznane pojęcia znajdują tu spójne, praktyczne zastosowanie.
Trzymanie pytań i odpowiedzi w dwóch równoległych listach pozwala działać na przejrzystych i łatwo rozszerzalnych danych. Pytanie i jego poprawna odpowiedź mają wtedy ten sam numer porządkowy w obu kolekcjach. Taka struktura ułatwia odczytywanie pary pytań bez osobnych instrukcji.
Zmienna indeksu pełni rolę wskaźnika bieżącej pozycji, dzięki któremu program wie, co ma wyświetlić. Wybranie pytania sprowadza się do odczytania elementu listy o tym właśnie numerze. Ta operacja odpowiada indeksowaniu tablic znanemu z klasycznych języków programowania.
Listy mogą być dowolnie długie, a dodanie nowego pytania nie zmienia wcale reguł działania. Jedynym warunkiem pozostaje synchronizacja list, aby liczba pytań zgadzała się z liczbą odpowiedzi. Taka skalowalność jest główną zaletą przechowywania treści z daleka od logiki programu.
Sterowanie quizem odbywa się przede wszystkim przez przyrosty zmiennej indeksu po każdej ocenionej odpowiedzi. Po każdym przyroście program pobiera następne pytanie i ponownie prezentuje je użytkownikowi. Taki cykl powtarza się aż do wyczerpania wszystkich pozycji listy.
Warunek zakończenia porównuje aktualny indeks z długością listy, co daje przejrzysty moment zatrzymania. W chwili przekroczenia listy aplikacja pokazuje podsumowanie punktów i liczbę pytań. Bardzo istotne jest, aby długość listy odczytywać właściwym blokiem przeznaczonym do tego celu.
Przycisk restartu przywraca stan początkowy: zeruje indeks, zeruje punkty i znów pokazuje pierwsze pytanie. Dobre zaprojektowanie restartu sprawia, że quiz nadaje się do wielokrotnych prób bez ponownego uruchamiania. W ten sposób aplikacja staje się elastyczna i przyjazna w codziennym użytkowaniu.
Ocenę rozpoczyna pobranie odpowiedzi użytkownika, najczęściej z pola tekstowego albo wyboru listy. Następnie program porównuje tę odpowiedź z poprawną wartością przechowywaną w liście. Wynik porównania decyduje o wyświetleniu komunikatu dobrego albo błędnego wyniku.
Porównywanie tekstów jest wrażliwe na wielkość liter, więc odpowiedź Warszawa i warszawa mogą zostać uznane za różne. Normalizacja za pomocą bloków zmieniających na małe litery usuwa ten problem przed porównaniem. Taka operacja jest częstą praktyką w programach obsługujących tekst od użytkownika.
Podanie prawidłowej odpowiedzi po błędnym strzale pełni funkcję edukacyjną i wzmacnia zapamiętywanie. Dzięki niej quiz nie tylko sprawdza wiedzę, ale również jej uczy. Połączenie oceny i wskazówki dydaktycznej jest szczególnie cenione w aplikacjach szkolnych.
Podsumowanie quizu może przyjąć formę osobnego ekranu albo etykiety ze zbiorczym komunikatem na tym samym widoku. Procent poprawnych odpowiedzi daje graczowi jednoznaczną miarę postępów. Taki zbiorczy wynik jest bardziej wartościowy niż surowe zliczenie punktów.
Słowny komentarz zależny od przedziału procentowego potrafi zmotywować i podpowiedzieć, co zrobić dalej. Cała logika opiera się na łańcuchu warunków porównujących wynik z kolejnymi progami. Dzięki temu aplikacja reaguje różnie na bardzo dobre, dobre i słabe wyniki.
Zapis najlepszego wyniku w TinyDB pozwala porównywać kolejne podejścia i motywuje do poprawy. Przycisk powrotu i restartu utrzymuje quiz w stanie gotowym do następnej rundy. Podsumowanie to moment, w którym aplikacja w pełni realizuje swój cel edukacyjno-rozrywkowy.
Quiz łączy umiejętności, które student zdobywał osobno w poprzednich przykładach, w jedną spójną całość. Listy dostarczają treści, indeks steruje nawigacją, a warunki oceniają odpowiedzi. Tym samym komplet pojęć tworzy gotowe do użycia rozwiązanie.
Zapis wyników w TinyDB domyka kwestię trwałości danych, dzięki czemu osiągnięcia nie przepadają po zamknięciu aplikacji. Umiejętność takiego przechowywania danych jest cenna w każdej aplikacji z elementem postępu. Student, który opanował tę sekcję, potrafi zbudować własny układ pytań.
Gotowy szkielet quizu jest otwarty na modyfikacje i dalszy rozwój. Wystarczy podmienić listy treści, aby powstała zupełnie nowa gra edukacyjna. Ten przykład kończy serię ośmiu wzorców i pozostaje jednym z najczęściej rozwijanych przez studentów.
Zegar i stoper pokazują, jak dzięki jednemu komponentowi czasu aplikacja może wykonywać pracę nawet bez działania użytkownika. Komponent Clock udostępnia zdarzenie cykliczne, które domyślnie wywoływane jest z wybraną częstotliwością. Dzięki temu możliwa jest animacja, odliczanie i pomiar upływającego czasu.
Wyświetlanie aktualnego czasu wymaga jedynie odczytania metod zwracających godzinę, minutę i sekundę. Stopery natomiast bazują na zliczaniu impulsów zdarzenia, czyli zwykle co sekundę. Ta druga technika wymaga odrobiny logiki, która decyduje, czy liczyć dalej, czy wstrzymać działanie.
Czas wyrażany jest w milisekundach, co dla człowieka jest mało naturalne, ale za to bardzo precyzyjne dla komputera. W praktyce student najczęściej wykorzystuje gotowe metody zamieniające ukryte wartości na czytelne teksty. Zrozumienie tej podstawy przydaje się także przy przechowywaniu znaczników czasu.
Ustawienie interwału na tysiąc milisekund sprawia, że zdarzenie Timer wykonuje się dokładnie raz na sekundę. Każde takie powtórzenie odświeża wyświetlaną na ekranie godzinę, minutę i sekundę. W ten sposób nawet pojedynczy komponent i kilka bloków tworzą pełnoprawny, działający zegar.
Metody zwracające elementy czasu działają na źródle systemowym, więc zawsze pokazują rzeczywisty stan. Złożenie godzin, minut i sekund w jeden napis przy użyciu join daje format czytelny dla człowieka. Bez takiego zestawienia otrzymywalibyśmy jedynie nieprzejrzyste wartości liczbowe.
Dokładanie zera wiodącego przy wartościach jednocyfrowych wymaga prostego warunku lub dodatkowego przetwarzania. Dzięki temu zegar wygląda naturalnie i nie zmienia długości w zależności od pory dnia. Taka obróbka tekstu jest dobrą wprawką w formatowaniu danych wyjściowych.
Stoper opiera się na liczniku, który jest zwiększany przy każdym impulsie zegara. Flaga logiczna pełni rolę wyłącznika, decydującego, czy licznik ma rosnąć, czy stać w miejscu. Dzięki niej ten sam blok zdarzenia obsługuje zarówno fazę pomiaru, jak i fazę zatrzymania.
Rozpoczęcie pomiaru zeruje licznik i ustawia flagę na wartość prawdy, co uruchamia zliczanie. Zatrzymanie pomiaru zmienia flagę na fałsz, dzięki czemu kolejne impulsy nie zmieniają wartości. Właśnie ten wzorzec flagi logicznej jest szeroko używany w różnych aplikacjach.
Wyświetlanie zliczonego czasu w czytelnym formacie pozwala użytkownikowi śledzić postęp pomiaru. Konstrukcja ta daje się łatwo rozszerzyć o funkcję zerowania, wznawiania i zapamiętywania wyników. Od tego miejsca zaledwie krok dzieli studenta od budowy pełnoprawnego stopera.
Zdarzenia czasowe otwierają zupełnie nową kategorię aplikacji reagujących na bieg czasu, a nie tylko na kliknięcia. Dzięki nim możliwe są gry z odliczaniem, animacje i dynamiczne interfejsy. To przełomowe rozszerzenie repertuaru zachowań możliwych do zaprojektowania.
Flaga logiczna uczy zarządzania stanem aplikacji za pomocą zaledwie dwóch wartości: prawda i fałsz. Ta prosta konstrukcja przenosi się na wiele innych dziedzin, takich jak blokowanie przycisków czy przełączanie trybów. Formatowanie czasu jest natomiast praktyczną lekcją przedstawiania danych w przyjaznej formie.
Ten wzorzec stanowi pomost do piątej prezentacji, w której dołączą czujniki oraz gry wymagające pomiaru czasu. Od teraz student potrafi tworzyć aplikacje żyjące własnym rytmem, nie tylko odpowiadające na polecenia. Zdobyte tu umiejętności będą potrzebne przy niemal każdym projekcie z animacją lub rozgrywką.
Metoda pracy oparta na odtwarzaniu i przekształcaniu gotowych wzorców przypomina sposób, w jaki uczą się zawodowi programiści. Najpierw wierne odtworzenie przykładu gwarantuje pewność rozumienia wszystkich szczegółów. Dopiero później warto wprowadzać własne modyfikacje, zaczynając od drobnych parametrów.
Zmiana jednej wartości i obserwacja skutku buduje intuicję co do tego, co można bezpiecznie modyfikować. Dodanie jednej nowej funkcji utrwala wzorzec integracji komponentu z istniejącą logiką. Wreszcie połączenie dwóch przykładów uczy łączenia modułów w spójną całość.
Zapisywanie kolejnych wersji i dokumentowanie zmian chroni pracę i pozwala cofać nieudane pomysły. Plik .aia zawiera cały projekt i można go bezpiecznie kopiować oraz udostępniać. Taki dyscyplinowany sposób pracy stanowi fundament samodzielnego rozwoju studenta.
Osiem przedstawionych aplikacji tworzy kompletny zbiór wzorców, z których każdy rozwija inną grupę pojęć. Ta biblioteka pozwala w razie potrzeby szybko wrócić do konkretnego rozwiązania i skopiować dobry przykład. Każdy wzorzec pozostaje przy tym otwarty na modyfikacje i rozbudowę.
Od prostego powitania, przez kalkulator i kolory, aż po quiz i zegar, widać wyraźną drogę narastania złożoności. Wszystkie aplikacje dzielą jednak wspólne fundamenty, czyli zdarzenia, właściwości, zmienne i warunki. Dzięki tej spójności nauka kolejnych przykładów przychodzi coraz łatwiej.
Zestaw ośmiu wzorców przygotowuje studenta do trudniejszego zadania w czwartej prezentacji. Przed przystąpieniem do dalszej nauki warto jeszcze utrwalić wszystkie najważniejsze bloki. Kontrola na końcu prezentacji pozwala zweryfikować pełnię osiągniętej wiedzy.
Pytania kontrolne służą nie tylko sprawdzeniu pamięci, lecz przede wszystkim uruchomieniu myślenia o mechanizmach. Zanim student napisze odpowiedź, powinien odtworzyć w myślach odpowiadające mu bloki i kolejność ich działania. Warto formułować odpowiedzi własnymi słowami, bo taka forma najlepiej utrwala wiedzę.
Rozwiązując zadanie łączące kalkulator z rzutem kostką, warto zacząć od zaplanowania ekranu menu i sposobu poruszania między częściami. Każda z nich zachowuje przy tym swoją wcześniej poznaną logikę, a połączenie sprowadza się do wyboru i przełączenia widoku. Taki podział pracy uczy projektowania aplikacji wieloekranowych.
Po rozwiązaniu wszystkich pytań warto sprawdzić każdą odpowiedź na prawdziwym sprzęcie i porównać z działaniem wzorcowym. Błędy odkrywane podczas testów są naturalną częścią tego procesu i nie powinny zniechęcać. Dzięki systematycznej pracy student zamyka trzecią prezentację z pełną wiedzą i gotowością na trudniejsze zadania.
Zakończenie prezentacji jest dobrym momentem na świadomą refleksję nad tym, ile nowych umiejętności nabyło się w ostatnim czasie. Z ośmiu gotowych aplikacji powstaje solidna baza wiedzy praktycznej, trudna do zdobycia samą teorią. Taka biblioteka wzorców pozostaje przydatna jeszcze długo po zakończeniu zajęć.
Każdy z przykładów przyczynił się do rozwoju innej umiejętności: od prostych interakcji po zarządzanie czasem i losowością. Powstałe w ten sposób pojęcia będą stale powracać w kolejnych prezentacjach. Warto zatem zwracać uwagę na nazwy bloków i komponentów, bo znacząco ułatwiają dalszą pracę.
W czwartej prezentacji wszystkie dotychczasowe wzorce zostaną połączone w rozbudowany program tworzony krok po kroku. Materiał ten stanowi naturalną kontynuację i wymaga, aby wszystkie przykłady zostały wcześniej przećwiczone. Lista literatury i serwisów internetowych zaprasza do dalszego, samodzielnego odkrywania środowiska.