Z racji iż mam trochę wolnego czasu ostatnio, postanowiłem zająć się czymś przyjemnym. Przyjemnym – tzn. w żaden sposób niezwiązany z tworzeniem oprogramowania serwerowego (w szczególności przy pomocy narzędzi Microsoftu). Zrobiłem zatem małą rewizję moich projektów i stwierdziłem, że warto byłoby wreszcie odkurzyć PasswordManagera (który już jakiś czas temu miał zostać przemianowany oraz przebrandowany na WyPass) i zrobić z niego jakiś względnie użyteczny program do zarządzania hasłami.

Wygląd Ribbon w WPF (za UXPassion)

Ostatnio jest spora konkurencja (i do tego bardzo dobra) w tym sektorze z LastPass na czele (z którego notabene sam z wielką przyjemnością korzystam), jednak nie przejmuję się tym tak bardzo. Robię bowiem produkt przede wszystkim dla swoich potrzeb, skupiając się na funkcjonalnościach, które nie są dostępne w innych programach tego typu (albo są, ale mi się nie podobają xD).

Przy okazji aktualizowania wyglądu i funkcjonalności programu pojawił się dylemat – czy zostać przy WinForms, które było używane w poprzednich wersjach PasswordManagera, czy może zmigrować i odpowiednio upiększyć wygląd w WPF. Generalnie pomysł na wykorzystanie Windows Presentation Foundation nie był głupi i daje mi sporo ciekawych możliwości:

  • użycie wstążki (Ribbon) jako głównego elementu interfejsu użytkownika. Ribbon nie jest standardowo zawarty w WPF, ale jest dostępny w pakiecie RibbonControlsLibrary od Microsoftu.
  • sporo ułatwień w kwestii łatwości tworzenia interfejsu użytkownika
  • DataBindingi do obsługi danych
  • Profesjonalny wygląd oraz spory wybór skinów do wszystkich kontrolek (to zasługa WPFToolkit)
  • Wymuszenie stosowania ujednoliconej architektury aplikacji opartej na MVVM. Poprzednia wersja aplikacji była oparta o coś a la MVC z wieloma “brudnymi” chwytami.

Lista możliwości wydaje się być całkiem obiecująca, jednak jak wszystko ze stajni Microsoftu ma swoje duże minusy. Generalnie są 2:

  • zasobożerność i marna wydajność (o czym zresztą za chwilę)
  • beznadziejna obsługa WPF w Visual Studio 2008, oraz marna współpraca Expression Blend z Visual Studio.

Ok, już nie wygląda to tak różowo ;] No, ale nie będziemy się zrażali takimi szczegółami tylko może spróbujemy coś zaprojektować i zakodzić testowego z użyciem Ribbona, którego tak bardzo chciałem użyć ;]

Odpalamy Visual Studio 2008, wybieramy nowy projekt WPF Project, budujemy i uruchamiamy czysty projekt, by zobaczyć, że na start zużywa 18,5 MB RAMu. Cóż… sporo, biorąc pod uwagę fakt, że mój Password Manager – jako względnie rozwinięta aplikacja po uruchomieniu i po podziałaniu (po przekliknięciu wszystkiego co się dało) zajmuje… 17,8 MB. Doskonale zdaję sobie sprawę z tego, że WPF jest nieco bardziej zasobożerny, bo takie są niestety konsekwencje większej funkcjonalności, ale to jest trochę więcej niż “nieco”.

image

Ok, to zobaczmy jak się zmieni zapotrzebowanie na pamięć gdy dodamy 2 nowe biblioteki do projektu (wymagane jeśli chcemy mieć interfejs wstążkę oraz ładny wygląd interfejsu i nowe kontrolki). Ile RAMu pożera teraz? Ot, raptem 49 MB i wygląd taki jak widać po lewej stronie. W takiej sytuacji aż chciałoby się zrobić w ten sposób całą aplikację by zobaczyć ile RAMu w rezultacie będzie zżerała.

Wydajność to nie jedyny problem niestety – zostaje nam jeszcze problem narzędzi. Bowiem przy założeniach takich:

  • Visual Studio 2010 generalnie nie nadaje się do używania
  • Visual Studio 2008 to ostatnia dobra wersja VS
  • Expression Blend 4 jest bardzo dobrym narzędziem do tworzenia designu, ale bardzo marnym jeśli chodzi o pisanie kodu C#

mamy pewien problem. Mianowicie VS 2010 pozwala na względnie rozsądną obsługę WPF w designerze i dość dobrze współpracuje z Blendem (można bez problemu ten sam plik solucji otworzyć w Blendzie, popracować i wrócić do Visual Studio. Ale z racji iż VS2010 generalnie został tak uszkodzony (przez przepisanie go na WPF notabene), że nie da się z niego korzystać nawet na bardzo dobrym sprzęcie. Dlatego też stosować będę poprzednią wersję. Ta jednak nie nadaje się do obróbki wyglądu. Można co prawda edytować ten sam projekt także w Expression Blend, ale ten wykonuje migrację projektu i zapisuje go już jako projekt dla Visual Studio 2010 (argh). Żeby dalej edytować projekt w VS2008 należy zmodyfikować ręcznie plik solucji za każdym razem gdy skończyliśmy robić poprawki w Blend.

image

Głupie, niepotrzebne, irytujące, itd. Tylko u Microsoft ;]

Przy okazji stwierdziłem, że może zrobię forka swojego projektu i zamiast dalej się p****** z tymi technologiami microsoftowymi wykonam go w Qt. Dawno nie pisałem nic w C++; Qt jest dla mnie nowością, ale jeśli chodzi o jakość narzędzi deweloperskich Qt Creator i ich przydatność, to nie mają sobie równych :)

Może czas wreszcie na migrację na nieco ciekawszą platformę? :>