Ćwiczenie z kalkulatorem jest punktem wyjścia do samodzielnego projektowania aplikacji mobilnych. Kalkulator wygląda na program prosty, a jednak łączy w sobie wszystkie fundamenty środowiska App Inventor: komponenty interfejsu, właściwości, zdarzenia, zmienne, instrukcje warunkowe i bloki matematyczne. Dzięki temu jeden projekt przygotowuje studenta do znacznie trudniejszych zadań, takich jak quiz, trener matematyczny czy gra.

Praca została podzielona na etapy tak, aby w każdej chwili było wiadomo, co właśnie się robi i po co. Najpierw powstaje szkielet ekranu, potem dochodzą przyciski, a dopiero na końcu logika obliczeń. Taki porządek odpowiada naturalnej kolejności pracy w Designerze, a potem w Blocks.

Po ukończeniu ćwiczenia student będzie miał działającą aplikację oraz powtarzalny schemat postępowania, który zastosuje przy każdym kolejnym projekcie. Warto wykonać wszystkie kroki samodzielnie, nawet jeśli niektóre wydają się oczywiste, bo właśnie powtarzalność buduje biegłość w środowisku blokowym.

Spis treści odzwierciedla kolejność, w jakiej powstaje prawdziwa aplikacja: od wymagań, przez interfejs, logikę, aż po testy i pakowanie. Każdy etap kończy się sprawdzalnym rezultatem, więc w trakcie pracy łatwo zauważyć postęp. Dzięki temu student nie gubi się w gąszczu bloków i zawsze wie, który element systemu jest aktualnie omawiany.

Podział na etapy ma też znaczenie dydaktyczne. Pozwala rozdzielić trudności związane z układaniem ekranu od trudności związanych z myśleniem algorytmicznym. Gdyby obie rzeczy robić naraz, błędy w wyglądzie i błędy w logice mieszałyby się ze sobą i trudniej byłoby je zdiagnozować.

Odnośniki w spisie treści prowadzą bezpośrednio do właściwych slajdów, co ułatwia powtórki i wracanie do wybranych zagadnień. Przed przystąpieniem do ćwiczenia warto raz na spokojnie przeczytać cały plan, a potem pracować slajd po slajdzie, nie przeskakując kroków. Kolejność nie jest przypadkowa - każdy etap opiera się na poprzednim.

Cele zostały sformułowane tak, aby dało się je sprawdzić na gotowej aplikacji. Każdy cel wiąże się z konkretnym elementem projektu: układ ekranu widać w Designerze, logika działań jest widoczna w Blocks, a testy i plik APK potwierdzają, że całość rzeczywiście działa. Taka postać celów ułatwia samodzielną ocenę postępów.

Warto zwrócić uwagę na cel czwarty, dotyczący odporności programu. Kalkulator bez walidacji wydaje się działać do momentu, aż użytkownik nic nie wpisze lub wpisze zera w mianowniku. Obsługa tych sytuacji odróżnia szkic od aplikacji, którą można komuś pokazać bez wstydu.

Ostatni cel ma wymiar syntetyczny, bo łączy wiedzę ze wszystkich wcześniejszych punktów. Uzasadnienie wyboru bloków wymaga rozumienia, co każdy blok zwraca i jakie ma ograniczenia. Student, który potrafi to wyjaśnić własnymi słowami, jest gotowy na samodzielne projektowanie kolejnych programów.

Kalkulator jest klasycznym przykładem programu przetwarzającego dane, dlatego dobrze nadaje się na pierwsze poważne ćwiczenie. Schemat wejście - przetwarzanie - wyjście powtarza się potem w quizie, w trenerze matematycznym i w każdej aplikacji, która przyjmuje informacje, coś z nimi robi i pokazuje rezultat. Zrozumienie tego schematu raz procentuje przy wielu kolejnych projektach.

Elementem, który często umyka początkującym, jest stan kalkulatora. Samo naciśnięcie znaku działania nic jeszcze nie oblicza - zapisuje jedynie fakt, że użytkownik wybrał daną operację i jaką liczbę podstawił. Dopiero przycisk równości uruchamia właściwe obliczenie, dlatego stan musi być przechowywany w zmiennych między naciśnięciami.

Zdarzenia Click są w App Inventor sposobem na reakcję na akcje użytkownika. Każdy przycisk ma własne zdarzenie, a kolejność obsługi zdarzeń jest sekwencyjna - w trakcie obsługi jednego zdarzenia nie jest obsługiwane inne. Ta prostota modelu wystarcza w zupełności do kalkulatora i ułatwia myślenie o programie jako o sekwencji reakcji na naciśnięcia.

Spis funkcji należy zapisać na kartce lub w notatniku, zanim cokolwiek pojawi się w Designerze. Dzięki temu od razu wiadomo, ile przycisków potrzeba i jakie logiki trzeba potem zaprogramować. Specyfikacja jest też umową z samym sobą - chroni przed ciągłym dodawaniem pomysłów w trakcie pracy i pozwala skupić się na wersji podstawowej.

Warto rozdzielić funkcje podstawowe od rozszerzonych. Cztery działania plus obsługa błędów stanowią jądro aplikacji, natomiast procent, potęga i pierwiastek można dorabiać etapami, gdy jądro już działa. Taki podział zmniejsza ryzyko, że przy pierwszej próbie powstanie zbyt duży i nieczytelny zestaw bloków.

Punkt dotyczący walidacji nie jest ozdobą specyfikacji, lecz jej pełnoprawną częścią. Każda funkcja obliczeniowa powinna mieć zdefiniowane zachowanie na wejściach niepoprawnych: pustych, zerowych lub niedozwolonych. Dopiero komplet takich reguł pozwala mówić, że aplikacja jest gotowa do testów użytkownika.

Rozróżnienie procentu i reszty z dzielenia jest jednym z najczęstszych źródeł nieporozumień między językiem programowania a codziennym użyciem. Studenci często zakładają, że blok modulo zaimplementuje przycisk procentu z kalkulatora szkolnego, a potem dziwią się nieoczekiwanym wynikom. Warto zapamiętać, że procent to zwykła arytmetyka, a modulo to operacja na liczbach całkowitych.

