MIX10 i Windows Phone 7 Series – moje wrażenia
MIX10 oficjalnie się zakończył. Właściwie powiedziano już wszystko i znam odpowiedzi na prawie wszystkie nurtujące mnie pytania. Postaram się w skrócie podsumować to wszystko co powiedziano na MIX-ie oraz dodać kilka swoich przemyśleń.
A więc po kolei.
Po pierwsze udostępniono Windows Phone Developer Tools CTP, które zawiera:
- Visual Studio 2010 Express for Windows Phone CTP
- Windows Phone Emulator CTP
- Silverlight for Windows Phone CTP
- XNA 4.0 Game Studio CTP
Wbrew pozorom ta informacja niesie ze sobą podprogowy przekaz 
Otóż na 99% możemy się spodziewać Visual Studio 2010 Express w wersji dla deweloperów Windows Phone. Co jest rewelacyjną informacją dla osób, które do tej pory nie mogły sobie pozwolić na “pełną” wersję Visual Studio (Express nie wspiera pisania aplikacji pod WM). A więc prawie na pewno przybędzie chętnych do spróbowania swoich sił.
Po drugie sam nowy system operacyjny jest dość kontrowersyjny:
- nie obsługuje multitaskingu a więc aplikację nie będą mogły chodzić w tle
- nie ma opcji kopiuj / wklej – Microsoft tłumaczy się zaawansowanym systemem rozpoznawania informacji na ekranie (np. numerów telefonu). Ale nijak nie potrafię sobie wyobrazić sytuacji kiedy chcę przekleić np kawałek tekstu strony internetowej i wrzucić to na Blipa.
- nie ma kart pamięci – jakoś nie wyobrażam sobie sytuacji gdzie ładuje do pamięci Auto Mapę , która ma 1GB danych i trzymam to non stop w telefonie
- nie masz dostępu do plików – nie żebym był jakiś strasznym fanem tego rozwiązania ale nie wyobrażam sobie sytuacji gdzie nie mogę ręcznie posprzątać plików w pamięci a pisząc programy telefon można zaśmiecić bardzo szybko
Po trzecie zmiany dotkną Marketplace:
Zostaną usunięte ograniczenia geograficzne. W końcu! Jakbym miał jeszcze raz w życiu wrzucić Tangram Pro osiem razy w języku angielskim tylko dlatego, że to inny kraj to chyba bym sobie darował.
Po czwarte – zajmijmy się konkretami:
Zestaw nowych bibliotek .NET dla Windows Phone 7 Series jest w wersji 4.0 – oczywiście mowa o podstawowym zestawie. A więc tu bez zmian – Microsoft zachował się tak jak przy poprzednich wersjach i udostępnił prawie identyczne zestawy.
Poza nim dostajemy zestaw bibliotek XNA w namespace Microsoft.XNA. Muszę przyznać, że odrobinę bawiłem się XNA na emulatorze i wyniki są naprawdę genialne. W tym się naprawdę bardzo prosto pisze gry. Koniec ze sztuczkami graficznymi GDI. Dostajemy prawdziwe narzędzie do pisania gier.
Plus zestaw silverlight z namespace Microsoft.Phone.Controls. Tutaj nie ma rewelacji. Oczywiście CTP nie jest wersją ostateczną, ale aktualny zestaw kontrolek nie powala. Brakuje mi wielu rzeczy i mam nadzieję, że to się zmieni. Co jest ciekawe w Application.Resources dostajemy domyślny zestaw styli telefonu a więc odpada nam karkołomna sztuka ustalania standardu. Na pewno zyskają na tym interfejsy i iPhone z Androidem mogą się zacząć bać, choćby z tego powodu że SL na telefonie wspiera IIS Smooth Streaming, DRM i tym podobne “dobra”.
API telefonu dostępne jest w bibliotekach Microsoft.Device. Obecnie widać akcelerometr i wibrację. Na pewno jest jeszcze obsługa kamery z dostępem do “czystych” klatek oraz kompas.
Kolejna ciekawostka. Dodano bibliotekę Microsoft.Phone.License która zawiera w sobie jedyną klasę License a w niej metodę IsTrial(). Marketplace otrzyma możliwość udostępniania aplikacji w wersji trial i wtedy powinniśmy sprawdzić wartość tej metody. Zastanawia mnie tylko jak się Microsoft zabezpieczył się przed podmianą tej biblioteki na taką która zawsze będzie zwracać false.
Na zakończenie otrzymaliśmy Microsoft.Phone.Notification do obsługi notyfikacji oraz Microsoft.Phone.Tasks która ma obsługiwać odpalanie map Bing, okna kamery, przeglądarki internetowej oraz odpowiada za obsługę pseudo funkcji wklej, bo na przykład pozwala zapisać adres email klasą SaveEmailAddressTask.
Na marginesie nie ma bibliotek System.Windows tak jak wcześniej zapowiadano a więc nie ma klasy Clipboard do obsługi schowka.
A tych wszystkich, których zastanawia brak File Explorera w telefonie przy jednoczesnym istnieniu biblioteki System.IO czeka niemiła niespodzianka. Ale to już sprawdźcie sami
Podsumowując
Nawiązując do jednego ze swoich poprzednich postów Windows Phone 7 Series – lista życzeń programisty spełniły się dwa z moich trzech życzeń. SL jest w wersji 4. Za Expression Blend będę musiał w Polsce zapłacić pewnie z 2 tysiące złotych (pomijajjąc fakt, że u nas jest on dużo droższy niż np w USA) oraz system posiada API do kamery, akcelerometru i kompasu. Myślę, że to niezły wynik.
W jakich kolorach maluje się przyszłość power userów? W tym momencie trudno odpowiedzieć na to pytanie. Jeżeli jesteś “kucharzem” ROM-ów i zapalonym tweakerem to zapewne porzucisz Windows Mobile i przerzucisz się na Androida.
A co do deweloperów – na odpowiedź musimy zaczekać do pierwszych wyników sprzedaży telefonów z Windows Mobile 7. Jeżeli się okaże, że telefony sprzedają się rewelacyjnie to nic tylko pisać aplikację i zarabiać kasę. Jeżeli jednak okaże się, że Microsoft się pomylił to nie pozostanie nam nic jak tylko przerzucić się na Androida / iPhone-a.
Windows Phone 7 Series – lista życzeń programisty
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.
Windows Mobile 6.5.3 Developer Tool Kit ponownie udostępniony
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…
Lokalizacja aplikacji w .NET Compact Framework
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ą.
Poprawny .NET Compact Framework CAB w kilku krokach
Na początek przyznam się, że zawsze miałem problemy z projektami instalacyjnymi. Dlatego chciałbym w kilku krokach przybliżyć wam mój sposób tworzenia poprawnego CAB-a dla Compact Framework, do którego doszedłem po wielu testach i próbach.
Projekt do którego tworzę CAB-a nazywa się Largo.
Krok pierwszy – tworzymy “Smart Device CAB Project”:
Ja przyjąłem standard nazewnictwa [Nazwa projektu].Cab. Ale jako tako nazwa ta nie ma większego znaczenia.
Krok drugi – zmieniamy nazwę pliku wyjściowego (prawy klik na projekcie i wybieramy Properties):
Na początek mała uwaga, kliknięcie Properties z menu kontekstowego przywołuje inny ekran niż wybór Properties z Properties Window.
Domyślna nazwa zbudowana jest według zasady “Debug\[Nazwa projektu CAB].cab” dlatego w naszym przypadku będzie to “Debug\Largo.Cab.cab”. Wystarczy usunąć przyrostek .cab aby nazwa wyglądała poprawnie (“Debug\Largo.cab”).
Krok trzeci – zmiana nazwy produktu i firmy (wybieramy Properties z Properties Window):
Manufacturer – zmieniamy na nazwę naszej firmy / imię nazwisko lub nick. Ta nazwa pojawi się tylko i wyłącznie podczas instalacji w momencie kiedy Windows Mobile pyta nas czy chcemy zainstalować program “[Manufacturer] [ProductName]“. Według mnie nazwa ta jest odrobinę zbędna ale np. Windows Marketplace for Mobile wymaga aby nazwa ta zgadzała się z nazwą firmy / dewelopera który jest zgłoszony do sklepu.
ProductName – zmieniamy na nazwę naszego programu. Domyślnie jest to nazwa projektu CAB. W tym punkcie warto pamiętać, że pod taką nazwą pojawi się katalog z naszą aplikacją w “Program Files”.
Krok czwarty – usuwamy z “File System” folder o nazwie “Program Files Folder” (prawy klik na katalogu i wybieramy Delete):
W większości przypadków ten katalog jest zbędny dlatego spokojnie można go usunąć.
Krok piąty – dodajemy “Primary Output” (prawy klik na projekcie Add -> Project Output… ):
To jest zestaw podstawowych plików naszej aplikacji, który zawiera plik exe oraz załączone biblioteki.
Krok szósty – utworzenie katalogu “Programs Folder” (prawy klik na lewym panelu Add Special Folder – > Programs Folder):
Krok siódmy – utworzenie skrótu do programu (rozwijamy w lewym panelu wcześniej utworzony “Programs Folder” i w prawym panelu, prawy klik “Create New Shortcut”):
Następnie pojawi się okno wyboru elementu do którego tworzymy skrót:
Wybieramy “Application Folder” a następnie “Primary output from [Nazwa projektu] (Active)”:
Nazwa która się pojawi od razu zmieniamy na “Largo” (albo jakakolwiek inna). Ta nazwa pojawi się w menu Start.
I to zasadniczo wszystko. W siedmiu krokach udało nam się utworzyć podstawowy projekt CAB. Ze swojej strony chciałbym tylko dodać kilka porad co do późniejszej pracy z takim projektem:
- Jeżeli dodajemy do oryginalnego projektu jakieś biblioteki warto po kompilacji kliknąć na katalogu “Detected Dependencies” i wybrać “Refresh Dependencies”. Czasami Visual Studio zapomina je odświeżyć i dlatego warto zrobić to ręcznie.
- Jeżeli używamy plików z ustawionymi atrybutami “Build Action” na “Content” pamiętajmy o tym aby je dołączyć do CAB. Wystarczy prawy klik na projekcie Add -> Project Output -> Content Files i pliki znajdą się w instalatorze.
- Podobnie jak powyżej dodajemy pliki lokalizacyjne Add -> Project Output -> Localized resources.
HTC Touch Pro2 – skórka emulatora
Pisząc programy pod .NET Compact Framework Microsoft dostarcza z Windows Mobile SDK zestaw emulatora urządzenia i skórek pod różne rozdzielczości. Znudzony trochę nieciekawym wyglądem postanowiłem stworzyć własną skórkę. A skoro firma HTC udostępniła HTC Touch Pro2 do testów, wybór był oczywisty.
Tworzenie skórki jest dziecinnie proste (dlatego dziwi mnie, że tak mało jest ich w sieci). Cała zabawa polega na stworzeniu grafiki urządzenia i pliku definicji. W skórkach Microsoft dodatkowo występuje grafika maski klawiszy oraz grafika “wciśniętych” przycisków, ale przez sam emulator nie są one wymagane.
Plik definicji wskazuje na poszczególne grafiki, położenie ekranu oraz listę obsługiwanych klawiszy jeżeli dostarczyliśmy grafikę maski. Więcej o tworzeniu skórek można poczytać na MSDN-ie.
Skórka emulatora HTC Touch Pro2:
Skórkę można pobrać tutaj.
Ponieważ HTC Touch Pro2 ma ekran o rozdzielczości WCGA (480×800) do tej skórki wymagany jest emulator “Windows Mobile 6.5 Professional WVGA Emulator”. który jest dostarczany w Windows Mobile 6.5 Developer Tool Kit.
Sposób instalacji:
- pliki wypakowujemy do C:\Program Files\Windows Mobile 6 SDK\PocketPC\DeviceemulationV650\
- uruchamiamy Visual Studio
- nawigujemy do Tools -> Options…
- wybieramy Device Tools -> Devices
- z listy wybieramy USA Windows Mobile 6.5 Professional WVGA Emulator
- klikamy Save As…
- wprowadzamy tytuł HTC Touch Pro2
- klikamy Properties…
- klikamy Emulator Options…
- przełączamy się na zakładkę Display
- w Skin wskazujemy ścieżkę do C:\Program Files\Windows Mobile 6 SDK\PocketPC\DeviceemulationV650\HTC_Touch_Pro2\HTC_Touch_Pro2.xml
- uruchamiamy nasz program
Ze względów praktycznych klawisz Back zmieniłem na App Launch 2 aby możliwe było obracanie emulatora. Ponieważ HTC Touch Pro2 ma duży ekran, emulator ledwo mieści się nawet na monitorze o rozdzielczości 1920×1200
Surface Blip 1.0 – wstęp do programowania Microsoft Surface
Po opublikowaniu Microsoft Surface SDK postanowiłem się z nim zaznajomić i popełnić jakąś aplikację (zanim zaczniesz instalować SDK pamiętaj, że wymagane jest zainstalowane XNA). Po obejrzeniu aplikacji do obsługi Twittera – Surface Twitter oczywisty wybór padł znowu na Blipa. Ale po kolei…
Po instalacji SDK w Visual Studio pojawiła się nowa gałąź w Visual C# o nazwie Surface. Do wyboru mamy trzy rodzaje projektów:
- Surface Application (WPF)
- Surface Application (XNA)
- Surface Application (XNA Game Studio 3.0)
Jako że nie znam XNA wybór padł na WPF skoro większość z nas już go zna. Co jest ciekawe sama implementacja Microsoft Surface w WPF nie różni się znacząco od standardowego WPF-a. Samo SDK dodaje nam kilkanaście nowych kontrolek a cała magia dzieje się poza nami Najważniejsza z naszego punktu widzenia kontrolka to ScatterView na którym są osadzane poszczególne interaktywne elementy. Dodatkowo SDK udostępnia większość implementacji standardowych kontrolek, których nazwa jest rozszerzona o przedrostek Surface. Dla przykładu Button w SDK nazywa się SurfaceButton itd.
Sama aplikacja nie jest skomplikowana, żeby nie powiedzieć trywialna Mamy ekran logowania a po nim ładuje ostatnie statusy z kokpitu plus okno do dodawania nowych wpisów. Nie chcę się wgłębiać w implementację bo widać ją na kodzie źródłowym. Natomiast chciałbym wskazać kilka elementów na które warto zwrócić uwagę:
- Po utworzeniu projektu template tworzy katalog Resources a w nim pliki AppIcon.png i AppIconPreview.png – są to ikony naszego projektu na które wskazują ścieżki z pliku definicji o konstrukcji [Nazwa naszego projektu].xml.
- W pliku definicji znajdują się ścieżki do ikon, aplikacji (exe) oraz kilka dodatkowych elementów.
- Z punktu widzenia programisty i Microsoft Surface ważne jest to iż programy nie muszą być zainstalowane, ponieważ Surface odczytuje pliki definicji z katalogu C:\ProgramData\Microsoft\Surface\Programs i na ich podstawie wyświetla dostępne aplikacje (położenie exe i ikon).
- Program (w Visual Studio) uruchamiamy standardowo klawiszem F5, ale symulacja nie obsługuje wielu aktywnych punktów; przydatne tylko we wczesnym testowaniu aplikacji, plusem jest szybki czas ładowania.
- W przypadku gdy chcemy w pełni testować aplikację ze ścieżki Start -> Microsoft Surface SDK 1.0 SP1 -> Tools uruchamiamy Surface Simulator jako administrator i uzyskujemy dostęp do pełnego symulatora włączając odczyt plików definicji z C:\ProgramData\Microsoft\Surface\Programs oraz symulację wielu aktywnych punktów (Visual Studio samo wykryje włączony symulator i odpali na nim nasz debugowany program).
- Co do samej implementacji “rozciąganych” kontrolek to mamy dostęp do kontrolki ScatterViewItem która pozwala na ustalenie minimalnych i maksymalnych rozmiarów.
- W przypadku gdy chcemy uzyskać standardowe skalowanie kontrolek to sugeruje używać Viewbox-a który będzie ładnie zoomował np osadzone zdjęcie.
- W przypadku gdy chcemy uzyskać bardziej skomplikowane skalowanie, np tak aby tylko jeden element się powiększał w miarę rozciągania – to wtedy sugeruje użyć Grid-a z ustawionymi kolumanmi / wierszami na autodopasowanie.
Download:
– SurfaceBlip – źródła
– SurfaceBlip – instalator
Galeria screenów aplikacji:
 |
 |
 |
 |
 |
