Podręcznik referencyjny: Aplikacje mobilne

Niniejszy artykuł ma służyć jako przewodnik i materiał referencyjny do tworzenia aplikacji mobilnych. Aplikacje mobilne to takie aplikacje z interfejsem użytkownika, których docelową platformą nie jest typowy komputer stacjonarny czy laptop, lecz urządzenie mobilne, jak na przykład smartfon.

Tworzenie aplikacji mobilnych odbywa się generalnie według tego samego modelu programowania i w tym samym środowisku deweloperskim, co tworzenie aplikacji z interfejsem użytkownika na komputery stacjonarne. W związku z tym, niniejszy artykuł koncentruje się na wymaganiach i różnicach, które są specyficzne dla aplikacji mobilnych.

Grupa docelowa

• Programiści
• Konsultanci techniczni

Wprowadzenie

Aplikacje mobilne to aplikacje zaprojektowane specjalnie do użytku na urządzeniach mobilnych. W ramach tego artykułu, przez urządzenia mobilne należy rozumieć przede wszystkim współczesne smartfony, ponieważ stają się one coraz bardziej popularne i wydajne. Smartfony łączą funkcjonalność telefonu i PDA (komputera przenośnego) w jednym urządzeniu, które użytkownik zawsze ma przy sobie. Dzięki zintegrowanym czujnikom i niemal powszechnemu dostępowi do sieci, smartfony stały się platformą dla niemal każdego rodzaju aplikacji.

Jednakże, te odnoszące sukcesy aplikacje nie są po prostu mniejszymi wersjami istniejących aplikacji desktopowych, ale często zupełnie nowo stworzonymi aplikacjami do zadań, których użytkownicy potrzebują w specyficznym kontekście mobilnym. W przeciwieństwie do komputera, z którego korzysta się przez wiele godzin w pracy do wykonywania obszernych zadań, smartfony są używane najczęściej do szybkiego odszukania konkretnych informacji. W związku z tym, kluczowe jest, aby użytkownicy mogli w jak najbardziej intuicyjny i wydajny sposób dotrzeć do potrzebnych im informacji.

Inne ważne warunki ramowe dla aplikacji mobilnych to oczywiście mniejszy rozmiar ekranu oraz model obsługi zoptymalizowany pod ekrany dotykowe. W przypadku urządzeń z ekranami dotykowymi, wszystkie elementy sterujące muszą być wystarczająco duże, aby można je było obsługiwać pewnie palcem. Dla najpopularniejszych rozmiarów ekranów oznacza to maksymalnie około 10 wierszy lub maksymalnie 5 przycisków na wiersz. Dlatego, podczas tworzenia aplikacji mobilnych, niezbędne jest zidentyfikowanie naprawdę ważnych i najczęściej potrzebnych informacji oraz odpowiednie ustrukturyzowanie interfejsu. Rzadko potrzebne informacje lub akcje powinny być przenoszone na osobne ekrany lub całkowicie pomijane.

W większości przypadków, aplikacje mobilne są wykorzystywane do przeglądania informacji, a nie do wprowadzania lub modyfikowania nowych danych. Aplikacje mobilne powinny jak najdokładniej rozdzielać tryby wyświetlania oraz zmiany/wprowadzania danych, na przykład za pomocą osobnego okna dialogowego edycji, które musi być jawnie otwierane za pomocą przycisku [Edytuj]. Takie podejście jest zalecane, ponieważ w trybie wyświetlania wszystkie puste pola są automatycznie ukrywane, a w trybie edycji ukrywane są pewne właściwości pól, przykładowo linki. Ponadto, edytowalne pola mogą łatwiej prowadzić do błędnych operacji, ponieważ urządzenia nie zawsze potrafią jednoznacznie rozpoznać, czy użytkownik chciał ustawić kursor w polu, czy przewinąć stronę.

Technologia

