Jakub Florczyk – Blog o programowaniu .NET

Kolejna odsłona Pocket Blip. Już dostępna w Windows Marteplace oraz na stronie aplikacji.

Zmiany w wersji 2.1:
• Dodana odpowiedź z cytowaniem.
• Dodana opcja bliplog w “Skocz na…”.
• Dodana opcja “przybliżonej lokalizacji” określanej na podstawie wieży komórkowej (ta opcja może nie działać na niektórych telefonach).
• Dodane proste dodawanie ^pocketblip do obserwowanych.
• Dodany podgląd profilu użytkownika ze statystykami dostarczanymi przez Blipi.pl.
• Dodany podgląd i zarządzanie obserowowanymi.
• Dodany podgląd obserwujących.
• Dodane wklejki do wiadomości (często używane teksty).
• Dodana opcja pozwalająca na wylączenie połączenia przy roamingu + opcja na pobieranie danych tylko po WiFi.
• Zmieniona sekretarka, teraz także pokazuje “cytowania ciebie” i “mówienie o tobie”.
• Zwiększona ikona zdjęcia przy wiadomości na ekranach VGA i większych.
• Zmiana “Przejdź…” na “Skocz na…”.
• Zmiana okna “Skocz na…”.
• Zmiany w notyfikacjach.
• Zmieniony sposób wyświetlania daty / godziny wiadomości.
• Usunięta opcja sprawdzania wersji (naruszała regulamin Windows Marketplace for Mobile).

Jakub Florczyk .NET, Compact Framework, Pocket Blip .NET, Blip, Blipi, BlipiNET, BlipNet, C#, CF, Compact Framework, Pocket Blip, Windows Marketplace Mobile, Windows Mobile

W czasie ostatniej konferencji Mobile World Congress 2010 dowiedzieliśmy się jak wygląda Windows Phone Series 7. Są tacy, którym nowy system operacyjny bardzo się podoba, mimo że część power-userów narzeka na jego “cukierkowość”. Jakby na nowy system operacyjny nie spojrzeć, Microsoft musiał zamiast kroku naprzód wykonać skok i zerwać ze starym interfejsem. Ja osobiście jest zwolennikiem takiego rozwiązania, bo konkurencja jest aktualnie lata świetlne przed nią. Bardzo cieszy mnie fakt, że sam interfejs nie jest kolejnym klonem iPhone-a w postaci siatki ikonek. Wygląda inaczej i wg mnie wygląda fajnie.
Tak czy inaczej pomijając aspekty estetyczne, dla mnie ważniejsze jest to co nowy system operacyjny niesie ze sobą dla programistów. Wiemy już, że na pewno za interfejs odpowiada Silverlight, nie wiemy tylko jeszcze w jakiej wersji. A co poza tym? Na razie kolos milczy, choć ma rozwiać mgłę w czasie nadchodzącego MIX-a 16-go marca. Wszystkie eventy będą transmitowane live, więc nie martw się jeśli cię tam nie będzie.
Zanim jednak Microsoft przedstawi swoją wizję Windows Phone 7 Series deweloperom, chciałbym przedstawić swoją listę życzeń:

• Silverlight w wersji co najmniej 3 – taka jest wg mnie obecnie wystarczająca z pełną paletą podstawowych kontrolek, które są dostępne już teraz.
• Visual Studio 2010 z zintegrowanym Expression Blend – nie mogę się przekonać do faktu, że te dwa narzędzia pracują obok siebie; moja wizja Blend-a jest zintegrowana w VS i nieoficjalnie z pewnych źródeł wiem, że tak się stanie
• Wspólne SDK-a dla wszystkich telefonów, narzucone przez Microsoft obsługujące kompas, kamerę, akcelerometr, inne czujniki i led. Mam nadzieję, że w końcu ktoś się obudzi i narzuci producentom pewne wymagania które musi spełnić każdy telefon a firma z Redmond stanie na wysokości zadania i dostarczy wspólne SDK dla wszystkich bajerów jakie tylko się mogą w telefonie znaleźć.

Jeżeli deweloperzy otrzymają w końcu GUI spełniające aktualne standardy, to na pewno powali to rozwiązania Androida oparte o tworzenie graficzek w PNG (sic!). Ale poza interfejsem potrzebujemy dostęp do wszystkich możliwości telefonu nie bawiąc się w pisanie wrapperów i innych cudów, które często działają tylko na telefonach jednej firmy. A zintegrowane środowisko w postaci Visual Studio z edytorem jak w Blend-zie będzie wisienką na torcie i tak najlepszego IDE jakie obecnie wyprodukowano.

