.NET i takie tam

Archive for Czerwiec 2008

Named Events – komunikacja między procesowa

2 komentarze

System Windows udostępnia nam mechanizm komunikacji między procesowej który wykorzystuje tzw. named events. Dzięki niemu możemy sygnalizować jak i monitorować, dowolnie utworzone przez nas zdarzenia np. pomiędzy dwoma różnymi programami, lub bądź chyba częściej spotykany, pomiędzy różnymi wątkami pracującymi w ramach jednej aplikacji. Ograniczeniem tego mechanizmu jest brak możliwości przekazywania danych, służy on jedynie do sygnalizacji.

Implementacja w .NET

Implementacją tego mechanizmu na platformie .NET jest klasa WaitHandle i jej pochodne jak np. EventWaitHandle. Jak to wszystko działa? Ano bardzo prosto, najpierw musimy niejako zarejestrować nasz event, przykładowo:

EventWaitHandle signal = new EventWaitHandle(false,
     EventResetMode.AutoReset, "UniqueSignalName");

Określamy czy w momencie utworzenia zdarzenia, (jest to zdarzenie tyle, że nie w .NET’owym jego sensie), powinno być ono zasygnalizowane, parametr false. Następnie określamy za pomocą EventResetMode określamy sposób pracy. Do wyboru mamy AutoReset który zaraz po naszym sygnale przywróci poprzedni stan naszego zdarzenia i ManualReset który pracuje jak jak bramka, tzn. po włączeniu wysyła sygnał tak długo aż jej sami nie zresetujemy. Ostatni parametr jest domyślny i określamy w nim nazwę naszego eventu, szczególnie przydaje się gdy planujemy komunikację między procesami które nie będą miały dostępu do referencji naszego zdarzenia (np. pomiędzy różnymi aplikacjami). Nazwa jest globalnie widoczna w systemie i każdy proces może obserwować jej zmiany, (pomijam tu kwestie związane z uprawnieniami systemu Windows) .

Tak utworzonym obiektem możemy swobodnie operować. Aby dokonać sygnalizacji korzystamy z metody Set(). W przypadku gdy EventResetMode ustatiliśmy na ManualReset aby wyłączyć ‚sygnał’ musimy skorzystać z metody Reset().

Przydatną metodą jest statyczną metoda OpenExisting klasy EventWaitHandle które umożliwia nam pobranie referencji do utworzonego przez nas zdarzenia, na podstawie jego nazwy np.:

EventWaitHandle signal =
    EventWaitHandle.OpenExisting("UniqueSignalName");

Gdy kończymy korzystać z naszego obiektu EventWaitHandle zwalniamy jego zasobu przy pomocy metody Close().

Nasłuchiwanie zmian

Niestety mechanizm ten nie został zautomatyzowany i sami musimy sprawdzić czy aby nie zaszło któreś z interesujących nas zdarzeń. Pomogą nam w tym statyczne metody klasy WaitHandle: SignalAndWait(), WaitAll(), WaitAny(). Przykładowo poniższy kod oczekuje na któryś z dwóch sygnałów i dla każdego z nich wykonuje inną operację:

int ev = EventWaitHandle.WaitAny(new WaitHandle[] {signalA, signalB});

switch (ev)
{
    case 0:
        Console.WriteLine("Signal A ...");
        break;
    case 1:
        Console.WriteLine("Signal B ...");
        break;
}

Zwykle kod nasłuchujący warto jest umieścić w osobnym wątku aby nie blokować głównej pętli programu.

Przykład

Przykład składa się z dwóch prostych aplikacji konsolowych z których jedna tworzy zdarzenia (EventCreator) a druga ich nasłuchuje (EventSubscriber). Uruchamiając należy pamiętać o kolejności.

Named Events Sample

Implementacja w .NET CF

W najnowszej wersji .NET Compact Framework 3.5 pojawiła się implementacja klasy EventWaitHandle niestety pozostawia ona sporo do życzenia. Przede wszystkim nie umożliwia nadawania nazwy naszym zdarzeniom co ogranicza nas do komunikacji w ramach jednej aplikacji. Nie udało mi się również zmusić jej do współpracy z metodami natywnymi (P/Invoke). Nic jednak straconego, w książce ‚Mobile Development Handbook‚ autorzy zamieścili własną implementację, pracującą poprawnie jak i zawierającą kilka dodatkowych metod dostępnych w pełnej wersji .NET Framework’s. Kod źródłowy przykładów załączonych do książki można znaleźć tutaj.

Written by sakowicz

Czerwiec 27, 2008 at 3:28 pm

Napisane w Misc

Device Security Configuration

leave a comment »