Blok modulo w dokumentacji MIT App Inventor ma ścisłą definicję: dla liczb dodatnich zgadza się z resztą z dzielenia, a ogólniej modulo(a, b) spełnia warunek floor(a / b) * b + modulo(a, b) = a. Znak wyniku modulo jest zawsze zgodny ze znakiem drugiego argumentu, co odróżnia go od bloku remainder. Te subtelności warto znać, zanim zacznie się używać operacji w działaniach na liczbach ujemnych.

Przy projektowaniu interfejsu najlepiej unikać wieloznacznych etykiet. Jeśli przycisk ma napis %, użytkownik spodziewa się procentu; jeśli mod, to reszty z dzielenia. Czytelne opisy na przyciskach to drobna rzecz, a znacząco poprawiają odbiór gotowej aplikacji i ułatwiają testy, bo od razu wiadomo, czego się spodziewać.

Projektując wygląd, warto oprzeć się na wzorcach znanych użytkownikom z systemowych aplikacji kalkulatora. Oczywisty podział na wyświetlacz u góry i siatkę przycisków na dole skraca czas oswajania się z programem. Im bardziej interfejs przypomina to, co student zna z telefonu, tym mniej energii pochłania obsługa, a tym więcej zostaje na myślenie o logice.

Kolorystyka ciemna ma praktyczne uzasadnienie: jasne cyfry na ciemnym tle są bardzo czytelne, a kolorowe przyciski operatorów natychmiast przyciągają wzrok. W App Inventor kolory ustawia się we właściwościach BackgroundColor, a czcionkę właściwością FontSize. Dobór tych dwóch parametrów potrafi odmienić ekran bez żadnych bloków.

Warto też pomyśleć o spójności wymiarów. Gdy wszystkie klawisze cyfr mają identyczną szerokość i wysokość, siatka wygląda profesjonalnie i nie skacze po kliknięciach. W Designerze ustawia się to właściwościami Width i Height poszczególnych przycisków, a kolejność wierszy zapewniają układy poziome osadzone w układzie pionowym.

Przegląd etapów pełni rolę checklisty, do której można wracać w trakcie pracy. Jeśli student zgubi się w blokach, wystarczy spojrzeć na mapę i sprawdzić, który punkt właśnie realizuje. Taki zewnętrzny nośnik porządku bardzo pomaga, zwłaszcza gdy przerwa między zajęciami jest dłuższa.

Kolejność etapów wynika z zależności technicznych. Nie da się sensownie zaprogramować przycisków, które jeszcze nie istnieją w Designerze, i nie da się testować logiki bez zmiennych przechowujących stan. Odwrotna kolejność byłaby możliwa, ale mniej czytelna i łatwiej byłoby wtedy pomylić nazwy komponentów.

Ostatni etap - testy i pakiet - bywa lekceważony, a szkoda. Właśnie wtedy wychodzą na jaw puste pola, zera w mianowniku i źle podpięte przyciski. APK jest zaś wisienką na torcie: gotowy plik można zainstalować na telefonie i pokazać rodzinie lub kolegom, co daje realne poczucie ukończenia projektu.

Tworzenie projektu jest formalnością, ale od niej zaczyna się porządek w całej pracy. Nazwa kalkulator_v1 od razu mówi, o jaki program chodzi i którą wersję mamy przed oczami. Gdy za kilka tygodni powstanie wersja z historią obliczeń, naturalnym nazwaniem będzie kalkulator_v2, a poprzednia pozostanie nietknięta jako punkt odniesienia.

Ograniczenia dotyczące nazwy wynikają z technicznych uwarunkowań serwisu i plików projektowych. Spacje i polskie znaki potrafią sprawiać problemy przy eksporcie, imporcie i budowaniu pakietu, więc lepiej unikać ich od początku. Podkreślnik jest bezpiecznym zamiennikiem spacji i dobrze czytelny w nazwach plików.

Po potwierdzeniu nazwy serwis od razu przechodzi do okna Designer, co sygnalizuje naturalną kolejność pracy w App Inventor: najpierw wygląd, potem zachowanie. Ekran Screen1 przydzielony jest automatycznie, więc nie trzeba go tworzyć ręcznie. Od tego momentu każdy kolejny krok będzie opierał się na tym pustym, czystym ekranie.

Właściwości ekranu definiują kontekst, w jakim pojawi się cały interfejs. Title jest widoczne od razu, nawet w trakcie testów przez Companion, dlatego od razu warto wpisać tam sensowny opis zamiast domyślnej wartości. AppName natomiast decyduje o tym, jak aplikacja będzie wyglądać na pulpicie telefonu po instalacji.

Ustawienie koloru tła na etapie ekranu oszczędza później powtarzania tej samej wartości przy każdym komponencie. Ciemne tło od razu zmienia odbiór całości i ułatwia ocenienie, czy wybrane kolory przycisków dobrze kontrastują. Próbkę koloru można wybrać z gotowej palety albo wpisać kod szesnastkowy, gdy potrzebny jest dokładny odcień.

Orientacja Portrait jest dobrym wyborem dla kalkulatora, bo siatka czterech kolumn naturalnie mieści się w pionowym układzie telefonu. Poziomy obrót ekranu wymagałby przeprojektowania rozmieszczenia i utrudniałby porównywanie wyników z innymi aplikacjami. Decyzja o orientacji, podobnie jak inne ustawienia ekranu, może być w razie potrzeby zmieniona w dowolnym momencie.

Rysunek na kartce zajmuje kilka minut, a oszczędza godziny poprawiania gotowego układu. Dzięki szkicowi od razu widać, ile rzędów będzie potrzebne i gdzie znajdą się przyciski rzadziej używane. Warto też zaznaczyć kolory, bo decyzje o palecie łatwiej podjąć na papierze niż w trakcie klikania w panel właściwości.

Układy poziome i pionowe w App Inventor pełnią rolę pojemników na komponenty. Bez nich przyciski układają się jeden pod drugim w kolejności dodawania i nie da się utworzyć siatki. Zagnieżdżanie jednego układu w drugim to standardowa technika i właśnie na niej opiera się budowa każdego kalkulatora.

