Zmiana paradygmatu, czyli o GUI słów kilka

Mały paradoks oprogramowania

Należę do grupy osób skoncentrowanych wyłącznie na funkcjonalności. W swojej pracy zawsze staram się korzystać z jak najbardziej ogólnych wzorców projektowych. Dzięki temu, pod napływem "chwili olśnienia", znaleźć można nowe zastosowanie dla wysłużonych już produktów bądź tych części programu, które - po nieznacznej tylko modyfikacji - mogłyby funkcjonować całkiem udanie na innym polu, w innej gałęzi gospodarki. Programista też człowiek, więc nierzadko zdarza się, że pewne przyjęte przez niego (i przeze mnie) wzorce można zamienić na inne, sprawniejsze, a wszystko to co było dawniej po prostu wyrzucić do kosza.

Z GUI sprawa wygląda nieco inaczej. Choć osobiście nie wykorzystuję tanich chwytów marketingowych z numerkiem lub z nowymi ikonkami to jednak uważam, że interfejs graficzny odgrywa kluczową rolę w procesie przygotowywania oprogramowania. Zawsze uważałem, że interfejsem graficznym powinni się zajmować graficy, tak jak programowanie leży w gestii programistów. Problem jest jednak bardziej złożony i często to na barkach programisty spoczywa obowiązek wykonania "atrakcyjnego interfejsu". Kiedy tak się dzieje, cierpią na tym wszystkie te aspekty oprogramowania, na które nie można było poświęcić więcej czasu (m.in. wydajność i niewłaściwe działanie w wyjątkowych sytuacjach). Katastrofa.

Programista zajmuje się GUI

W dzisiejszym świecie nie ma miejsca dla brzydkich produktów. Wszystko powinno być ładne a priori. Znając tę "najprawdziwszą z prawd" programista często sięga po rozwiązania firm trzecich, które przy pomocy jednego magicznego przycisku (albo jednej linijki kodu) zmieniają standardowe okienka i nieatrakcyjne "kontrolki" w świecące, kolorowe atrakcje. Mowa tu o czymś co nazywamy potocznie skórkami. Niejednokrotnie same skórki nie świecą już wielkim przykładem geniuszu. Wtedy implementujemy nieco inne rozwiązania. W przypadku platformy .NET taką alternatywą dla Windows Forms jest technologia Windows Presentation Foundation wespół z językiem XAML. Zainteresowani bez trudu znajdą informacje na ich temat, więc nie poruszę tu kwestii za i przeciw tym rozwiązaniom.

Obecnie prawie każda pełnoprawna platforma programistyczna wspiera w pewnym zakresie wysiłki programistów mające na celu uatrakcyjnienie wyglądu projektowanych aplikacji. I choć cel jest słuszny - w mojej opinii wiele z nich idzie drogą pełną anachronizmów i sprzeczności.

• Wygląd kosztem nauki nowego języka opisującego interfejs użytkownika (na przykładzie XAML)?
• Narzędzia przeznaczone tylko i wyłącznie do budowy GUI eksportujące serię nic nie mówiących (niewtajemniczonym) znaczników?
• Dwucyfrowy wzrost zużycia cennych zasobów komputera kosztem kilku bajeranckich (jak dla kogo) okienek?

Proszę...

Pewnego razu w Menedżerze zadań

Do czego służy Menedżer zadań wiedzą chyba wszyscy. Poza nim istnieje szereg narzędzi obrazujących i rejestrujących pracę aplikacji w systemie Windows (na przykład wbudowany Monitor wydajności, w skrócie perfmon). Zużycie zasobów nowych wersji oprogramowania z reguły ma tendencję wzrostową i każdy ma możliwość sprawdzenia tego faktu. Dzieje się tak przeważnie tuż po wprowadzeniu widocznych zmian w interfejsie graficznym aplikacji. Inaczej jest natomiast gdy programista swoją uwagę skupia na problemie wydajności. Wtedy prawie każda zmiana pozytywnie wpływa i reguluje zasobożerność oprogramowania. Od powyższego zawsze są wyjątki, ale jak wiadomo nieliczne. Wszyscy znamy przecież aplikacje, które po pewnym czasie obecności na rynku stają się po prostu "bloated".