Producenci smartfonów korzystają z różnych technologii do programowania aplikacji mobilnych. Oprócz programowania natywnego, przykładowo w Objective-C/iOS lub Java/Android, oferują także możliwość tworzenia aplikacji w HTML, CSS i JavaScript, a następnie wyświetlania ich w przeglądarce urządzenia. W przeciwieństwie do aplikacji natywnych, umożliwia to stosunkowo łatwe tworzenie aplikacji wieloplatformowych. Co więcej, to podejście uniezależnia dewelopera aplikacji od tak zwanych App-Stores danego producenta.

Aplikacje oparte na HTML/JavaScript mają pewne ograniczenia w porównaniu do aplikacji natywnych, na przykład zazwyczaj nie mają dostępu do czujników lub danych urządzenia. Istnieją jednak już propozycje rozszerzeń dla HTML5, które mają standaryzować odpowiednie interfejsy.

Z perspektywy systemu ERP, dla urządzeń mobilnych stosowana jest zasadniczo ta sama technologia co dla komputerów klienckich z Internet Explorerem. W obu przypadkach generowana jest dynamiczna strona HTML z CSS i JavaScript, w której działają poszczególne aplikacje ERP. W przypadku urządzeń mobilnych wewnętrznie używany jest jedynie specjalny silnik renderujący, który zapewnia niezbędne dostosowania do urządzeń i ich przeglądarek.

Tworzenie aplikacji

Pod względem tworzenia aplikacji, istnieją tylko niewielkie różnice między aplikacjami mobilnymi a standardowymi, desktopowymi aplikacjami. W obu przypadkach są to CisUiApplications, które można programować w ten sam sposób. Dotyczy to nie tylko programowania, ale także możliwości dostosowywania interfejsu, tłumaczenia, dostarczania, rozszerzania (aplikacje/hooki), itd.

Zasadnicza różnica polega na specjalnym silniku renderującym, który jest używany przy dostępie z urządzeń mobilnych. Podczas gdy przy dostępie za pomocą przeglądarki desktopowej wszystkie elementy interfejsu użytkownika są prezentowane w swojej standardowej wizualizacji, przy dostępie przez przeglądarkę mobilną używany jest widok dostosowany do smartfonów. Zmiana ta dotyczy nie tylko formy i funkcji poszczególnych elementów interfejsu, ale także całej aplikacji.

Specjalny silnik renderujący wprowadza jednak pewne ograniczenia i wymagania dotyczące programowania interfejsu użytkownika aplikacji mobilnych. Przykładowo, silnik renderujący nie obsługuje wszystkich elementów interfejsu, a niektóre właściwości elementów są z góry ustalone.

To, czy aplikacja z interfejsem użytkownika jest oferowana na urządzeniach mobilnych, zależy od ustawień w powiązanym obiekcie deweloperskim Aplikacja. W polu wyboru Ustawienia prezentacji i utrzymania należy wybrać wartość Urządzenia mobilne lub Wszystkie urządzenia. Możliwe jest więc stworzenie jednej aplikacji, która może być używana zarówno na komputerach stacjonarnych, jak i na smartfonach. W przypadku aplikacji, które można dostosowywać, można nawet zdefiniować różne widoki do użytku na komputerach stacjonarnych i smartfonach.

Zasadniczo jednak należy założyć, że wymagania merytoryczne i model obsługi dla tych typów aplikacji różnią się na tyle, że lepiej jest tworzyć dwie oddzielne aplikacje. Niezależnie od tej decyzji, wewnątrz aplikacji lub komponentów aplikacji można sprawdzić, w jakim kontekście jest ona używana. Przykładowo, EditorFactory może tworzyć różne edytory dla komputera stacjonarnego i smartfona. Odpowiednich informacji dostarcza SessionType, który można pobrać z klasy CisEnvironment.

Możliwość dostosowania

