Niestety do tej pory nie ukazała się, żadna publiczna wersja frameworka graficznego Cascades na PlayBooka. Czy to oznacza, że nie można łatwo tworzyć aplikacji graficznych na ten tablet?

Otóż nie! Jest to najbardziej otwarta platforma, z jaką miałem do czynienia pracować i gorąco zachęcam do zabawy z nią! Posiada (oprócz oczywiście Androida) pełne wsparcie dla technologii Flash! I co ciekawe, co pokażę dalej, programy można tworzyć, łatwo, szybko i przyjemnie, a wyglądają one przy tym jak te natywne. Co najważniejsze, wszystko to ZA DARMO!

 

Czego potrzebujemy? (zalecam instalację w podanej kolejności)

• Przede wszystkim PlayBooka (lub symulatora, do pobrania tutaj), na którym będziemy się bawić.
• Adobe Flex 4.6 SDK
• PlayBook NDK 2.0 SDK
• PlayBook AIR 2.0 SDK (wskazujemy lokalizację Flex 4.6)
• FlashDevelop 4.0.1 (w ustawieniach projektu dodajemy lokalizację AIR 2.0 oraz Flex 4.6 SDK, tak aby AIR, było domyślnym; Tools ---> Program Settings –> AS3Context –> Installed Flex SDKs)

• BlackBerry Tablet OS Template dla FlashDevelop (instalacja polega na wypakowaniu wszystkiego do folderu: C:\Program Files\FlashDevelop\Projects). Szablon ten wymagał niestety kilku poprawek, które zaraz opiszę, ale lepsze to, niż pisać wszystko od zera. Teraz przynajmniej, tworząc nowy projekt dostaniemy wszystko, aby szybko utworzyć pierwszą aplikację.
• I na dokładkę coś, co po prostu umili życie oraz deployment. Instalujemy FriutBat 1.4. Na jego stronie znajduje się też mały przewodnik o tym, co jak i gdzie. Jedyne, co jest istotne to znowu, lokalizacje SDK oraz adres IP urządzenia i hasło do niego.

Trochę tytułem wstępu – na co dzień używam NDK 2.0 do pracy z kodem w C/C++ i dystrybuowanego razem z nim QNX Momentics IDE. W nim też mam skonfigurowane wszystkie potrzebne klucze (P12, CSJ, CSK…), debug-token itp. Dlatego ten etap pominę ;) Na tej stronie zainteresowani znajdą wszystko.

Tak naprawdę to wystarczy to zrobić RAZ, z automatu przy pomocy czarodzieja (wizzarda) z Momentics’a (nie to co w poprzedniej wersji SDK, która wymagała rejestracji w Internecie, i wymiany emaili z RIMem, która trwała kilka godzin!) i włączyć tryb developerski na urządzeniu i oczywiście zapomnieć (na jakiś czas, aż klucze nie wygasną :D). W dodatku dla wygody, FriutBat również odnajduje te klucze w ich domyślnych lokalizacjach i nie musimy tego tam ustawiać.

Jeszcze końcowa uwaga, zanim przejdziemy do mięska – wszystkie te narzędzia, które wymieniłem po liście SDK, nie są oficjalnie wspierane przez RIM, a przez grono programistów, którym się nudzi po godzinach. Mimo to wszystko działa w jak najlepszym porządku i nie spotkałem się z jakimikolwiek problemami.

Jeśli nie chcesz stosować tych sztuczek, to po prostu kup Adobe Flash Buildera, a wszystko skonfiguruje się samo.

 

Moja pierwsza aplikacja!

• Uruchamiamy FlashBuildera i tworzymy nowy projekt (Project –> New Project) w oparciu o szablon Air BlackBerry Playbook. Nazwijmy go “MyAirTest”.

• Próba kompilacji zakończy się błędem:

   

  Error: a target file must be specified
  Use 'mxmlc -help' for information about using the command line.

  Rozwiązanie: w oknie ‘Project’, naciskamy PPM na pliku MyAirTest.as i wybieramy opcję “Set Document Class”.

• Kolejny błąd, choć tym razem inny:

MyAirTest\src\MyAirTest.as: Error: A file found in a source-path 'MyAirTest' must have the same name as the class definition inside the file 'Main'.