Do pamiętnego dnia wykorzystywałem zbiór popularnych bibliotek pozytywnie wpływających na wygląd wdrażanych aplikacji .NET. Krzywdzącym byłoby podanie nazwy producenta tego pakietu, więc pominę ją milczeniem. Istotnym jest bowiem fakt, że posiadając deweloperską licencję zawsze mogłem i nadal mogę liczyć na szybkie wsparcie techniczne i miłą obsługę. Niemniej z wersji na wersję, mimo pozytywnego - wizualnie - postępu, zasobożerność (tu zużycie pamięci) wykorzystywanych komponentów wzrastała co najmniej liniowo. Podczas gdy standardowa aplikacja wykorzystująca jedynie wbudowane w .NET komponenty zużywała niewiele ponad 15MB pamięci operacyjnej, to już samo puste, nic nie robiące okienko w technologii "skórek" zużywało jej 40MB. Rozumiem, że postęp technologiczny jest nieunikniony, ale będąc osobą w pewnym sensie ukształtowaną przez system z rodziny AmigaOS i mając na względzie obecne cztero- i pięcioletnie komputery osobiste typu PC i klasy "refurbished", nie mogłem nad taką sytuacją przejść obojętnie. "Bo później Pani Jadzia narzeka, że jej komputer działa wolno...". Skórki poszły do kosza. Bynajmniej w większości przypadków. A dalej było tak...

Stare pomysły w nowym wydaniu

Wykorzystanie WPF i XAML w nowych projektach byłoby ryzykownym przedsięwzięciem, biorąc pod uwagę ówczesną (i obecną) politykę Microsoftu. Poza tym wiązałoby to się z koniecznością współpracy z grafikiem znającym się na "tej dziwnej rzeczy". Kiedy na drodze programisty pojawiają się przeciwności, rozsądek karze uprościć problem i szukać odpowiedzi w oczywistym miejscu. I choć tym razem Microsoft Developer Network nie przyniósł upragnionej odpowiedzi to jednak sama technologia służąca jej poznaniu była strzałem w dziesiątkę.

Trident (czyt. Internet Explorer), jakiżby inny komponent systemu, czy to wbudowany czy doinstalowany lepiej miałby spełniać rolę ze wszechmiar modyfikowalnego GUI dowolnej aplikacji. I choć użyłem tu konkretnej nazwy nie bez powodu Ty sam możesz przywołać zupełnie inną np. Webkit (czyt. Chrome, Safari) lub Gecko (Firefox) oraz wiele innych.

Przeglądarka internetowa to podstawowe narzędzie pracy interauty i zawiera (to prawda!) doskonale zoptymalizowany silnik wyświetlający interaktywne (dynamiczne) treści. Mając za sobą wyczekiwany od dawna upadek IE6 powoli nastaje czas spokoju i "wspólnych standardów". Akceleracja sprzętowa zaimplementowana w silnikach popularnych przeglądarek a co za tym idzie coraz szybsza obsługa JavaScript, ale także obsługa SVG czy HTML5 - to wszystko sprawia, że powtórne wykorzystanie komponentów umożliwiających osadzanie odpowiednio spreparowanych stron internetowych, pełniących tu rolę wyłącznie interfejsu użytkownika w aplikacjach windowsowych (ale także i linuksowych), to czysta przyjemność. Co więcej, separując interfejs graficzny aplikacji (wykonany chociażby w HTML'u z domieszką jQuery) od właściwego kodu źródłowego przy użyciu specjalnie skonstruowanych klas opakowujących zyskujemy naprawdę dużą swobodę. Zmiany interfejsu graficznego mogą być wtedy dowolne i jedynie w znikomym stopniu wpływają właściwą część tworzonego przez nas programu. Komunikacja pomiędzy typowym kodem a stroną (GUI) przebiega w niezwykle prosty i klarowny sposób a samą oprawę wizualną jest w stanie przygotować każdy porządny grafik internetowy znający podstawy HTML i JavaScript. A takich osób na rynku wiele, więc można skoncentrować się na jakości a nie dostępności wykształconych jednostek. Zużycie zasobów tak przygotowanego GUI w porównaniu do tradycyjnych skórek jest niewielkie a możliwości rozbudowy niczym nieograniczone.

Oczywiście to od producenta danego komponentu zależy czy sprawnie będzie zachowywał się w środowisku produkcyjnym, ale nie oszukujmy się: przeglądarki internetowe (ich silniki) znajdują się pod stałą presją milionów użytkowników, tu wszystko musi grać jak należy. Nie ma mowy o technologicznym zastoju.

Na koniec - idziemy z duchem czasu. Ostatnio coraz więcej mamy przecież usług "web-enabled" - oczywiście nie w tym sensie :) Ale mówiąc szczerze, obserwując wielkich graczy rynku IT, właśnie w tym kierunku zmierzamy!

Wykorzystanie silnika Trident (klasa WebBrowser) w aplikacjach Windows Forms: http://msdn.microsoft.com/en-us/library/a0746166.aspx Całkiem udana implementacja Chromium (Awesomium) umożliwiająca tworzenie GUI opartego na HTML: http://awesomium.com/

P.S. Zdaję sobie sprawę, że nie we wszystkich przypadkach taki interfejs się sprawdza. Niemniej polecam tego typu rozwiązania... i pozdrawiam wszystkich, którzy dotrwali do końca.