Jakub Florczyk .NET, Compact Framework, Silverlight, Windows Mobile .NET, C#, CF, Compact Framework, Silverlight, Visual Studio, Windows Forms, Windows Mobile

Może pamiętacie jak kilka dni temu Mirosoft udostępnił Windows Mobile 6.5.3 Developer Tool Kit po czym instalator zniknął. Szczęśliwcy ci, którzy nie zdążyli go ściągnąć (ja się do nich nie zaliczam) i go nie zainstalowali. Otóż poprzedni release zawierał błędy i po instalacji nie dało się na nim pracować. Nie dość tego także niszczył SDK od innych wersji i “niefortunne” dążenie do nowinek i ładniejszych screnów w Windows Marketplace dla mobilnych urządzeń kosztowało mnie reinstalację wszystkich SDK-ów od wersji 5 począwszy.

Tak czy inaczej Microsoft podobno naprawił błędy i ponownie udostępnił Tool Kit-a, którego można pobrać tutaj. Ja jednak tym razem chwilę poczekam…

Jakub Florczyk .NET, Compact Framework .NET, C#, CF, Compact Framework, Visual Studio, Windows Mobile

Marek Foss od Blipi.pl zaktualizował dziś API do wersji 2.0 wprowadzając kilka ulepszeń. Co za tym idzie zaktualizowałem także BlipiNET.

Zmiany w najnowszej wersji:

• klucz API wymagany jest tylko do wyszukiwania, reszta metod go nie używa
• usunięte zostały metody GetTrackedBy oraz GetRank
• powyższe metody zastąpiła metoda GetStats która zwraca pełne statystyki użytkownika: liczba obserwujących, zmiana liczby obserwujących, liczba obserwowanych, zmiana liczby obserwowanych, liczba cytowań, liczba wzmianek, ranking i zmiana rankingu

Ponieważ aktualnie pracuje nad zmianami w Pocket Blip już można zobaczyć roboczą wersję widoku profilu użytkownika:

Marek na Blipie zdradził także, że pracuje nad udostępnieniem trendów w API.

Jakub Florczyk .NET, BlipiNET, Compact Framework, Windows Forms .NET, API, Blipi, BlipiNET, C#, CF, Compact Framework, Windows Mobile

Książek o programowaniu na platformę Windows Mobile w języku polskim nie uświadczymy. W języku angielskim jest natomiast w czym wybierać. Na samym Amazon-ie jest co najmniej kilka pozycji wartych polecenia. Jedną z nich jest właśnie “Mobile Development Handbook”.

Dlaczego ją akurat wybrałem nie mam zielonego pojęcia. Ale z doświadczenia wiem, że książki Microsoft-u stoją na dobrym poziomie. A ponieważ nie jestem zwolennikiem rozmyślań autora nad wyższością bożego narodzenia nad wielkanocą dlatego preferuje książki które formą przypominają helpy opatrzone bardziej dokładnie opisanymi przykładami niż poradniki gotowania na parze.

Książka składa się z dziewięciu części:

1. .NET Compact Framework – a Platform on the Move
2. Building a Microsoft Windows Forms GUI
3. Using SQL Server 2005 Compact Edition and Other Data Stores
4. Catching Errors, Testing and Debugging
5. Understanding and Optimizing .NET Compact Framework Performance
6. Completing the Application: Packaging and Deployment
7. Exchanging Data with Backend Servers
8. Networking
9. Getting Connected

Jak widać ze skróconego spisu treści książka obejmuje praktycznie wszystkie zagadnienia które mogą interesować każdego programistę Windows Mobile. Dlatego polecam ją każdemu kto dopiero ma zamiar zacząć przygodę z WM jak i tym, którzy już zjedli na niej zęby – bo na pewno im się przyda.
Ze swojej strony powiem tylko, że części o SQL CE pochłonąłem w jedno popołudnie; bo nigdy nie byłem orłem i fanem sposobu obsługi baz danych do którego przyzwyczaił nas Microsoft. Nie wspominając już o synchronizacji z “pełnym” SQL-em co zawsze przyprawiało mnie o ból głowy.