Rozwiązanie: Szablon źle nazywa główną klasę (tzn. Main), a powinna ona nazywa się tak samo jak plik, w którym się znajduje.

• Otwórzmy może oryginalną dokumentację i spróbujmy skopiować przykładowy program autorów PlayBooka (pamiętajmy o nazwie głównej klasy, aby zmienić ją na MyAirTest).
• Kompilacja powinna się udać.
• Przeciągamy plik application.xml z katalogu ‘bin’ naszej aplikacji na okno aplikacji FruitBat. Automatycznie wczyta on wszystko o naszym programie i powinniśmy być gotowi do instalacji na urządzeniu! Brawo!

• Ale nie tak szybko, bo oto kolejne problemy:

Error 305: Initial window content SWF version 11 exceeds namespace version http://ns.adobe.com/air/application/2.5

• A zatem w application.xml zmieniamy spodziewaną wersję SDK z 2.5 na 2.6 (lub wyższą), poprzez zmianę na “http://ns.adobe.com/air/application/2.6”.
• Poprawmy od razu informacje o naszym podpisie. W pliku blackberry-tablet.xml wpisujemy odpowiednie informacje w tagach “authorId” oraz “author”. Muszą być one zgodne z debug-toknem, który wgraliśmy na urządzenie!
• I wgrywamy wszystko FruitBatem (utworzy on podpisany plik *.bar) i używając połączenia WiFi lub USB (zależnie od podanego adresu IP urządzania) i automatycznie je uruchomi.

I oto cała tajemnica…

Moja druga aplikacja!

Cóż, w tym momencie nie pozostaje nic innego jak tylko uczyć się Action Script 3. Ciekawsze przykłady – a mianowicie jak utworzyć menu, zakładki, wyszukiwanie itp. znajdują się na portalu blackberry.github.com. Pociąga to za sobą jedną niedogodność – trzeba samemu ręcznie utworzyć pliki projektów zgodne z FlashDevelop (bazując na tych z Flash Buildera). Nie jest to bynajmniej nic trudnego, a bardziej nudne zajęcie.

Jedna podpowiedź – brakujące pliki swc z referencjami głównie do klas QNX znajdują sie tutaj:

   C:\Program Files\Research In Motion\blackberry-tablet-sdk-2.0.0\frameworks\libs

W FlashDevelop, zakładka ‘Project’, PPM na dowolnym katalogu i Add –> Existing File … –> wybieramy np. qnx-screen.swc. A już po samym dodaniu go, naciskamy na nim PPM i wybieramy opcję ‘Add To Library’, co spowoduje, że nazwa zmieni się na niebieską.

 

Co dalej?

Wszystko ;) Własne aplikacje, publikacja, natywne rozszerzenia, aby mieć dostęp do natywnego kodu… jednym słowem – ‘why do I climb a mount? because I am in love!’

Co nim może być? Otóż – polskie znaki! Pokarało mnie potwornie, bo wszędzie próbuję stworzyć użytkownika o imieniu ‘Paweł’ (aż żal, że tak nazwałem systemowego).

Och, jak ciężko w dobie powszechnej cyfryzacji, o wsparcie chociażby dla kilku głupawych znaków tu i tam. Poległ mi na tym system online FedEx, gdzie lepiej z definicji nie używać żadnych nie ASCII-7 znaków, następnie konsola do GITa, nie umie poprawnie wyświetlić mojego imienia, ani znaleźć katalogu domowego,  a teraz rady sobie nie dają narzędzia do Android na Windows 7.

I tylko jedno lekarstwo przychodzi do głowy – symlink tych wszystkich głupawych odmian, do mojego folderu. W Windows 7 junction robi się tak:

C:\Users>mklink /D "PaweĹ‚" "Paweł"

Znowu możemy poczuć się prawie jak w domu!

Gdy w końcu przyjdzie pora, że podczas zabawy z QNX i SDK dla BlackBerry Playbook zostaniemy sam sam z plikiem .bar (lub nie daj Boże!) dostaniemy go od zaprzyjaźnionego dewelopera, to istnieje bardzo prosty sposób, aby ten plik umieścić na urządzeniu. Wystarczy wykonać polecenie:

blackberry-deploy -installApp -device <IP urządzenia> -package <ścieżka do pliku BAR> -password <hasło urządzenia>