Znacie to uczucie gdy czas was goni, a narzędzia które normalnie działają, postanawiają sobie zrobić wolne? Myślę, że tak. Pół biedy jeśli przyczyna niesprawności jest nam znana – wtedy możemy się zżymać na złośliwość rzeczy martwych. Jeśli jednak nie mamy pojęcia gdzie leży problem, nie pozostaje nam nic innego jak uzbroić się w cierpliwość i szukać rozwiązania.

Dzisiaj ni stad ni zowąd Device Emulator postanowił odmówić mi współpracy. Próby uruchomienia aplikacji z poziomu Visual Studio 2008 kończyły się następującym komunikatem:

„Error 82 The device security configuration disallowed the connection. Ensure that you have the appropriate certificates on your device for development. Review your SDK documentation for proper security settings for connecting to this device. Device Connectivity Component „

Jakimś trafem emulator zgubił moje certyfikaty SDK. Aby je przywrócić możemy skorzystać z Device Security Manager’a (VS 2008 menu Tools). Łączymy się do wybranego urządzenia a następnie wybieramy opcję Certificate Management. Zostaną nam wylistowane wszystkie dostępne certyfikaty danego urządzenia. Następnie Add Certificate:

VS 2008 Add Certificate

i Manage Certificates:

Manage Certificates

Wybieramy przycisk Import i wskazujemy lokacje plików *.cer. Domyślnie dla Windows Mobile 6 SDK znajdują się one w katalogu: C:\Program Files\Windows Mobile 6 SDK\Tools\Security\SDK Development Certificates. Musimy zainstalować osobno trzy certyfikaty: FailsafeEmulator.cer, SamplePrivDeveloper.cer, SampleUnprivDeveloper.cer i gotowe.

Jedno mnie dziwi, zanim re-importowałem certyfikaty, powyższy problem występował niezależnie jakiego obrazu korzystałem. Jednak po ich zainstalowaniu, tylko na jednym ‚urządzeniu’, wszystkie inne również zaczęły działać.

Written by sakowicz

Czerwiec 25, 2008 at 4:49 pm

Napisane w Misc

HTC, Android i Windows Mobile 7

leave a comment »

HTC ogłosiła wprowadzenie nowych systemów operacyjnych do swoich urządzeń. Chodzi mianowicie o Windows Mobile 7 i bazujący na linuxie Google Android. O ile produkt Google’a jest gotowy i dostępny do pobrania, Windows Mobile 7 jest cały czas w fazie przygotowania.

Microsoft zapowiada, że nowy system wyeliminuje bolączki poprzedników szczególnie te związane z interfejsem użytkownika. Osobiście jestem trochę sceptyczny, pamiętam szumne zapowiedzi Windows Mobile 6. I co z nich wyszło – ano Windows Mobile 5 z kilkoma nowymi funkcjami i nieco zmienionym interfejsem. Kluczowe problemy jednak pozostały. Na obronę MS możemy powiedzieć, że wraz z wydaniem systemu WM6 narzędzia developerskie zostały znacząco ulepszone, jednak to, chyba nie interesuje użytkowników końcowych.

Ostatnio miałem okazję, wziąć w moje łapki nowość HTC Touch Diamond, pierwsze odczucia – super. Idealne urządzenie PDA o rozmiarach małego telefonu – albo właściwszym było by powiedzieć telefon z funkcjami PDA. Duży ekran, przyzwoity aparacik i mógłbym się na niego skusić, nawet pomimo tego, że wolę urządzenia z pełną klawiaturą (tutaj Sony Ericsson Xperia X1 wygląda interesująco). Jadnak IMHO urządzenie cierpi na tą samą bolączkę co jego pierwowzór HTC Touch – fajne UI sporo wodotrysków (nie mówię, że tego nie oczekuję) ale urządzenie pracuje jakoś tak … wolno. Co jak co, ale książka telefoniczna powinna działać szybko, funkcjonalność przede wszystkim.

Teraz jestem ciekaw czy główną przyczyna problemów z szybkością leży po stronie urządzenia czy systemu? Będziemy mogli sobie to porównać gdy np. HTC wprowadzi swojego Diamond’a z systemem Google Android. Cokolwiek by nie było, pojawienie się nowych systemów, to krok w dobrą stronę. Na pewno spowoduje sporo trudności z synchronizacją danych, kompatybilnością aplikacji myślę jednak, że wzmoże on konkurencję i przypomni gigantowi z Redmond, że niemożna zasypiać gruszek w popiele.

Update 23/06/2008:

Właśnie sobie czytam o poprawkach w TouchFLO 3D dla HTC Diamond’a. Widać nie tylko ja zwróciłem uwagę na jego powolne działanie.

Written by sakowicz

Czerwiec 20, 2008 at 9:44 am

Napisane w Devices, Misc