Warto też przewidzieć miejsce na przyciski, które pojawią się dopiero w kolejnych etapach, na przykład na przycisk potęgowania czy pierwiastka. Jeśli zostawimy wolne pole na samym początku, później nie trzeba będzie przesuwać całej reszty. Dobry szkic zawiera nawet te elementy, których logika jeszcze nie powstanie.

Wyświetlacz jest pierwszym elementem, który użytkownik zobaczy, dlatego warto poświęcić mu chwilę uwagi. Duży rozmiar czcionki i wyrównanie do prawej to cechy klasycznych kalkulatorów; przyzwyczajonych użytkowników od razu uspokajają. Etykieta sprawdza się tu lepiej niż pole tekstowe, bo chroni wynik przed przypadkową edycją palcem.

Układ pionowy obejmujący całą treść ekranu porządkuje dalszą pracę: każdy kolejny rząd przycisków będzie dodawany jako osobny wiersz wewnątrz tego nadrzędnego pojemnika. Dzięki temu nie trzeba ręcznie pilnować kolejności komponentów na samym ekranie - robi to za nas struktura układów.

Właściwość Width ustawiona na Fill parent sprawia, że wyświetlacz zajmuje całą dostępną szerokość i nie ma dziwnych odstępów po bokach. Wysokość etykiety warto zwiększyć, aby nawet bardzo długie wyniki mieściły się wygodnie i nie przesuwały reszty interfejsu w dół przy każdym kliknięciu.

Metoda tworzenia rzędów po kolei jest żmudna, ale bardzo czytelna. Każdy HorizontalArrangement jest zamkniętą całością, którą łatwo sprawdzić w podglądzie, zanim przejdzie się do następnego wiersza. Dzięki temu błędy w układzie wychodzą natychmiast, a nie po złożeniu całego ekranu.

Równe wymiary przycisków są kluczowe dla profesjonalnego wyglądu. Jeśli jeden klawisz będzie szerszy od drugiego, siatka przestanie tworzyć regularną kratę i od razu zacznie wyglądać amatorsko. Właściwości Width i Height można skopiować, ustawiając je najpierw wzorcowo na pierwszym przycisku, a potem przenosząc te wartości na pozostałe.

Warto od początku przemyśleć rozmieszczenie operatorów. Typowy układ kalkulatora umieszcza je w prawej kolumnie, co odpowiada przyzwyczajeniom użytkowników. Jeśli do siatki mają dojść jeszcze przyciski procentu, potęgi i pierwiastka, lepiej od razu zaplanować dla nich osobny rząd funkcyjny zamiast psuć regularność głównej kraty.

Rząd funkcyjny domyka specyfikację wizualną. Przyciski procentu, reszty z dzielenia, pierwiastka i potęgi są używane rzadziej niż cyfry, więc dobrze wyglądają oddzielone od głównej siatki. Taki podział od razu komunikuje hierarchię funkcji i nie przytłacza początkującego użytkownika nadmiarem klawiszy.

Kolory w App Inventor ustawia się właściwością BackgroundColor, która oferuje paletę gotowych barw oraz możliwość podania kodu RGB. Grupowanie kolorystyczne to najtańszy sposób na poprawę ergonomii - nie wymaga żadnych bloków, a zmienia odbiór aplikacji bardziej niż wiele skomplikowanych zabiegów.

Przed przejściem do okna Blocks warto raz jeszcze obejrzeć całość w podglądzie i sprawdzić, czy nic się nie przelewa poza ekran. Jeśli któryś rząd nie mieści się na małym wyświetlaczu, można zmniejszyć szerokość przycisków lub skondensować odstępy układów. Lepiej poprawić to teraz, gdy logika jeszcze nie powstała, niż potem przerabiać nazwy komponentów po wszystkim.

Nadawanie nazw jest najtańszą inwestycją w czytelność projektu. Gdy w oknie Blocks pojawi się kilkanaście zdarzeń Click, nazwy btnPlus i btnDziel mówią same za siebie, podczas gdy Button7 i Button12 niczego nie sugerują. Student wracający do projektu po tygodniu od razu odnajdzie właściwy blok.

Komponent Notifier jest niewidoczny na ekranie, ale niezwykle użyteczny. Metoda ShowAlert wyświetla krótki komunikat na dole ekranu, ShowMessageDialog - okno z przyciskiem, a ShowChooseDialog - pytanie z wyborem. W kalkulatorze wystarczy ShowAlert do ostrzeżeń o pustym polu czy dzieleniu przez zero.

Warto też unikać polskich znaków w nazwach komponentów i zmiennych. Chociaż nowsze wersje AI2 radzą sobie z nimi coraz lepiej, to konwencja bezpiecznego nazewnictwa łacińskiego nie sprawia problemów przy eksporcie i imporcie projektu. Podkreślnik i wielkość liter wystarczą, by nazwy pozostały czytelne.

Checklist zamyka pierwszy duży etap pracy i daje poczucie zamkniętego rozdziału. Nawet przy prostym kalkulatorze łatwo przeoczyć niezmienioną nazwę przycisku albo zostawiony przypadkowy komponent. Krótki przegląd kosztuje minutę, a oszczędza frustrację podczas debugowania bloków.

Przełącznik między Designerem a Blocks to most między dwoma różnymi sposobami myślenia: o wyglądzie i o zachowaniu. Obie części projektu są ściśle sprzężone - bloki odwołują się do komponentów utworzonych w Designerze, więc wcześniejszy porządek przekłada się wprost na czytelność logiki.

Jeśli w trakcie programowania okaże się, że brakuje jakiegoś przycisku, zawsze można wrócić do Designer i go dodać - tylko wtedy trzeba będzie dopisać dla niego odpowiednie bloki. Dlatego lepiej dopiąć interfejs na ostatni guzik przed pierwszym zdarzeniem Click, nawet kosztem kilku minut dokładniejszego sprawdzania.

Zmienne globalne stanowią pamięć kalkulatora pomiędzy poszczególnymi naciśnięciami przycisków. Bez nich program nie wiedziałby, jaką liczbę podstawić do działania, gdy użytkownik najpierw wpisze cyfry, a potem wybierze operator. Zmienna pełni tu rolę pojemnika, do którego odkładamy dane na czas między zdarzeniami.