A co najlepsze, wszystko to możemy zrobić bez fizycznego podłączania urządzenia do komputera, jeśli poprawnie skonfigurowaliśmy swoje konto dewelopera i mamy możliwość wgrywania zdalnie po WiFi.

Jakby tu zabezpieczyć swoje programy .NET-owe?

Szukałem, szukałem i znalazłem – darmowy obfuscator Eazfuscator.NET. Mnogość funkcji oraz wsparcie dla wszystkich współczesnych wersji platformy Microsoft .NET stawia go moim zdaniem na równi z płatnymi wersjami wielu innych firm znanych na rynku. Jedyne, czego życzyłbym sobie jeszcze w tym zestawie, to wsparcie dla Mono (chociaż samej manipulacji metadanymi), ale i tak duże wrażenie robi zaangażowanie autora w ten projekt przez tyle lat!

Życzę dalszej i równie dużej motywacji.

Dziś ukazała się długo oczekiwana nowa wersja moich bibliotek CodeTitans Libs v1.5. Zawiera ona szereg poprawek oraz nowych funkcjonalności.

Niewtajemniczonym, podpowiem, że służą one do: obsługi odczytu i zapisu w formacie JSON, wymiany danych z użyciem protokołu Bayeux oraz zawierają inne funkcjonalności potrzebne przy przenoszeniu programów z iPhone’a do Windows Phone 7.

Zapraszam do pobierania tutaj.

Testowanie - niestety temat zapomniany i zupełnie zignorowany przez twórców Windows Phone 7. Jakoś w głowie mi się nie mieści, że premiera telefonu odbyła się trzy miesiące temu, po raz pierwszy telefon pokazano światu w marcu 2010 i do dzisiejszego dnia nie doczekał się od oficjalnego frameworka testowego zintegrowanego z Visual Studio. Aż jestem ciekaw, jakim cudem tak dobrze go przetestowali i czy w ogóle zamierzają coś w tę stronę ruszyć. Bo widzę, nawet po kursie na virtualstudy.pl, że dużo ludzi interesuje się dużo bardziej cyklem życia aplikacji, niż prowadzeniem dobrego projektu na tej platformie (nie obrażając nikogo oczywiście).

Na samym początku wyjaśnię zatem, że oczywiście chodzi nam o pisanie testów, do których już przywykliśmy – czy to używając MS Unit Testing Framework, czy NUnit, używając atrybuty, które znamy i które nie sprawiają nam kłopotu oraz całego tego podejścia.

Tak, czy inaczej, błądząc po Internecie i marnując kolejne godziny możemy znaleźć garść przydatnych materiałów, które pozwolą uzbroić nas w środowisko do zabawy. Podejrzewam, że większość nie ma za dużo czasu, zatem przejdźmy od razu do meritum. Polecam zatem przestudiowanie przynajmniej:

• Wystąpienia Jeffa Wilcoxa na MIX2010 o testowaniu Silverlight3 i Silverlight4. Co ciekawe, jest on członkiem zespołu Silverlight (tworzącego między innymi Silverlight Toolkit) i pokazuje on tam między innymi swój autorski projekt. Doprawdy, podziwiam takich ludzi. Ale ciągle daje mi do myślenia, dlaczego Microsoft nie wspiera tego aktywniej (albo samemu?).
• Najnowszą wersję bibliotek, które trzeba dołączyć do projektu automatycznego testowania (o czym za chwilkę) znajdziemy na jego blogu. Dla potomności skopiowałem to również tutaj. Niestety jest to wersja z maja 2010, a mamy ostatni dzień grudnia i choć dzisiaj działa, to ciekawe jak będzie w niedalekiej przyszłości. Kontaktowałem się z Jeffem i obiecał rzucić okiem (popatrzeć na problemy, które mu zgłosiłem) i wypuścić nową wersję niedługo. Wszyscy jednak wiemy, jak to jest z wolnym czasem… no jest wolny ;)

Na koniec zostawiłem sobie zbudowanie aplikacji testowej. Oryginalny post, na którym bazuję znaleźć można tutaj. Jednak jak dla mnie jest on nieco przekombinowany. W skrócie mówi on o tym, że:

