Ograniczone zasoby systemowe urządzeń to podstawowy problem twórców aplikacji dla komputerów naręcznych. Konieczność minimalizacji objętości aplikacji, optymalizacji jej interfejsu i wydajności przypomina sytuację programistów komputerów PC sprzed 10, 20 lat.

Wielu programistów piszących aplikacje mobilne twierdzi, że ich praca niewiele różni się od programowania komputerów PC. Trudno jednak nie zauważyć, że o problemach, z którymi muszą się oni zmagać na co dzień, programujący komputery PC dawno już zapomnieli. Dwie dekady temu Bill Gates twierdził, że 640 KB pamięci operacyjnej powinno wystarczyć każdemu. Chociaż dzisiaj komputery naręczne oferują kilka razy większą ilość pamięci, problemy programistów PC sprzed wielu lat pozostają nadal aktualne. Twórcy aplikacji dla komputerów naręcznych muszą oszczędnie gospodarować zasobami urządzeń, decydować się na kompromisy między wielkością aplikacji a jej wydaj- nością i uwzględniać relatywnie małą prze- pustowość łączy, za pośrednictwem których wykonywana jest synchronizacja danych.

Ciasny ekran

Zapytani o specyfikę pisania aplikacji dla komputerów naręcznych, programiści jako pod-stawowe utrudnienie wymieniają niewielkie rozmiary ekranów. Komputery Palm są wyposażone w wyświetlacze o wymiarach zaledwie 160 x 160 pikseli. Nawet jednak większe ekrany komputerów Pocket PC (320 x 240 pikseli) zmuszają do precyzyjnego i przemyślanego tworzenia interfejsu użytkownika.

Wybór sposobu prezentacji danych na urządzeniach z niewielkimi wyświetlaczami nie jest łatwy. Interfejs aplikacji biznesowej musi być jak najprostszy, wygodny w użyciu, a przy tym zapewniać użytkownikom funkcjonalność niezbędną do realizacji ich zadań. Jeśli wymagania te nie zostaną spełnione, użytkownicy będą tracić czas na obsługę urządzenia - a cel jego zastosowania jest wręcz przeciwny. "Niewielkie rozmiary wyświetlacza z pewnością są kłopotliwe, ale trudność jego obsługi ma również swoje dobre strony. Programista musi bowiem zwrócić szczególną uwagę na zaprojektowanie wygodnego interfejsu, który przede wszystkim nie może być przeładowany informacjami. Niemalże na pierwszy rzut oka widać również, czy programiście udało się osiągnąć sukces i czy interfejs rzeczywiście jest łatwy w użyciu" - mówi Konrad Spociński z firmy Noblestar, oferującej m.in. rozwiązania mobilne.

Trudność nie ogranicza się wyłącznie do zaprojektowania wyglądu interfejsu, ale również takiej organizacji sposobu wprowadzania informacji, by użytkownik nie musiał wprowadzać zbyt wielu znaków z wykorzystaniem rysika. W warunkach terenowych jest to po prostu niewygodne i czasochłonne. Częstym rozwiązaniem jest tworzenie zestawu rozwijanych list, z których użytkownik wybiera przygotowane wcześniej pozycje, uzupełniając je jedynie danymi liczbowymi.

Warto również, o ile pozwala na to interfejs aplikacji, zaprojektować nieco większe przyciski, co umożliwiłoby użytkownikom wybieranie opcji na ekranie dotykowym bezpośrednio palcem (bądź paznokciem) zamiast rysikiem.

Nadzieja na standard

Chociaż standardowe wyposażenie komputerów naręcznych stale jest rozszerzane, to jednak ze względu na relatywnie małe zasoby pamięci i wydajność procesora programista musi zwykle również iść na trudny kompromis między wydajnością i funkcjonalnością aplikacji a jej wielkością. Cechy te rzadko bowiem idą w parze. Wprawdzie najnowsze modele urządzeń pozwalają na wykorzystanie dodatkowych kart pamięci, co teoretycznie znosi istotne ograniczenie, dotyczące objętości aplikacji, to jednak implementacja obsługi takich kart wpływa na złożoność aplikacji i komplikuje jej architekturę.

Dotychczas poważnym problemem pozostawał brak jednego standardu, którego efektem był m.in. brak możliwości przenoszenia aplikacji między różnymi systemami czy nawet kolejnymi modelami urządzeń z tej samej serii. Stworzenie aplikacji, która mogłaby być uruchamiana zarówno na komputerach pracujących pod kontrolą Palm OS, jak i Windows CE, w praktyce sprowadzało się do zatrudnienia dwóch programistów specjalizujących się w rozwiązaniach dla tych systemów. "Na rynku komputerów PC liczy się tylko jeden system: Windows. W świecie systemów operacyjnych dla urządzeń mobilnych znaczących graczy jest kilku" - twierdzi Konrad Spociński.