Flaga nowyWpis jest subtelna, ale bardzo praktyczna. Gdy jest prawdą, następna cyfra zastępuje wyświetlaną wartość, a gdy fałsz - dokleja się do niej z prawej strony. Dzięki temu wpisywanie wielocyfrowych liczb działa intuicyjnie, dokładnie tak jak w systemowym kalkulatorze.

Warto zauważyć, że App Inventor nie wymusza typów zmiennych - ta sama zmienna może przechowywać tekst, liczbę lub wartość logiczną. Dlatego operator wygodnie trzymać jako tekst, a mimo to porównywać go z literałami w blokach warunkowych. Świadomość tej elastyczności ułatwia projektowanie stanu aplikacji.

Obsługa cyfr jest powtarzalna, więc doskonale nadaje się do ćwiczenia kopiowania bloków. Prawym przyciskiem myszy wybieramy Duplicate, przenosimy kopię obok i zmieniamy wyłącznie to, co konieczne: nazwę przycisku w zdarzeniu oraz tekst cyfry w literale. Kilka minut i cały zbiór cyfr jest obsługiwany.

Warunek sprawdzający nowyWpis jest sercem intuicyjnego wprowadzania liczb. Bez niego każda naciśnięta cyfra zastępowałaby poprzednią i nie dałoby się zbudować liczby większej od dziewięciu. Z drugiej strony ustawienie flagi na false po pierwszej cyfrze sprawia, że kolejne kliknięcia doklejają się zgodnie z oczekiwaniem.

Warto zauważyć, że etykieta wyświetlacza przechowuje tekst, nie liczbę. To normalne w App Inventor i nie przeszkadza w dalszych obliczeniach - AI2 w blokach arytmetycznych sam rozpoznaje ciąg przypominający liczbę. Problem pojawia się dopiero przy pustym tekście lub niedozwolonych znakach, co jest tematem etapu walidacji.

Przycisk kropki wymaga prostego zabezpieczenia: bez sprawdzenia użytkownik mógłby wcisnąć kilka separatorów i uzyskać ciąg nie do zinterpretowania jako liczba. Warunek sprawdzający obecność kropki w tekście wyświetlacza wystarczy, by uniemożliwić taki scenariusz. To pierwszy przykład walidacji wpisu jeszcze na etapie budowania liczby.

Rozróżnienie między kasowaniem bieżącego wpisu a pełnym resetem jest standardem kalkulatorów. Kasowanie czyści tylko to, co widać na wyświetlaczu, pozostawia zapamiętany operator i pierwszą liczbę, natomiast AC przywraca stan początkowy całego programu. Dzięki temu użytkownik może poprawić literówkę bez konieczności zaczynania działania od nowa.

W przypadku liczb ujemnych warto zdecydować się na jedno, spójne rozwiązanie i opisać je użytkownikowi. Można dodać osobny przycisk zmiany znaku albo interpretować pierwsze naciśnięcie minusa jako utworzenie liczby ujemnej. Niezależnie od wyboru najważniejsze, by logika była przewidywalna i testowana na kilku przykładach.

Przycisk operatora pełni funkcję łącznika między dwiema liczbami: zamyka wprowadzanie pierwszej i otwiera wprowadzanie drugiej. Właśnie dlatego musi zdążyć zapisać dotychczasowy wynik wyświetlacza, zanim przełączy flagę nowyWpis. Ta jedna sekunda chronologii decyduje o tym, czy potem policzymy dobrze.

Przechowywanie operatora w postaci tekstu jest proste i czytelne w blokach warunkowych. Później, przy przycisku równości, wystarczy porównać zmienną z literałami +, -, *, / i w każdej gałęzi użyć właściwego bloku matematycznego. Alternatywą byłoby używanie liczb jako kodów operacji, ale tekst jest czytelniejszy podczas oglądania bloków.

Opcjonalny wiersz wyrażenia znacząco poprawia komfort obsługi. Gdy użytkownik widzi 12 +, wie, że pierwsza liczba została przyjęta i czeka na drugą. Bez tego sygnału łatwo o pomyłkę i powtórne naciskanie operatora. Podgląd ten to tylko ustawienie tekstu etykiety, a bardzo ułatwia życie.

Przycisk równości jest jedynym miejscem, w którym faktycznie dzieje się arytmetyka. Wcześniejsze zdarzenia tylko przygotowują stan: zapisują liczbę i wybierają operację. Dzięki takiemu podziałowi blok Click pozostaje czytelny, mimo że obsługuje wiele różnych działań.

Instrukcja if...then...else może być rozbudowywana o kolejne gałęzie za pomocą ikonki koła zębatego. W kalkulatorze potrzebujemy osobnej gałęzi dla każdego operatora, więc lista warunków stopniowo się wydłuża. Ważne, by każde porównanie dotyczyło tej samej zmiennej operator i by gałęzie się nie nakładały.

Ustawienie flagi nowyWpis po obliczeniu domyka cykl wprowadzania. Bez tego następna naciśnięta cyfra dokleiłaby się do wyniku i użytkownik nie mógłby rozpocząć nowego działania bez ręcznego czyszczenia. Ta jedna linia bloków odpowiada za płynność dalszej pracy z aplikacją.

Dodawanie i odejmowanie to najprostsze gałęzie, bo nie wymagają żadnych warunków dodatkowych. Blok matematyczny sam rozpoznaje, że tekst na wyświetlaczu przedstawia liczbę, i wykonuje działanie. Dzięki temu można od razu przetestować pełny cykl: wpisanie liczby, wybór operatora, druga liczba i wynik.

Porównania operatora warto budować spójnie - zawsze z tą samą konwencją, na przykład tekst z lewej i literał z prawej. App Inventor udostępnia porównania zarówno w szufladzie Math, jak i w Logic, więc łatwo o pomyłkę przy wyborze bloku. Oba rozwiązania zadziałają w tym miejscu, ale lepiej trzymać się jednego stylu w całym projekcie.

Zmienna wynik nie jest konieczna, ale ułatwia debugowanie. Można kliknąć prawym przyciskiem na blok i wybrać Do it, by sprawdzić wartość pośrednią bez uruchamiania całej reszty programu. Przy dłuższych wyrażeniach ta technika bardzo skraca czas szukania błędu.