Minusem książki jest fakt że opisuje .NET CF w wersji 2.0. Wersja 3.5 jest tylko miejscami wspominana. Ale jeżeli ktoś orientuje się w różnicach między obydwiema wersjami wie, że nie ta rozbieżność nie wprowadza sporych różnic. Sam Compact Framework między tymi wersjami nie uległ znaczącym zmianom a .NET dostał tylko kilka dodatków ułatwiających pisanie aplikacji.

Książka do kupienia na Amazon w cenie 44,09$.

Z ciekawostek książka ma swoją grupę na Facebook-u Microsoft Mobile Development Handbook.

Jakub Florczyk .NET, Compact Framework .NET, C#, CF, Compact Framework, Windows Forms, Windows Mobile

Nowa odsłona programu Pocket GPW po sugestiach użytkowników.

Zmiany obejmują:

• poprawkę na edycję alarmów, których nie można było usunąć
• dodanie wartości obrotu i wolumenu obrotu

Aplikacja dostępna jest na portalu Codeplex.

Jakub Florczyk .NET, Compact Framework, Pocket GPW .NET, C#, CF, Compact Framework, Pocket GPW, Windows Mobile

Żeby nie było, iż jestem jednostronny to dla odmiany dziś o firmie Samsung. I o jego w moim mniemaniu cudownym dziecku Samsung Windows Mobile SDK.

Na początek małe wytknięcie pięty achillesowej firmy HTC. Otóż mimo iż produkują świetne telefony, z najlepszymy nakładkami i oprogramowaniem, to ogromnym minusem jest brak jakiegokolwiek SDK dla bibliotek HTC.
Oczywiście podstawową część obsługi telefonu możemy załatwić standardowymi bibliotekami .NET / Tapi/ ExTapi / RIL ale często te najsmaczniejsze kąski siedzą w warstwach do których HTC nas nie chce dopuścić. I do dziś się zastanawiam dlaczego.
O tyle dobrze, że niektórym udało się dostać to obsługi akcelerometru i LED-ów HTC o tyle kamera np. nadal jest jedną wielką zagadką i dostęp do surowych danych a nie ubranych w jakieś okienka Microsoftu.

Z drugiej strony pojawia się firma Samsung i udostępnia pełne SDK do funkcji telefonu. Pisząc pełne, mam na myśli: akcelerometr, kamerę, lampę kamery, radio, led, haptics, czujnik światła, mysz optyczną, orientację 2D i 3D, czujnik zbliżeniowy, procesor audio, slider-a, wyjście TV, wibrację i kółko nawigacji. Jeżeli jeszcze ci szczęka nie opadła, to jest właśnie dobry moment.

Samsung całość udostępnił jako SDK, które można pobrać tutaj. Biblioteki są przygotowane pod C++ z jednym przykładem natywnym.

Jako, że nie mogłem znaleźć wrappera z pełną implementacją, postanowiłem go napisać samemu. Biblioteka dostępna jest na CodePlex SamsungMobileSDKNET. Na obecną chwilę zawiera pełną implementację wersji 2.1. Ale ponieważ nie posiadam telefonu Samsunga, żaden element nie jest przetestowany. Dlatego prośba dla programistów z telefonami Samsunga o przetestowanie poszczególnych elementów. No chyba, że wcześniej z Orange-a wezmę Samsunga Omnia II – bo ostatnio mi proponowali nawet w rozsądnej cenie i sam przetestuje poszczególne elementy.

Jakub Florczyk .NET, Compact Framework, SamsungMobileSDKNET .NET, API, C#, CF, Compact Framework, Samsung, SamsungMobileSDKNET, Windows Mobile, Wrapper

A propos artykułu RilNET – Radio Interface Layer (RIL) .NET wrapper należy się drobne sprostowanie działania biblioteki a przede wszystkim obsługi lokalizacji.

Otóż po wielu testach na telefonach firm HP i HTC oraz po przeczytaniu kilku artykułów w sieci wszystkim osobom, które używają RIL-a należy się małe wyjaśnienie o którym nie zdawałem sobie sprawy w momencie pisania wpisu.

Otóż implementacja biblioteki RIL zależy od producenta telefonu. Sprowadza się to do tego, iż część funkcji może nie być w ogóle zaimplementowana!