Designery kontrolek w .NET Compact Framework
Ktokolwiek tworzył edytory kontrolek w Windows Forms, wie że jest to droga przez mękę. Jednak to co go czeka w Compact Framework można tylko nazwać drogą przez piekło 
O ile w standardowych Form-sach designer może być zawarty w bibliotece kontrolki w CF jest to niewykonalne. Wynika to z błahej przyczyny – braku implementacji edytorów w bibliotekach CF. A więc jak to zrobić?
Tworzenie edytora dla określonej kontrolki musimy zacząć od stworzenia Windows Class Library:
Kolejnym krokiem jest dodanie referencji do System.Design abyśmy uzyskali dostęp do base-owych edytorów:
W tak przygotowaną bibliotekę możemy dodać naszą klasę edytora. W naszym przykładzie stworzymy klasę edytora dla kontrolki ToolBar:
internal class ToolBarDesigner : ControlDesigner
{
public ToolBarDesigner()
{
}
}
Zadaniem tego designera będzie powiązanie buttonów dziedziczących po klasie Component z naszym ToolBar-em. Powiązanie to jest wymagane przy wykonywaniu przenoszenia / kopiowania ToolBar-a z jednego form-a na drugi. Zrealizujemy je przez przeciążenie właściwości AssociatedComponents ControlDesigner-a:
public override ICollection AssociatedComponents
{
get
{
ToolBar control = this.Control as ToolBar;
if (control != null)
{
return control.Buttons;
}
return base.AssociatedComponents;
}
}
Następnym krokiem jest powiązanie naszego designera z konkretną kontrolką. Aby to uzyskać musimy wskazać naszemu ToolBar-owi jakiego edytora ma używać. Jednak nie możemy tego wykonać przez bezpośrednie wskazanie klasy a przez referencję do biblioteki.
Na początek podpisujemy bibliotekę kluczem:
W kolejnym kroku musimy ją zarejestrować w Global Assembly Cache. Aby sobie ułatwić zadanie możemy rejestrowanie dodać do zdarzeń po kompilacji:
“C:Program FilesMicrosoft Visual Studio 8SDKv2.0Bingacutil.exe” /u “$(TargetName)”
“C:Program FilesMicrosoft Visual Studio 8SDKv2.0Bingacutil.exe” /i “$(TargetPath)”
Pierwsza linijka wyrejestrowuje bibliotekę a druga rejestruje.
Ostatnim krokiem powiązania jest wskazanie w pliku Design-Time Attribute klasy (o tych plikach pisałem w tym artykule), która ma być użyta jako edytor:
<?xml version="1.0" encoding="utf-16"?> <Classes xmlns="http://schemas.microsoft.com/VisualStudio/2004/03/SmartDevices/XMTA.xsd"> <Class Name="Cubicsoft.WindowsMobile.Controls.ToolBar"> <Designer> <Type>Cubicsoft.WindowsMobile.Controls.Design.ToolBarDesigner, Cubicsoft.WindowsMobile.Controls.Design, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c223de6bc083912b</Type> <BaseType></BaseType> </Designer> </Class> </Classes> </xml>
W wyniku otrzymujemy funkcjonalność przenoszenia powiązanych komponentów między form-ami.
Atrybuty designerów w kontrolkach .NET Compact Framework
Każdy kto kiedykolwiek stworzył choćby jedną kontrolkę w Compact Framework zauważył, że ilość atrybutów właściwości / klas jest bardzo ograniczona. Praktycznie .NET CF implementuje tylko następujące atrybuty:
- DefaultValueAttribute (tylko w wersji jedno parametrowej gdzie można podać wartość)
- DesignTimeVisibleAttribute
- EditorBrowsableAttribute
Brak ten wynika z faktu, iż .NET Compact Framework nie wspiera automatycznie Visual Studio designerów.
Aby zapewnić sobie pełen wachlarz atrybutów trzeba do projektu dodać plik design-time atrybutów:
Dodany plik ma następującą zawartość:
<?xml version="1.0" encoding="utf-16"?> <Classes xmlns="http://schemas.microsoft.com/VisualStudio/2004/03/SmartDevices/XMTA.xsd"> </Classes>
Aby dodać kontrolkę wystarczy dodać następujący element:
<Class Name="Cubicsoft.WindowsMobile.Controls.Label"> </Class>
Kolejne klasy muszą być potomkiem “Classes”. Choć wg. mnie dobrym zwyczajem jak w przypadku “zwykłych” klas jest przyjęcie zasady: jeden plik na jedną kontrolkę.
Warto rozpocząć definiowanie parametrów od atrybutu DesktopCompatible, aby ustrzec się błędęm “Visual Inheritance is Currently Disabled” który może się pojawić w momencie dodania kontrolki do Form-a:
// włączenie DesktopCompatible <DesktopCompatible>true</DesktopCompatible>
Kolejne elementy jak DefaultProperty, DefaultEvent itp. dotyczą oczywiście klasy.
Właściwości definiujemy w następujący sposób:
<Property Name="BorderStyle"> <Category>Appearance</Category> <Description>Indicates whether the label should have a border.</Description> </Property>
Edytor w pełni wspiera IntelliSense, więc pisanie kolejnych elementów jest dziecinnie proste.
Wynikowy plik dla kontrolki Label może wyglądać tak:
<?xml version="1.0" encoding="utf-16"?> <Classes xmlns="http://schemas.microsoft.com/VisualStudio/2004/03/SmartDevices/XMTA.xsd"> <Class Name="Cubicsoft.WindowsMobile.Controls.Label"> <DesktopCompatible>true</DesktopCompatible> <DefaultProperty>Text</DefaultProperty> <Property Name="BorderStyle"> <Category>Appearance</Category> <Description>Indicates whether the label should have a border.</Description> </Property> <Property Name="BorderColor"> <Category>Appearance</Category> <Description>The border color of this component.</Description> </Property> </Class> </Classes>
Po zapisaniu i skompilowaniu biblioteki otrzymamy dodatkowy plik o rozszerzeniu [Nazwa biblioteki].PocketPC.asmmeta.dll jest to biblioteka, która zawiera nasze nowe definicję atrybutów dla designerów.
-
-
- Subskrybuję kanał użytkownika LiquidGenerationTube w YouTube. http://www.youtube.com/user/LiquidGenerationTube?feature=autoshare
- I uploaded a YouTube video -- Studio Architektoniczne LA - spot na telebim http://youtu.be/hYQGtfWX_eE?a
- RT @pocketnowTweets: HTC1 Concept Shown Off http://is.gd/dpikC
Follow me @JakubFlorczyk -
-