Mnożenie jest równie proste jak dodawanie i nie wymaga zabezpieczeń poza standardową walidacją wejścia. Ciekawostką jest możliwość rozbudowy bloku o więcej czynników, co przydaje się w innych programach, lecz w kalkulatorze dwie wystarczą. Ważniejsze jest to, by kolejne gałęzie warunków nie zachodziły na siebie.

Ochrona przed dzieleniem przez zero to najważniejszy przypadek brzegowy w całym kalkulatorze. Najpierw porównujemy mianownik z zerem, a dopiero potem wykonujemy dzielenie; gdy warunek jest spełniony, pokazujemy komunikat i nie uruchamiamy bloku /. Dzięki temu użytkownik dostaje zrozumiałą informację zamiast tajemniczej wartości na wyświetlaczu.

Warto wypróbować obie ścieżki podczas testów: normalne dzielenie oraz dzielenie przez zero. Porównanie zachowania aplikacji z i bez zabezpieczenia najlepiej przekonuje, dlaczego walidacja jest niezbędna. Ten sam wzorzec - warunek przed niebezpieczną operacją - wykorzystasz potem w wielu innych programach.

To zagadnienie bywa prawdziwym odkryciem dla studentów znających programowanie tekstowe. Tam kolejność wyznacza priorytet operatorów, a nawiasy trzeba dopisywać ręcznie; tutaj kolejność jest wprost widoczna w przestrzennym ułożeniu klocków. Błędne zagnieżdżenie widać od razu, o ile patrzy się na kształt bloków.

W kalkulatorze ta zasada ma znaczenie przy budowie wyrażeń złożonych, na przykład procentu złożonego z dzielenia i mnożenia. Zamiast walczyć z interpretacją priorytetów, budujemy wyrażenie etapami: najpierw dzielimy przez 100, potem mnożymy przez wartość procentu. Każdy etap to osobny, jawnie widoczny blok.

Świadomość pracy z zagnieżdżeniem przydaje się też przy testach. Zamiast zgadywać, co się stało, można kliknąć prawym przyciskiem na wewnętrzny blok i sprawdzić jego wartość przed przekazaniem dalej. Ta technika, znana z podejścia Do it, zamienia abstrakcyjny problem w konkretne liczby do porównania.

Testy na wczesnym etapie oszczędzają dużo pracy później. Jeśli okaże się, że po wyniku nie resetuje się flaga nowyWpis, lepiej dowiedzieć się o tym teraz, gdy w blokach są jeszcze tylko cztery działania, niż po dodaniu dziesięciu kolejnych przycisków. Mały, częsty cykl testowania to cecha dobrej praktyki programistycznej.

Przypadek 8 / 3 pokazuje kwestię prezentacji wyniku. AI2 wyświetli długi łańcuch dziesiętny, który nie mieści się elegancko na ekranie. Rozwiązaniem jest późniejsze formatowanie wyniku blokiem format as a decimal albo zaokrąglenie - ale najpierw warto zobaczyć problem na własne oczy.

Sprawdzenie przycisku = po każdym wyniku jest tak samo ważne jak sama arytmetyka. To właśnie tam ujawniają się błędy w zarządzaniu flagami i stanem. Jeśli po equals użytkownik nie może wpisać nowej liczby bez ręcznego czyszczenia, logika stanu wymaga poprawki, niezależnie od tego, czy cztery podstawowe działania liczą poprawnie.

Brak dedykowanego bloku procentu nie jest wadą środowiska, tylko okazją do zrozumienia, z czego procent tak naprawdę wynika. Każdy procent to zwykła ułamkowa część liczby, a podzielenie przez sto jest właśnie operacją zamiany procentu na ułamek. Student, który to pojmie, przestanie traktować % jako magiczny symbol.

W praktycznych kalkulatorach funkcja procentu ma kilka konwencji: czasem liczy procent od poprzedniej wartości, czasem po prostu dzieli przez sto, a czasem domyka działanie typu 200 + 10%. Warto świadomie wybrać jedną z nich i opisać ją w specyfikacji, a potem konsekwentnie zaimplementować. Niespójność między opisem a działaniem jest gorsza niż prosty, dobrze udokumentowany wzór.

Przy implementacji łatwo o pomyłkę kolejności: czy najpierw dzielimy przez sto, czy najpierw mnożymy. Przy liczbach dodatnich wynik będzie ten sam, ale zagnieżdżenie bloków warto mieć zapisane dokładnie tak jak we wzorze. Dobrym nawykiem jest nazwanie zmiennej pomocniczej, na przykład czescProcentowa, i policzenie jej osobno.

Blok modulo jest w dokumentacji opisany ścisłym wzorem: floor(a / b) * b + modulo(a, b) = a. Dla liczb dodatnich pokrywa się z potoczną resztą z dzielenia, więc w codziennym użyciu wystarcza intuicja ze szkoły. Różnice wychodzą dopiero przy liczbach ujemnych, co warto sprawdzić, zanim zacznie się polegać na wyniku w dalszych obliczeniach.

Opcja remainder jest alternatywą dla modulo i zawsze przyjmuje znak pierwszego argumentu. Quotient natomiast zwraca część całkowitą wyniku dzielenia, odrzucając resztę. Te trzy bloki są w jednej grupie rozwijanej, więc łatwo o niechcącą pomyłkę - zawsze warto sprawdzić, którą pozycję wybrano na liście.

W kalkulatorze reszta z dzielenia bywa użyteczna, gdy użytkownik pracuje na liczbach całkowitych, na przykład przy prostych obliczeniach czasowych lub porządkowych. Jeśli jednak aplikacja ma służyć głównie do szkolnej arytmetyki, przycisk mod można umieścić w rzędzie funkcyjnym i opisać w instrukcji, aby nie mylił się z procentem.

Potęgowanie jest w AI2 realizowane jednym, prostym blokiem, co nie znaczy, że łatwo o pomyłkę. Zamiana podstawy z wykładnikiem daje zupełnie inny wynik, dlatego warto zapisywać w komentarzu przy bloku, który slot za co odpowiada. Trzymanie konwencji ułatwia też testy - łatwo wtedy przewidzieć oczekiwany rezultat.