W praktyce wygląda to tak, iż mój wysłużony HP 614C nie posiadał zaimplementowanej metody udostępniającej informację o komórce sieci  GetCellTowerInfo przez co w artykule błędnie zasugerowałem, że to pewnie wina sieci Orange.
Po zamianie i testach na HP Touch Pro2 wszystko działa poprawnie. Funkcja zwraca informacje o sieci!

Oczywiście można sobie zadać pytanie: no i co z tego? Otóż wbrew pozorom bardzo wiele. Chociażby to, że Google Maps potrafi obsługiwać RIL-a i jest w stanie określić waszą przybliżoną pozycję na podstawie wieży komórkowej.

Podsumowując. Jest to kolejny powód aby kupować telefony poważnych firm. Choć HP kiedyś bardzo się starało w sprawie PocketPC, obecnie daleko im do czołówki i standardów króla HTC.

Jakub Florczyk .NET, Compact Framework, RilNET .NET, API, C#, CF, Compact Framework, Radio Interface Layer, RIL, Windows Mobile, Wrapper

W nowej wersji Pocket Blip pracuję nad zmianą dostawcy wyszukiwarki oraz statystykami użytkowników. Wybór dostawcy padł na Blipi Marka Fossa, ponieważ poza wyszukiwarką Marek udostępnia też ranking i licznik obserwujących. Z tego powodu powodu popełniłem bibliotekę dostępową .NET do API. Projekt można znaleźć na CodePlex BlipiNET.

Jak w przypadku innych bibliotek zdecydowałem się na “toporne” metody HttpWebRequest ze względu na brak nowych rozwiązań a’la WCF w wersji Json w Compact Framework.

Przykłady użycia:

// Wyszukiwanie wiadomości
BlipiService bs = new BlipiService("[twój klucz API]");
Message[] messages = bs.Search("jakubflorczyk");

// Ranking (Top100)
BlipiService bs = new BlipiService("[twój klucz API]");
User userRank = bs.GetRank("jakubflorczyk");

Dostępna jest pełna implementacja aktualnego API:
- wyszukiwanie
- pobieranie rankingu użytkownika
- pobieranie licznika obserwujących użytkownika
- pobieranie statystyk Top 10 i 100

Jakub Florczyk .NET, BlipiNET, Compact Framework, Windows Forms .NET, API, Blipi, BlipiNET, C#, CF, Compact Framework, Windows Mobile

W kilku krokach i słowach, postaram się wyjaśnić zasadę lokalizacji aplikacji .NET Compact Framework. Wszystko przy uwzględnieniu certyfikowania aplikacji dla Windows Marketplace for Mobile.

Na samym początku pragnę przypomnieć, że lokalizacja opiera się na tłumaczeniu aplikacji dla danego kraju a nie języka! To jest bardzo ważny element z którego nie wszyscy sobie zdają sprawę. Ale później pokaże jak w prosty sposób “oszukać” Marketplace aby nasza aplikacja na jednym języku chodziła na wiele krajów.

Drugim ważnym problemem jest pytanie jakie musi sobie zadać każdy deweloper: w którym momencie lokalizować aplikację? Odpowiedź na to pytanie nie jest prosta. Jeżeli zamawiamy grafiki, piszemy teksty do naszej aplikacji należy o tym pamiętać na samym początku. Ale samą lokalizację sugeruje robić na samym końcu – nawet po testach funkcjonalnych. Ale ta teoria sprawdza się tylko w przypadku aplikacji okienkowych, bo gry warto lokalizować na samym początku, wraz z pisanym kodem. W aplikacjach okienkowych problem sprowadza się do zmian wprowadzanych na poszczególnych formach, które następnie musimy weryfikować na innych wersjach językowych. Dlatego aby uprościć sobie przeklikiwanie się przez kolejne formy i sprawdzanie czy zmiany zostały poprawnie przeniesione, sugeruje lokalizować aplikację na samym końcu.

Lokalizacja kodu.

Tutaj sprawa wygląda dość prosto i całość problemu sprowadza się do poprawnego wyświetlania danych oraz odpowiedniego sposobu konwertowania tychże.

// konwersja
DateTime dateTime = Convert.ToDateTime(xeEntry.Attribute("DateTime").Value, CultureInfo.CurrentCulture);
// wyświetlanie
label1.Text = dateTime.ToString(CultureInfo.CurrentCulture);