Sytuacja stopniowo się jednak zmienia. "Obecnie rynek zmierza ku temu, by możliwe było pisanie jednego kodu i uruchamianie go na różnych urządzeniach, wyposażonych w różne systemy operacyjne. Takim standardem mogłaby stać się np. platforma J2ME (Java 2 Micro Edition). Wówczas potrzebna byłaby jedynie wirtualna maszyna Javy dla danego typu komputera naręcznego. Dostępne są już nawet telefony GSM z maszyną Javy" - mówi Leszek Smoliński, kierownik Centrum Kompetencyjnego ds. Systemów Dystrybucyjnych w Procter & Gamble Polska. Firma tworzy oprogramowanie, wspierające pracę handlowców dla kilkuset komputerów Palm. Obecnie zespół tworzący aplikację zastanawia się nad opracowaniem jej w technologii Java. Standardem wymiany informacji między różnymi typami komputerów naręcznych a systemami korporacyjnymi ma szansę stać się XML.

Oczywiście aplikacje pisane w Javie, uruchamiane na platformach mobilnych, podlegają takim samym prawom, jak wszelkie inne aplikacje. Ponadto na ich pracę może mieć wpływ wydajność i poprawność pracy maszyny wirtualnej - podobnie jak w przypadku komputerów PC.

Kłopotliwa synchronizacja

Komputery naręczne w biznesowych zastosowaniach stanowią przedłużenie systemów informatycznych korporacji, toteż konieczna jest okresowa dwukierunkowa synchronizacja przechowywanych na nich informacji z aplikac-jami firmowymi. Synchronizację taką można przeprowadzać na wiele sposobów: za pośrednictwem podstawki połączonej z kompute-rem stacjonarnym interfejsem szeregowym lub USB, za pośrednictwem lokalnej sieci Ethernet, analogowej komunikacji modemowej lub bezprzewodowej komunikacji GSM. W każdym przypadku inna jest przepustowość wykorzystywanych do tego celu łączy, co znacząco wpływa na czas replikowania danych.

W zależności od typu aplikacji, ilości generowanych przez nią danych oraz podstawowego sposobu dostępu do sieci korporacyjnej programista musi właściwie sam zaprojektować proces synchronizacji informacji. Dostępne obecnie sposoby komunikacji bezprzewodowej GSM nie oferują rozbudowanych możliwości transmisji danych (standardowo 9,6 Kb/s lub kilkakrotnie więcej w HSCSD lub GPRS). Presja na skrócenie czasu synchronizacji wymusza więc minimalizację ilości replikowanych danych.

Ponadto programista, tworzący rozwiązania dla wielu platform mobilnych, musi liczyć się z tym, że synchronizacja danych między komputerami PC a komputerami naręcznymi różnych platform rządzi się różnymi prawami.

Pisz i testuj

Podobnie jak programiści komputerów PC, twórcy aplikacji dla komputerów naręcznych mają duży wybór narzędzi programistycznych i języków programowania. Najczęściej wykorzystują języki C i Visual Basic. Nie brak również narzędzi graficznych, umożliwiających tworzenie interfejsów użytkownika ekranów z użyciem gotowych komponentów.

Podstawowym narzędziem dla programistów platformy Windows CE jest pakiet Microsoft Embedded Tools. Zawarte w nim narzędzia umożliwiają dodatkowo łatwe przenoszenie fragmentów kodu między kompilatorem dla komputerów PC a kompilatorem dla komputerów naręcznych.

W przypadku komputerów Palm najpopularniejszym środowiskiem jest CodeWarrior firmy Metrowerks. Najnowsza wersja tego pakietu - CodeWarrior 7.0 - pozwala na tworzenie aplikacji dla urządzeń działających pod kontrolą systemu Palm OS bez względu na wykorzystywany w urządzeniu procesor. Dotychczas większość środowisk umożliwiała tworzenie aplikacji tylko dla wybranego typu procesora, np. Motorola DragonBall, PowerPC lub MIPS. Programiści zwracają jednak uwagę, że narzędzia Microsoftu są dostępne bezpłatnie. Natomiast CodeWarrior jest produktem komercyjnym. Jego cena wynosi 370 USD.

Do testowania tworzonych aplikacji nie jest konieczne posiadanie komputera naręcznego. Jego funkcje z powodzeniem może pełnić emulator pracujący na komputerze PC. Tym, o co musi zatroszczyć się każdy programista, jest przetestowanie aplikacji we wszystkich środowiskach, w których będzie ona uruchamiana, co można uczynić z wykorzystaniem jednego emulatora, wczytując tylko do niego różne ROM-y - pliki zawierające środowisko operacyjne konkretnego urządzenia w konkretnej wersji systemu operacyjnego.

Alternatywą wobec samodzielnego testowania aplikacji jest skorzystanie z pomocy specjalizujących się w tym laboratoriów. Przykładowo, firma Ericsson w ramach programu Świat Aplikacji udostępnia firmom tworzącym mobilne aplikacje (głównie dla telefonów komórkowych) swoje laboratorium testowe, w którym można symulować cały system: klienta, sieć transmisyjną oraz serwer.