Ciekawostką jest to, że w materiałach pam4 potęgowanie było demonstrowane procedurą ProcDoPotegi2, która mnożyła liczbę przez samą siebie. Blok ^ zastępuje całą tę procedurę w codziennym użyciu, ale przykład z procedur pozostaje świetną ilustracją, jak działa zwracanie wartości z własnych bloków. Obie drogi są poprawne i warto znać obie.

Wykładnik nie musi być liczbą całkowitą - blok przyjmuje również ułamki, co pozwala na obliczanie pierwiastków inną drogą: pierwiastek kwadratowy to potęga o wykładniku 0,5. Nie zastępuje to bloku square root, ale dobrze pokazuje spójność matematyki w środowisku blokowym.

Blok square root jest częścią większej rodziny jednoargumentowych funkcji matematycznych: abs, neg, log, e^, round, ceiling i floor. Wszystkie znajdują się w tej samej rozwijanej grupie, co ułatwia eksplorowanie szuflady Math i odkrywanie gotowych narzędzi zamiast ręcznego konstruowania ich z bloków elementarnych.

Warunek chroniący przed pierwiastkiem z liczby ujemnej działa tak samo jak zabezpieczenie przed dzieleniem przez zero. Najpierw sprawdzamy, czy argument jest nieujemny, a dopiero potem uruchamiamy właściwy blok. Bez tego użytkownik mógłby zobaczyć na wyświetlaczu wartość niebędącą liczbą i nie wiedzieć, skąd się wzięła.

Warto pamiętać, że pierwiastek kwadratowy z liczby, która nie jest pełnym kwadratem, daje wynik z wieloma miejscami po przecinku. Ładne prezentowanie takich wyników to zadanie dla formatowania, omówionego w dalszej części ćwiczenia. Sam blok zwraca wartość z pełną precyzją, jaką dysponuje środowisko.

Funkcje pomocnicze zamieniają surowy kalkulator w narzędzie, z którego korzysta się przyjemnie. Formatowanie z dwóch miejsc po przecinku wystarczy, aby wynik dzielenia 8 na 3 przestał szpecić ekran, a zaokrąglenie przydaje się przy szybkich obliczeniach szacunkowych. Nawet jeden dodatkowy przycisk potrafi zmienić odbiór całej aplikacji.

Blok is a number? wraca przy walidacji. Zwraca prawdę tylko wtedy, gdy podany obiekt rzeczywiście jest liczbą, więc świetnie nadaje się do sprawdzania treści, zanim trafi do działania arytmetycznego. W połączeniu z warunkiem if tworzy zaporę przed niepoprawnymi wejściami.

Warto zauważyć, że round w AI2 stosuje regułę zaokrąglania do parzystej: przy dokładnej połowie liczba o parzystej części całkowitej zaokrągla się w dół. To subtelność z dokumentacji, która może zaskoczyć, gdy spodziewamy się klasycznego zaokrąglania w górę. Świadomość tej reguły chroni przed fałszywym podejrzeniem błędu w programie.

Formatowanie to etap domykający każde działanie. Jeśli pominąć ten krok, prosty test 8 / 3 od razu pokaże problem: łańcuch cyfr nie mieści się na wyświetlaczu i psuje estetykę. Blok format as a decimal rozwiązuje to zadanie w jednym miejscu, bez ręcznego skracania tekstu.

Drugi argument bloku musi być nieujemną liczbą całkowitą, inaczej wywołanie zakończy się błędem. W praktyce wystarczy wpisać stałą 2 lub 4 w odpowiedni slot. Jeśli ktoś chciałby zwiększyć precyzję dynamicznie, musiałby najpierw zwalidować wartość, którą zamierza podstawić.

Warto też rozważyć, czy formatować wyłącznie wynik końcowy, czy każde pośrednie wyświetlanie. Zbyt częste zaokrąglanie może maskować błędy w obliczeniach pośrednich, dlatego dobrym nawykiem jest pokazywanie pełnej precyzji w trakcie debugowania, a dopiero potem włączanie ładnego formatu w wersji finalnej.

Walidacja danych wejściowych to zbiór technik sprawdzających, czy informacja od użytkownika nadaje się do dalszego przetwarzania. W kalkulatorze sprowadza się do dwóch pytań: czy coś w ogóle wpisano i czy to coś jest liczbą. Dopiero gdy oba pytania dają odpowiedź twierdzącą, bezpiecznie można uruchomić bloki arytmetyczne.

Blok is a number? jest wygodniejszy od ręcznego przeglądania znaków, bo obsługuje przypadki, których łatwo nie przewidzieć - spacje, dziwne separatory, litery w środku ciągu. Jeśli zwróci fałsz, wiadomo, że dalsze działanie mogłoby się zakończyć błędem wykonania albo sensownym, lecz błędnym wynikiem.

Warto pamiętać o różnicy między NumbersOnly a walidacją. NumbersOnly wpływa wyłącznie na to, co podpowiada klawiatura na danym urządzeniu; nie kontroluje treści, która już znajduje się w etykiecie ani danych przychodzących z innych źródeł. Dlatego profesjonalne podejście zawsze łączy wygodę na wejściu z kontrolą przed przetwarzaniem.

Przypadki brzegowe są tym, co odróżnia szkic aplikacji od jej solidnej wersji. Dzielenie przez zero i pierwiastek z liczby ujemnej występują rzadko, ale właśnie wtedy, gdy użytkownik eksperymentuje lub się spieszy. Aplikacja, która w takiej sytuacji pokazuje czytelny komunikat, buduje zaufanie; taka, która wyświetla tajemniczą wartość, je traci.

Kolejność sprawdzania warunków ma znaczenie przy zagnieżdżonych ifach. Najpierw eliminujemy najbardziej proste błędy - pusty wpis, brak operatora - a potem przechodzimy do warunków specyficznych dla danego działania. Taki układ zapobiega sytuacji, w której program próbuje sprawdzać własność mianownika, gdy druga liczba w ogóle nie została jeszcze podana.

Warto zapisać spis obsługiwanych wyjątków w notatce do projektu. Lista typu: pusty wpis, nie-liczba, zerowy mianownik, ujemny argument pierwiastka staje się gotową listą testową. Można ją przeglądać przed każdą większą zmianą i mieć pewność, że wcześniejsze zabezpieczenia nadal działają.