Ot co, cała filozofia. Jeżeli używamy Microsoft FxCop – nie omieszka nas o tym poinformować odpowiednim komunikatem.

Lokalizacja okien (Form-ów).

Mój projekt składa się tylko z jednego forma, w którym jest bardzo proste menu (w tym momencie w języku angielskim):

Następnie przełączamy się na właściwości forma i zmieniamy Localizable na True oraz Language na Polish:

Po tej operacji w nazwie okna (na górnym pasku) powinniśmy zobaczyć napis Form1.cs [Design - Polish]. W tym momencie możemy przetłumaczyć menu na język polski:

Kiedy dokonamy pierwszej zmiany w plikach aplikacji zostanie utworzony dodatkowy plik o nazwie Form1.pl.resx. Każde tłumaczenie jakiego dokonamy będzie miało odzwierciedlenie właśnie w tym pliku – poprzez utworzenie odpowiedniego rekordu lokalizacji.

Tak jak pisałem na początku w przypadku okienek warto te kroki zostawić na sam koniec, aby później nie paprać się zbytnio w zmianach na kolejnych formach kiedy zauważymy źle ustawiona kontrolkę lub tym podobny trywialny problem, który po lokalizacji może narastać lawinowo w zależności od ilości krajów.

Lokalizacja zasobów (Resources).

Załóżmy że nasz aplikacja wyświetla MessageBox-a z tekstem “Are you sure?” – np w momencie kliknięcia w Exit (tak na marginesie certyfikacja dla Marketplace zabrania takich praktyk). Tekst przenosimy do zasobów pod nazwą MessageBox_Text. Mamy załatwioną wersję angielską.
Aby utworzyć odpowiednie tłumaczenie w wersji polskiej, musimy utworzyć kopię pliku Resources.resx zmieniając jego nazwę na Resources.pl.resx i dokonując tłumaczenia. Gotowe!

Lokalizacja instalatora.

Aby przenieść i wkompilować wszystkie wersje językowe w jednego CAB-a musimy dodać do projektu instalatora pliki lokalizacyjne. Aby to zrobić klikamy prawym klawiszem na projekcie i wybieramy Add -> Project Output… -> Localized resources.

W tym momencie uzyskujemy jeden plik CAB, który załaduje wersję językową naszej aplikacji w zależności od ustawień regionalnych telefonu użytkownika.

A co na to Marketplace?

Zanim napiszę o Marketplace wrócę do tematu, który z premedytacją pominąłem na początku a dotyczy działania lokalizacji na telefonie. Otóż sam proces jest stosunkowo prosty w działaniu. Windows Mobile odpala program, szukając jednocześnie lokalizacji zgodnej z danym ustawieniem regionalnym. Jeżeli nie dokonamy lokalizacji programu albo nie system operacyjny nie znajdzie odpowiedniej lokalizacji, zostanie załadowana lokalizacja domyślna programu. Jeżeli system odnajdzie odpowiednią lokalizację – zostanie ona załadowana.

Windows Marketplace for Mobile zakłada, że każdy certyfikowany program może zawierać nieograniczoną ilość lokalizacji o ile znajdują się one w jednym pliku CAB. Jeżeli lokalizacja znajduje się w oddzielnym pliku CAB niż “oryginał” cały proces certyfikacji musi zostać wykonany ponownie za co zapłacimy 100$. W pierwszym wypadku zapłacimy tylko 9.99$ za każdy kolejny kraj. Jednym słowem warto kompilować CAB-y z wieloma lokalizacjami.

Wracając do tematu “oszukania” Marketplace. Z mojego punku widzenia istnieje Polska i reszta świata, która mówi w języku angielskim. W Marketplace reszta świata mówiąca po angielsku sprowadza się do następujących krajów: Australia, Kanada, Indie, Irlandia, Nowa Zelandia, Singapur, Wielka Brytania, Stany Zjednoczone. Aby nie komplikować sobie sprawy z lokalizacjami sugeruję utworzyć “domyślną” lokalizację w języku angielskim a tłumaczenie w Polskim. Chodzi o to, że zamiast tworzyć osiem lokalizacji, tworzymy tylko jedną.

Jakub Florczyk .NET, Compact Framework, Visual Studio .NET, CF, Compact Framework, Visual Studio, Windows Mobile