Aplikacje mobilne nie różnią się pod względem możliwości dostosowywania od innych aplikacji z interfejsem użytkownika. To, czy i które części aplikacji można dostosować, zależy od decyzji dewelopera, który dokonuje odpowiednich ustawień w obiekcie deweloperskim Aplikacja, dołącza DataViews oraz konfiguruje zaprogramowane elementy interfejsu (np. za pomocą VisualElement#setCustomizabe). Podobnie jak w przypadku wszystkich aplikacji z interfejsem użytkownika, które można dostosowywać, modyfikacja interfejsu odbywa się w trybie projektowania. Aplikacje muszą być w tym celu otwierane w sesji dialogowej, ponieważ dostosowywanie bezpośrednio na urządzeniu mobilnym nie jest możliwe. Otwieranie aplikacji mobilnych musi odbywać się ewentualnie z powiązanego obiektu deweloperskiego Aplikacja, ponieważ aplikacje mobilne nie są wyświetlane w nawigatorze (menu użytkownika).

W zależności od konfiguracji w obiekcie deweloperskim Aplikacja, można tworzyć widoki przeznaczone dla komputerów stacjonarnych, smartfonów lub obu typów urządzeń. Jeśli aplikacja z możliwością dostosowania jest dozwolona dla wszystkich urządzeń, w trybie projektowania podczas tworzenia nowego widoku można wybrać żądany typ.

Interfejs użytkownika

Interfejs użytkownika jest zorganizowany w poszczególne strony (widoki). Taka strona zawsze wypełnia całą powierzchnię ekranu, ale może być również większa w pionie (co wymaga przewijania). Aplikacja może składać się z jednej lub wielu takich stron. Zazwyczaj strony są ustrukturyzowane hierarchicznie i służą do grupowania szczegółowych informacji. Same aplikacje są zorganizowane przez nadrzędną aplikację ramową, która prezentuje się również jako strona startowa.

Strona startowa

Dostępne aplikacje są prezentowane na stronie startowej (Home) w postaci przycisków i można je otworzyć, po prostu dotykając ich. Aby ułatwić dostęp do często lub ostatnio używanych aplikacji, strona startowa jest podzielona na sekcje: Ulubione, Historia oraz Wszystkie aplikacje.

• Ulubione — sekcja zawiera listę aplikacji, które zostały przez użytkownika zapisane jako Ulubione
• Historia — w sekcji wyświetlane są ostatnio otwierane aplikacje. Aplikacje, które już znajdują się na liście ulubionych, są automatycznie pomijane w historii.
• Wszystkie aplikacje — sekcja grupuje wszystkie dostępne aplikacje według ich przynależności do obszaru, umieszczając je na oddzielnych podstronach

Pasek nawigacji

W górnej części ekranu znajduje się pasek nawigacji. Zazwyczaj wyświetla on opis (tytuł) aktualnie przeglądanego widoku. Dodatkowo, pasek nawigacji może zawierać jeden lub więcej elementów sterujących. Elementy te, w zależności od widoku, mogą służyć do nawigacji między różnymi widokami lub do sterowania zawartością.

Aplikacje

Strona startowa lub główna każdej aplikacji ma specjalny pasek nawigacji. Oprócz tytułu, mogą być w niego wbudowane także pole identyfikacyjne oraz inne elementy sterujące.

Tytuł

W górnej części paska nawigacji wyświetlana jest nazwa bieżącej aplikacji wraz z nazwą systemu. Odpowiada to informacjom, które w aplikacjach desktopowych są widoczne na pasku tytułu okna przeglądarki.

Pola identyfikacyjne

Identyfikacja aktualnie otwartego obiektu jest wyświetlana w polu identyfikacyjnym. Pole to, o ile aplikacja na to pozwala, może być również wykorzystywane do bezpośredniego wprowadzania identyfikacji, na przykład w celu otwarcia konkretnego obiektu.

Zazwyczaj pole identyfikacyjne to EntityField, ale mogą być używane również inne typy pól.

Pole identyfikacyjne musi zostać dostarczone przez aplikację poprzez dodanie wybranego pola jako jedynego do IndentPane obiektu CisUiApplication. Jeśli IndentPane zawiera więcej niż jedno (widoczne) pole, infrastruktura wybiera po prostu pierwsze (widoczne) pole. Wszystkie pozostałe pola z IndentPane nie pojawiają się na interfejsie.

• Odświeżanie — przycisk [Aktualizuj] jest połączony z LoadAction obiektu MainCoolBars i ma taką samą funkcjonalność jak w aplikacjach desktopowych, tzn. odświeża dane bieżącej aplikacji lub otwiera obiekt o identyfikacji wpisanej w polu identyfikacyjnym. W aplikacjach z polem identyfikacyjnym przycisk [Aktualizuj] jest wizualnie zintegrowany z polem, w przeciwnym razie znajduje się po prawej stronie paska nawigacji.

• Wyszukiwanie — jeśli aplikacja udostępnia pole identyfikacyjne, a to pole ma wartości wspomagające (SearchManager), to po prawej stronie paska nawigacji automatycznie pojawia się przycisk wyszukiwania. Po wybraniu tego przycisku otwiera się okno dialogowe wyszukiwania.
• Dodawanie — za pomocą przycisku [Dodaj], bieżącą aplikację można dodać do ulubionych

Pasek narzędzi

Pasek narzędzi (Toolbar) jest częścią aplikacji ramowej i znajduje się u dołu każdej aplikacji (głównego widoku).

• [Wstecz] — przycisk przewija wstecz ostatnio otwarte obiekty
• [Dalej] — przycisk działa przeciwnie do przycisku [Wstecz]
• [Ekran startowy] — przycisk przenosi użytkownika do strony startowej
• [Inne akcje] — za pomocą przycisku dostępne są akcje, których ze względu na ograniczoną przestrzeń nie można umieścić bezpośrednio na pasku narzędzi. Lista możliwych w danej chwili akcji pojawia się w specjalnym panelu (Action sheet), który wysuwa się od dołu, zasłaniając bieżącą aplikację. To, jakie akcje są oferowane na liście, zależy od aktualnie używanej aplikacji. Obszar analizuje w tym celu pasek narzędzi MainCoolBar aplikacji i pobiera z niego określone akcje (Actions) do listy. Pierwszym kryterium wyboru akcji jest ich Action-ID. Z akcji standardowych przenoszone są tylko te o identyfikatorach CREATE, UPDATE, EDIT, DELETE i EXIT. Dodatkowo, uwzględniane są wszystkie akcje specyficzne dla danej aplikacji, których identyfikatory mieszczą się w zakresie od 1 do 9999. Drugim kryterium jest stan akcji. Przenoszone są tylko akcje widoczne i aktywne. Szczególnym przypadkiem jest strona startowa. Zamiast akcji Zamknij (EXIT), oferowana jest tam akcja Wyloguj. Akcja Anuluj jest dodawana automatycznie – umożliwia ona użytkownikowi zamknięcie listy i powrót do aplikacji, jeśli przypadkowo wybrał przycisk [Inne akcje].

• [Otwarte aplikacje] — przycisk otwiera listę wszystkich aktualnie otwartych aplikacji. Przełączenie się na wybraną aplikację następuje po wybraniu odpowiedniego wpisu na liście.

Okna dialogowe

Okna dialogowe i wyskakujące okienka są wyświetlane na osobnej stronie ekranu. Natomiast komunikaty i okna dialogowe potwierdzenia są umieszczane jako półprzezroczyste wyskakujące okienka nad wcześniej aktywną stroną ekranu.

Wszystkie okna dialogowe i wyskakujące okienka są automatycznie wyposażane w przycisk [Wstecz]. Mogą też mieć własne przyciski. W tym celu okno dialogowe musi zawierać ButtonBar, która może mieć maksymalnie dwa przyciski (akcje). Jeśli ButtonBar zawiera własny przycisk CANCEL lub CLOSE, zastępuje on standardowy przycisk [Wstecz] w lewym górnym rogu paska nawigacji. Jeśli ButtonBar zawiera przycisk, który nie odpowiada ani CANCEL ani CLOSE, zostanie on umieszczony po prawej stronie paska nawigacji. Wszystkie pozostałe przyciski są ignorowane.

Komunikaty

W przeciwieństwie do aplikacji desktopowych, w aplikacjach mobilnych nie ma paska komunikatów ani paska stanu. Zamiast tego, komunikaty o błędach i ostrzeżenia są wyświetlane w wyskakującym okienku. W przypadku komunikatów o błędach dotyczących konkretnego pola, pole to jest dodatkowo podświetlane.

Okna dialogowe potwierdzenia

Okna dialogowe potwierdzenia (klasa com.cisag.pgm.gui.ConfirmationDialog) są traktowane w szczególny sposób i otwierają się jako wyskakujące okienka. Przyciski są również automatycznie pobierane z ButtonBar, jednak zasady są nieco inne. ButtonBar nadal może mieć maksymalnie dwa przyciski, przy czym w przypadku dwóch przycisków, przycisk Default jest zawsze umieszczony po prawej stronie i ma nieco jaśniejszy kolor.

Pola

Wygląd pól jest specjalnie dostosowany do małej szerokości ekranu. Etykieta (Label) jest zawsze umieszczona nad zawartością pola, dzięki czemu obie te części mają jak najwięcej miejsca na szerokość.

DialogButton

DialogButton może być użyty do wyświetlania lub edycji dodatkowych szczegółów powiązanych z danym polem. Zazwyczaj, za pomocą ActionListener i DialogAction, otwiera się dodatkowy dialog lub wyskakujące okno. W zależności od tego, czy pole umożliwia inne interakcje (np. linki lub edycję), przyciskiem otwierającym dialog jest albo całe pole, albo tylko jego prawy fragment. Można to rozpoznać po kształcie i kolorze ikony strzałki.

Poprzez specjalną Property można skonfigurować pole z DialogButton w taki sposób, aby jego etykieta była wyświetlana jak pasek tytułowy w Shelf. W takim przypadku, wartość pola służy jako wstępna informacja dla dialogu. Przykładowo, jeśli dialog wyświetla listę niezapłaconych faktur, pole powinno podawać ich liczbę. Ze względu na wygląd i ograniczoną dostępną przestrzeń, powinna to być zawsze wartość całkowita (Integer).

Ustawienie tej właściwości jest obecnie możliwe tylko za pomocą klasy VisualElement z pakietu com.cisag.pgm.dialog oraz metody  setClientProperty:

Wartości pomocnicze

W edytowalnych polach, po prawej stronie, dostępny jest przycisk do otwierania wartości pomocniczych (jeśli pole ma przypisany SearchManager i nie jest zajęte przez DialogButton). Dotknięcie pola powoduje otwarcie odpowiedniego dialogu wyszukiwania.

Linki

Pola mogą być używane jako linki, które dzielą się na wewnętrzne i zewnętrzne. Linki wewnętrzne wywołują odpowiednie listenery (np. ActionListener lub MouseListener) w aplikacji, natomiast linki zewnętrzne są obsługiwane bezpośrednio przez klienta.

Linki zewnętrzne

Zawartość TextFields może być interpretowana jako link zewnętrzny, pod warunkiem, że odpowiedni Content-Type zostanie zdefiniowany w powiązanym DataDescription lub bezpośrednio za pomocą API na danym polu. Obsługiwane są URI dla stron internetowych, adresów e-mail oraz numerów telefonów. Odpowiedni schemat URI (http:, mail: bzw. tel:) jest automatycznie określany na podstawie typu zawartości. Po wybraniu takiego pola na smartfonie, przeglądarka uruchamia odpowiednią aplikację, taką jak przeglądarka internetowa, klient poczty e-mail lub aplikacja telefoniczna.

Jeśli link zewnętrzny ma być niezależny od zawartości pola, można go zdefiniować, ustawiając właściwość dla danego pola. Wymagany kod to:

WebInterface.getVisualElement(field).putClientProperty(„uri”,„http://www.comarch.de/erp”);

Wyszukiwanie

Dla wszystkich wartości pomocniczych opartych na klasie DefaultSearchManager dostępny jest ogólny dialog wyszukiwania. Umożliwia on wyszukiwanie po nazwie, a w liście wyników wyświetla znalezione rekordy wraz z ich identyfikacją, nazwą i ewentualnie znacznikiem usuwania. Atrybuty, które są brane pod uwagę, są automatycznie określane na podstawie powiązanych metadanych. Są to dokładnie te atrybuty, które w wyszukiwaniu OQL zostały sklasyfikowane jako identyfikacja, nazwa lub znacznik usuwania.

Kontenery

Jako elementy strukturalne można używać klas View, GroupBox i Shelf. Dostępne menedżery układu to: BorderLayout, BoxLayout i StandardLayout. W przypadku StandardLayout, treść jest zawsze układana w jednej kolumnie, niezależnie od rzeczywistej liczby kolumn. Ponadto, elementy z właściwością ReferenceConstraints są ignorowane.

Automatyczne ukrywanie pól i kontenerów

W celu poprawy czytelności na małym ekranie, pola i inne elementy interfejsu użytkownika są automatycznie usuwane, gdy są wyłączone lub puste i jednocześnie nieedytowalne. To zachowanie może być propagowane w górę przez całą strukturę kontenerów, co oznacza, że jeśli kontener nie zawiera żadnych elementów lub zawiera tylko ukryte elementy, sam kontener również zostanie ukryty.

GroupBox

GroupBoxy (sekcje) różnią się wyglądem, ale ich zachowanie jest takie samo jak na komputerach stacjonarnych. Tytuł jest opcjonalny, a dzięki odpowiednim odstępom i kolorystyce, nawet GroupBoxy bez tytułu mogą być używane do grupowania powiązanych informacji.

Jednakże, zagnieżdżanie GroupBoxów jest niewskazane, ponieważ ich wizualizacja nie będzie się różnić od dwóch GroupBoxów umieszczonych jeden pod drugim. Zagnieżdżanie GroupBoxów i Shelfs (lub odwrotnie) jest dopuszczalne w przypadku urządzeń mobilnych. Więcej informacji na ten temat można znaleźć w kolejnej sekcji.

Shelf

Zachowanie Shelfs (rozwijanych sekcji) na urządzeniach mobilnych różni się od ich działania na komputerach stacjonarnych. W kontenerze, do którego dodano Shelf, widoczny jest tylko jego pasek tytułowy. Dopiero po dotknięciu tego paska, właściwa zawartość Shelf staje się widoczna, ale nie na bieżącej stronie, lecz na osobnej stronie szczegółowej. Tę funkcjonalność można rozpoznać po małej strzałce znajdującej się po prawej stronie. Na stronie szczegółowej, tytuł Shelf pojawia się jako tytuł na pasku nawigacyjnym, a dodatkowo pojawia się przycisk [Wstecz], który umożliwia użytkownikowi powrót do poprzedniej strony.

W zawartości Shelfs mogą być używane nie tylko pola, ale również GroupBox i Shelfs. Umożliwia to elastyczne grupowanie treści i hierarchiczne ich rozmieszczanie na różnych stronach ekranu. Jednakże, nie należy stosować zbyt głębokich hierarchii, ponieważ z każdym poziomem nawigacja staje się dla użytkownika bardziej złożona.

Do Shelf można dodać opcjonalny element Header. W przypadku urządzeń mobilnych jest on obsługiwany tylko wtedy, gdy jest to Label z ikoną. W takiej sytuacji ikona jest dodawana na początku wiersza tytułowego.

TabbedPane

Karty nie są obecnie obsługiwane. Zamiast nich, poszczególne karty są wyświetlane jedna pod drugą jako sekcje (GroupBoxes). To uproszczone przedstawienie jest tymczasowe i nie należy go celowo wykorzystywać.

Listy

Obecnie obsługa list jest bardzo podstawowa. Obsługiwane są tylko listy w trybie tylko do odczytu. Można używać wyłącznie prostych list typu ListViews (nie ExtendedListViews), a jako menedżera układu należy stosować BoxLayout. Należy zachować ostrożność co do liczby rekordów, ponieważ brak jest przycisku paginacji (PageButton), a moc obliczeniowa i pamięć operacyjna w urządzeniach mobilnych są ograniczone. Rozsądną górną granicą jest około 50 wierszy.

Tabele

Obecnie obsługa tabel jest bardzo podstawowa. Obsługiwane są jedynie tabele w trybie tylko do odczytu, bez możliwości zaznaczania. Zaleca się, aby tabele nie miały więcej niż dwie lub trzy kolumny. Nie ma również gwarancji, że wszystkie typy pól zostaną w nich poprawnie wyświetlone. Dlatego też, na chwilę obecną, zaleca się unikanie stosowania tabel.

Wykresy

Klasa com.cisag.pgm.gui.Chart umożliwia wstawianie wykresów słupkowych i skumulowanych wykresów słupkowych do interfejsu użytkownika. Działania użytkownika, takie jak dotknięcie pojedynczego słupka na wykresie, mogą być programowo analizowane. Można je wykorzystać na przykład do wyświetlania dodatkowych, szczegółowych informacji na temat danego słupka, na przykład w postaci kolejnego wykresu.

Nieobsługiwane elementy

Następujące elementy nie są obecnie obsługiwane:

• Grafika 2D (Canvas, Shapes, Strokes, …)
• Header (tabela)
• ComboBox
• HTMLEditor
• ImageLabel
• LayeredPane
• LayeredIconField
• Menu (Menu, MenuBar, MenuManager, PoppupMenu)
• SearchView (Grid-Control)
• SmartButton
• SplitPane
• ToggleButtons
• TabbedPane
• Table
• Tree
• Upload (FileUploadElement)

Nieobsługiwane właściwości

Następujące właściwości nie są obecnie obsługiwane:

• Pozycjonowanie absolutne (x, y)
• Accesskeys
• Background (Color)
• Border
• Pomoc kontekstowa
• Drag & Drop
• Sterowanie fokusem
• Font
• Foreground (Color)
• Guides
• KeyEvents
• Margins (Insets)
• Preferowana szerokość/wysokość, minimalna szerokość/wysokość, maksymalna szerokość/wysokość
• ReferenceConstraints
• Shortcuts
• TextAttribute
• Texture (Icon)
• ToolTips
• UIManager
• Wartości pomocnicze dla wartości dziesiętnych, dat oraz dokumentów/folderów
• Schowek

Środowisko testowe

Proste testy i prezentacje można przeprowadzić za pomocą przeglądarki desktopowej opartej na silniku WebKit, takiej jak Google Chrome lub Safari. Infrastruktura rozpoznaje takie przeglądarki i rysuje wokół aplikacji ramkę w stylu iPhone’a. Pozwala to na wstępne oszacowanie proporcji i zajmowanej przestrzeni. Zmiana szerokości okna umożliwia także symulację obracania urządzenia.

Testy na rzeczywistych urządzeniach i w realnych warunkach pozostają jednak niezbędne, ponieważ symulacja na komputerze stacjonarnym nie uwzględnia w pełni kilku istotnych aspektów. Do testów należy używać zarówno urządzeń z systemem iOS, jak i Android. Poniższe kwestie powinny zostać przetestowane na każdym z urządzeń:

• Rzeczywista przestrzeń — uwzględnienie pasków przeglądarki, klawiatury ekranowej oraz rzeczywistych rozmiarów elementów
• Wydajność — uwzględnienie procesora, przepustowości i opóźnień sieci
• Ekran dotykowy — obsługa palcem, klawiatura ekranowa, przewijanie i sterowanie fokusem
• Nawigacja — nawigacja między aplikacjami

Uwagi techniczne

Obsługiwane urządzenia

Obsługa urządzeń mobilnych jest obecnie ograniczona do następujących urządzeń i platform:

• iPhone (od 3GS, iOS 4.1 lub nowszy)
• Smartfony z Android 2.2 (lub nowszy)

iPhone

Ekran główny

Przeglądarka (Safari) umożliwia zapisanie strony internetowej jako skrótu na ekranie głównym. W tym celu na dolnym pasku narzędzi Safari znajduje się przycisk [Dodaj] (oznaczony jako +). W kolejnym wyskakującym okienku należy wybrać przycisk [Do ekranu początkowego]. Następnie pojawi się dialog, w którym można wprowadzić lub zmienić nazwę skrótu. Po potwierdzeniu, skrót z nazwą i ikoną (wyglądem przypominający natywną aplikację) zostanie wyświetlony na ekranie głównym. Po uruchomieniu strony za pomocą tego skrótu, przeglądarka całkowicie ukrywa swoje własne elementy sterujące (pasek nawigacji i pasek narzędzi), dzięki czemu cała przestrzeń ekranu jest dostępna dla strony internetowej.

Dane logowania

W testowanych wersjach iOS nie było możliwe zapisanie nazwy użytkownika i hasła. Dlatego przy każdym uruchomieniu wymagane jest ponowne wprowadzenie danych.

Starsze urządzenia

Na modelu 3G często występują opóźnienia. W wersjach iOS starszych niż 4.1 występują również pewne błędy wyświetlania.

Android

Ekran główny

Na urządzeniach z systemem Android istnieje możliwość umieszczenia skrótu do strony na ekranie głównym, jednak jego wygląd zależy od interfejsu danego urządzenia lub producenta. Niestety, po uruchomieniu strony za pomocą tego skrótu, przeglądarka nadal wyświetla swoje własne elementy sterujące (pasek adresu).

Interfejsy specyficzne dla producenta

Wytwarzane przez niektórych producentów smartfony z systemem Android są wyposażone we własny interfejs i/lub alternatywne klawiatury ekranowe. Te rozszerzenia mogą niestety prowadzić do błędów wyświetlania w przeglądarce. Takie zachowanie zaobserwowano na przykład w przypadku urządzenia Desire firmy HTC z interfejsem Sense. W tym urządzeniu występują różne problemy w interakcji przewijania i edytowania zawartości pól.

Dostosowanie ekranu

Powierzchnia interfejsu dostosowuje się automatycznie do szerokości ekranu danego urządzenia, co dotyczy również obracania urządzenia z pionowej do poziomej orientacji. Zawartość dla obu orientacji jest identyczna. Różnica polega jedynie na tym, że w orientacji poziomej jest więcej miejsca na długie teksty, ale przewijanie w pionie staje się konieczne szybciej. Ten rodzaj dostosowania ekranu dotyczy również tabletów (iPad i Android).

Sesje

Urządzenia mobilne są rozpoznawane przez infrastrukturę na podstawie nagłówka User-Agent ich przeglądarki. Infrastruktura przypisuje urządzeniom mobilnym specjalny typ sesji. Dla tych sesji obowiązują następujące cechy szczególne:

• Specjalny UI (dostosowany dla mobilnych przeglądarek opartych na WebKit)
• Dla jednego użytkownika możliwy jest tylko jeden aktywny login jednocześnie. Przy ponownym lub kolejnym połączeniu, istniejąca sesja jest albo przejmowana, albo automatycznie kończona.
• Sesja jest utrzymywana przez serwer przez około godzinę w przypadku braku aktywności. Dopóki ten czas nie zostanie przekroczony, użytkownik może z łatwością kontynuować swoją pracę po przerwie lub zerwaniu połączenia.
• Dostęp z urządzeń mobilnych musi być wyraźnie dozwolony w panelu systemowym na zakładce Przyporządkowania użytkownika dla typu System