Notifier jest jednym z najbardziej uniwersalnych komponentów App Inventor. Nie wymaga prawie żadnej konfiguracji w Designerze, a pozwala natychmiast komunikować się z użytkownikiem. W roli komunikatora błędów sprawdza się idealnie, bo nie zaburza układu ekranu i znika po chwili.

Wybór między ShowAlert a ShowMessageDialog zależy od wagi komunikatu. Ostrzeżenie o literówce nie potrzebuje okna z przyciskiem - wystarczy Alert. Natomiast pytanie o potwierdzenie kasowania całego stanu naturalnie pasuje do okna dialogowego. Nadmiar ciężkich okien irytuje, nadmiar cichych Alertów użytkownik może przeoczyć.

Warto przygotować stałe teksty komunikatów i trzymać je w jednym miejscu, na przykład w procedurze pomocniczej. Dzięki temu zmiana sformułowania nie wymaga przeszukiwania całego projektu. To prosty nawyk, który procentuje przy każdym kolejnym programie z komunikatami.

Procedury są najlepszym sposobem na unikanie powtarzania tego samego fragmentu bloków. Komunikat o błędzie może być wywoływany z wielu miejsc - pusty wpis, zerowy mianownik, ujemny pierwiastek - a mimo to jego treść definiuje się tylko raz. Przy zmianie sformułowania wystarczy poprawić jedno miejsce.

Procedura zwracająca rezultat działa jak funkcja znana z matematyki: przyjmuje argumenty, coś oblicza i odsyła wartość do wywołującego. W kalkulatorze świetnie nadaje się na obliczanie procentu albo sprawdzanie poprawności wejścia, bo wynik testu można potem podpiąć pod warunek if.

Warto też dodać komentarze do procedur - prawym przyciskiem na bloku wybieramy Comment i opisujemy, co procedura robi. Komentarze pomijane są przez środowisko, ale dla człowieka wracającego do projektu po miesiącu są nieocenione. Ta dobra praktyka kosztuje kilkanaście sekund, a oszczędza mnóstwo domysłów.

Podsumowanie logiki jest dobrym momentem na krok w tył i obejrzenie całości. Jeśli przestrzeń robocza wygląda na chaos, warto ją uporządkować, zanim dojdą kolejne funkcje. W App Inventor łatwo przesuwać bloki i grupować je komentarzami, więc estetyka Blocks jest na wyciągnięcie ręki.

Uporządkowanie ma też praktyczne konsekwencje przy debugowaniu. Gdy zdarzenia są ułożone w logiczne sekwencje, szybciej znajduje się to, czego się szuka, i łatwiej zauważyć brakujące powiązanie. Studenci często lekceważą ten aspekt, a potem tracą czas na szukanie jednego zdarzenia pośród kilkudziesięciu bloków.

Warto zadać sobie pytanie kontrolne: czy każdy przycisk z interfejsu ma jakieś zdarzenie w Blocks? Jeśli któryś został pominięty, użytkownik naciśnie go i nie stanie się nic - bardzo frustrujące zachowanie. Pełna mapa przycisków do zdarzeń to naturalna część checklisty przed przejściem do testów.

AI Companion skraca cykl poprawiania z minut do sekund. Zamiast budować plik i instalować go po każdej zmianie, wystarczy poprawić blok i spojrzeć na telefon. Dzięki temu można testować nawet drobne decyzje - kolor przycisku, treść komunikatu, miejsce formatowania - w naturalnym tempie pracy.

Wariant Wi-Fi wymaga, by oba urządzenia widziały się w tej samej sieci. W salach wykładowych bywa z tym problem, gdy sieć gościnna blokuje komunikację między urządzeniami. Awaryjnym rozwiązaniem jest emulator na komputerze, chociaż zachowuje się on nieco inaczej niż prawdziwy telefon i nie wszystko sprawdzi równie dobrze.

Warto pamiętać, że nie każda zmiana natychmiast odświeża widok. Czasem trzeba zmodyfikować dowolną właściwość w Designerze, by wymusić aktualizację, albo przerwać i ponowić połączenie. Znajomość tych drobiazgów oszczędza nerwów na początku pracy z Companionem.

Tablica testów jest dokumentem, który warto prowadzić równolegle z programem. Każdy wiersz to konkretne oczekiwanie, które łatwo sprawdzić oczami - nie trzeba do tego specjalistycznego narzędzia. Gdy po dodaniu nowej funkcji uruchomimy ponownie całą listę, mamy pewność, że nic się nie popsuło.

Wiersze dotyczące błędów są równie ważne jak te z poprawnymi wynikami. Aplikacja, która poprawnie liczy, ale nie radzi sobie z zerem czy pustym wpisem, jest wciąż niegotowa. Warto dopisać do tabeli każdy komunikat, którego się spodziewamy, i sprawdzić, czy rzeczywiście się pojawia.

Po udanych testach można spokojnie przejść do pakowania. Jeśli jakiś wiersz nie przechodzi, wracamy do bloków z konkretnym tropem - nazwą próby i oczekiwaniem - zamiast chaotycznie klikać po całej aplikacji. Taka metodyczna praca to nawyk, który warto wynieść z tego ćwiczenia na całą dalszą karierę.

Debugowanie w środowisku blokowym ma własne, bardzo wygodne narzędzia. Funkcja Do it pozwala wykonać pojedynczy blok i zobaczyć jego wynik bez uruchamiania całego programu. Disable block chwilowo wyłącza fragment logiki, co pomaga zawęzić przyczynę problemu. Komentarze z kolei porządkują myślenie, nawet gdy sam program jeszcze nie działa.

Błędy nazw są częstsze, niż się wydaje, zwłaszcza gdy nazwy zmieniane były w pośpiechu. Wielkość liter w App Inventor ma znaczenie, więc nazwa pierwszaLiczba nie jest tożsama z pierwszaliczba. Jeśli blok nie może znaleźć zmiennej, warto najpierw sprawdzić właśnie pisownię, a dopiero potem szukać głębszych przyczyn.

Warto pracować metodą najmniejszego kroku: poprawić jedną rzecz, przetestować, potem kolejną. Przy wielu zmianach naraz trudno ustalić, co dokładnie naprawiło albo zepsuło aplikację. Ta dyscyplina wydaje się wolna, a w praktyce jest najszybszą drogą do stabilnie działającego programu.