1. Trzeba już mieć zainstalowane narzędzia do pracy z Windows Phone 7.
2. Utworzyć najzwyklejszy projekt Silverlight3 dla Windows Phone 7.
3. Dodać referencje do bibliotek Jeffa.
4. Usunąć wszystkie strony aplikacji, gdyż to framework będzie je tworzył sam (za chwilkę).
5. Zmodyfikować konstruktor aplikacji App() tak, aby oprócz monitorowania wyjątków, ustawiał odpowiednio widok (wszystko inne należy skasować z konstruktora):
   

   this.RootVisual = UnitTestSystem.CreateTestPage();
   

6. I najważniejsze – CreateTestPage(), posiada też wersję, która przyjmuje dodatkowe opcje konfiguracji (UnitTestSettings). Wśród nich jest między innymi lista assembly, które mają być przeszukiwane w celu lokalizacji testów. Dodajemy do niej oczywiście wszystkie, które nas interesują. Po co? No ja osobiście wolę oddzielić same testy, od aplikacji, która je odpala. Mimo wszystko testy można użyć jeszcze gdzieś indziej, a tej aplikacji to już nie zawsze.

Wesołego TDD!

Sam temat nie powinien być nieznany. Atrybuty to od takie dodatkowe adnotacje w kodzie, które możemy “przypiąć” do klas, metod, pól (itd.), które nadają im bardziej mistyczne własności, objawiające się już dalej podczas działania samej aplikacji. Ot, po prostu gdzieś później sami będziemy sprawdzać, czy dana klasa, pole czy metoda jest naznaczona wykonywać dla niej specjalny kod, który jest ukryty pod ‘if’ dla typowych elementów.

Jednakże te ‘systemowe’ atrybuty, które oferuje platforma czy kompilator .NET potrafią coś więcej. Dziś pokażę wybrane atrybuty .NET, które według mnie zasługują na szerszy rozgłos i użycie. Niejednokrotnie znajomość ich ułatwiła mi pracę, zatem mam nadzieję, że komuś jeszcze pomogą.

• InternalsVisibleTo – sprawia, że bez ujawniania chronionych klas, “zaprzyjaźniony” tym atrybutem projekt testów jednostkowych (unit test) będzie widział wszystko i mógł tworzyć bez problemu instancje tych klas.
• Conditional – pozwala wyrzucić z kodu te funkcje (ich definicje oraz wywołania), dla których wskazany warunek nie jest prawdziwy. Przydatne bardzo do logowania operacji w trybie ‘Debug’, które nie są nam potrzebne w trybie ‘Release’. Oczywiście funkcje muszą spełnić kilka warunków, ale to już odsyłam do dokumentacji.
• AllowPartiallyTrustedCallers – pozwalamy używać swojego kodu nie w pełni autorytatywnemu kodowi (np. ściągniętemu z Internetu, który nie ma pełni praw wykonania na lokalnej maszynie).
• TestClass / TestMethod – atrybuty używane w projektach testów od oznaczania pojedynczych testów. Głównie używane z Microsoft Testing Framework, jednakże z poziomu funkcjonalności API, posiada on komplementarne funkcje do NUnit, dzięki czemu przy użyciu kilku dyrektyw ‘using’ można te atrybuty przekształcić na identyczne z NUnit. Dzięki czemu nasz kod testuje się świetnie w systemie Window oraz na maszynach z Linuxem czy MacOS, gdzie dostępne jest Mono.

Jeżeli zależy nam na jakości wytwarzanego oprogramowania (co jest z góry wiadome, że tak) – to pojęcie Continous Integration nie powinno być obce. Mi osobiście do gustu przypadł projekt BuildBot. Jednym zdaniem – mały, prosty, obsługujący wiele platform, bardzo łatwo rozszerzalny i co więcej mamy pełny kod źródłowy, gdyby coś poszło nie tak…

Jak go zatem zainstalować na Windows XP (i późniejszym)? Twardzieli odsyłam do “oficjalnego” przewodnika. Ja postaram się dodać coś od siebie i zmniejszyć ilość potrzebnym kroków:

1. Instalujemy Python 2.7.1. Inne (czyt.: wyższe) wersje Pythona mogą być nieco niewygodne, bo nie wszystkie ‘pakiety’ wymagane przez BuildBota mogą być już zaktualizowane, aby z nią działać i w chwili pisania, tak właśnie było.
2. Do zmiennej systemowej PATH dodajemy odpowiednio katalogi (co skróci niektóre męki przy wykonywaniu poleceń z konsoli):
   • C:\Python27
   • C:\Python27\Scripts
     (najprościej chyba we Właściwościach Systemu –> Zaawansowane –> Zmienne środowiskowe i tam znajdziemy Path)
3. Instalujemy twisted w wersji 10.2.
4. Instalujemy SetupTools dla Pythona w wersji 2.7.1. Będą one potrzebne, aby później bez problemu pobrać z sieci wszystko to, czego jeszcze brakuje dla działającej instancji BuildBota.
5. Teraz poleceniami instalujemy:
   • easy_install Zope.Inteface
   • easy_install jinja2
   • easy_install PyCrypto
   • easy_install PyOpenSSL
6. Wreszcie pobieramy samego BuildBota (jako master i slave). Rozpakowujemy do katalogu C:\Temp.
7. Instalujemy go:
   • python C:\Temp\buildbot-0.8.2\setup.py install
   • python C:\Temp\buildslave-0.8.2\setup.py install
8. Sprawdzamy, czy wszystko działa:
   buildbot --version
   
   Powinno zwrócić numer wersji, a nie krzyczeć o brak zainstalowanego pakietu.
9. Teraz pozostała już tylko własna konfiguracja maszyn budujących, dostępów do repozytoriów, nadobnych akcji, uruchamiania testów oraz przygotowywaniu release’a. O tym może opowiem coś niedługo. Dokumentacja natomiast opisuje wszystko bardzo czytelnie.

Oczywiście nie byłbym sobą, gdybym w tym momencie nie napotkał na problem oraz nie próbował ostrzec, że bardzo łatwo zmarnować wieczór i stracić dobry humor. Powód dość prozaiczny. Nie działa logowanie oraz podgląd wykonywanych poleceń, historia itp. Generalnie dużo rzeczy wygląda jak nieudane posuniecie i brak wsparcia dla Windowsa. Nic bardziej mylnego.  Winą obarczmy brak zgrania BuildBota z najnowszą wersją twisted. Bardzo ładnie opisano to w tickecie #1697. Z pomocą przychodzi nam tutaj oczywiście otwartość kodu tego projektu. W opisie problemu znajduje się odnośnik do poprawki. Aplikujemy ją bardzo prosto, nadpisując plik builder.py, tym, który ściągamy z repozytorium.

Uruchamiamy ponownie BuildBot mastera i gotowe!

Dzisiaj wystartował mój najnowszy projekt open-source, oparty o licencję Apache 2.0. Jest nim oczywiście .NET-owa biblioteka do zapisywania/odczytywania wiadomości w formacie JSON. Kod źródłowy oraz binaria znaleźć można na codeplex.com.

Zachęcam do zerknięcia na nią okiem z powodów takich jak:

• pełne wsparcie standardu JSON
• mały rozmiar plików wykonywalnych (~30kb)
• wsparcie dla .NET 2.0+, Compact Framework 2.0 oraz Mono.NET 2.6
• prostotę i wygodę użycia API
• wysokiej jakości kod, oparty o testy automatyczne!

Kiedy budzisz się pewnego dnia i od początku coś ci się nie układa. Nie wiesz do końca, o co chodzi, ale niektóre rzeczy dwoją i troją ci się w oczach. To jeszcze nie dowód na to, żeby odstawić mocniejsze trunki! To po prostu Visual Studio 2010 ześwirowało!

U mnie wyglądało to tak, że nie działał Backspace, Control i inne specjalne klawisze, zaś sam interfejs prezentował się tak, że każdy element menu i paska narzędziowego był zduplikowany kilka razy w pozornie losowych miejscach:

 

 

Wyglądało to na swój sposób tragicznie. Istnieje niestety tylko jedna opcja, która pozwala przywrócić IDE to stanu poprzedniego. Wszystkie innej (tj. próba zresetowania ustawień w Tools->Import/Export Settings…, czy usunięcie katalogu VisualStudio z Moich Dokumentów) spełzły na niczym.

A oto przepis, który wszystko przywraca do normalności:

devenv.exe /ResetUserData