Poprawki wizualne najlepiej robić po pełnej serii testów funkcjonalnych. Wtedy wiadomo już, że logika działa i można bez ryzyka skupić się na detalach. Często drobne przesunięcie odstępu albo podbicie czcionki robi większą różnicę niż kolejna, rzadko używana funkcja.

Warto obejrzeć aplikację na co najmniej dwóch rozmiarach ekranu - telefonie i emulatorze. Elementy, które mieszczą się na dużym wyświetlaczu, potrafią wychodzić poza ramkę na mniejszym. Jeśli coś się nie mieści, lepiej skondensować odstępy niż zmniejszać przyciski poniżej wygodnego rozmiaru dotyku.

Dokumentacja w postaci zrzutu ekranu kosztuje kilka sekund, a bardzo pomaga przy wracaniu do projektu lub opisywaniu go w sprawozdaniu. Dobry nawyk to zapisywać taki zrzut po każdym większym etapie, nie tylko na samym końcu. Dzięki temu widać ewolucję interfejsu i łatwiej uzasadnić decyzje projektowe.

Rozszerzenia pokazują, że kalkulator jest dobrym punktem startowym, a nie celem samym w sobie. TinyDB pozwala przechowywać dane trwałe między uruchomieniami aplikacji, więc historia obliczeń przetrwa zamknięcie programu. To pierwszy kontakt z trwałą pamięcią w App Inventor i naturalny kolejny krok po opanowaniu zmiennych globalnych.

Tryb naukowy wykorzystuje gotowe bloki trygonometryczne i logarytmiczne z szuflady Math. Wiele z nich pracuje na kątach podawanych w stopniach, co warto zaznaczyć użytkownikowi w interfejsie. Dodanie takich funkcji nie wymaga nowych mechanizmów - jedynie kolejnych przycisków i gałęzi w logice.

Warto też pamiętać o priorytetach. Lepiej najpierw doprowadzić wersję podstawową do pełnej stabilności, a dopiero potem dokładać nowe pomysły. Rozbudowa bez zamkniętej bazy testów zwykle prowadzi do regresji, gdy stara funkcja przestaje działać po wprowadzeniu nowej.

Budowanie APK jest zwieńczeniem ćwiczenia i momentem, w którym praca przestaje być tylko zadaniem w przeglądarce, a staje się prawdziwym programem na telefonie. Instalacja własnej aplikacji na własnym urządzeniu daje satysfakcję, której nie zastąpi żaden podgląd w Companion.

Plik .aia pełni rolę kopii zapasowej projektu. Bez niego ponowne odtworzenie wszystkich bloków i właściwości zajęłoby mnóstwo czasu, a w razie przypadkowego usunięcia projektu z serwisu nie byłoby czego odzyskać. Warto pobierać go regularnie, nie tylko na samym końcu pracy.

Przed budowaniem ostatni raz przejdź przez listę testów. Pakiet nie pozwala już na szybkie poprawki w czasie rzeczywistym - każda zmiana oznacza ponowną kompilację i instalację. Im lepiej dopracowana wersja przed naciśnięciem Build, tym mniej trzeba będzie powtarzać tego kroku.

Podsumowanie pokazuje, że mimo wielu slajdów całość da się streścić w kilku powtarzalnych krokach. To ważna obserwacja, bo studenci często obawiają się, że muszą zapamiętać każdy detal. Wystarczy zapamiętać kolejność myślenia: najpierw wymagania, potem wygląd, stan, logika, testy, pakiet.

Poszczególne etapy są ze sobą sprzężone na tyle, że pominięcie któregoś zwykle wraca przy testach. Brak specyfikacji prowadzi do przypadkowych przycisków, brak nazw utrudnia bloki, brak walidacji psuje testy, a brak kopii .aia naraża na utratę pracy. Każda luka w procesie ma swoją cenę, tylko nie zawsze widać ją od razu.

Najcenniejszym efektem ćwiczenia nie jest sam kalkulator, lecz nawyk pracy etapami. Student, który przejdzie tę ścieżkę raz, powtórzy ją przy quizie, grze czy aplikacji czujnikowej. Wtedy doceni, że kolejność kroków była przemyślana, a nie wymyślana na gorąco.

Pytania kontrolne nie służą tylko do powtórki - pomagają wykryć miejsca, w których rozumienie jest jeszcze powierzchowne. Jeśli student nie potrafi wyjaśnić, po co jest flaga nowyWpis, prawdopodobnie skopiował bloki bez zrozumienia stanu programu. Lepiej wrócić do tego teraz, niż powielać błąd w kolejnych projektach.

Zadanie praktyczne jest celowo otwarte: wymaga zastosowania poznanej mechaniki w nowej sytuacji. Dodanie przycisku zaokrąglania obejmuje zmianę interfejsu, nowe zdarzenie Click i użycie bloku z szuflady Math - czyli pełen cykl pracy, ale w małej skali.

Warto dopisać do tabeli testów nie tylko oczekiwany wynik poprawny, ale też zachowanie po zaokrągleniu wyniku pośredniego. Dzięki temu student zobaczy, że testy nie kończą się na jednym ptaszku, lecz obejmują też wpływ zmiany na resztę aplikacji.

Zakończenie ćwiczenia jest dobrym momentem, by spojrzeć na całość z dystansem. Od pustego ekranu do działającej aplikacji na telefonie prowadziła nas ściśle określona ścieżka, a każdy etap miał swoje uzasadnienie. Dzięki temu kalkulator nie jest zbiorem luźnych bloków, tylko spójnym programem o jasnej strukturze.

Najważniejsze pojęcia z tego ćwiczenia - zmienna stanu, zdarzenie Click, warunek, walidacja i formatowanie - powrócą w każdym kolejnym projekcie. Warto je zapamiętać wraz z momentem, w którym się ich używa, a nie tylko jako suche definicje.

Zachęcam do samodzielnej rozbudowy kalkulatora o wybrane rozszerzenia, a potem do powtórzenia całego schematu dla innej aplikacji, na przykład prostej gry w zgadywanie liczby. Im częściej przejdzie się tę ścieżkę od początku do końca, tym bardziej stanie się ona naturalna i szybka.