Detekce spojeni s ActiveSync

Celkem dlouho jsem na netu hledal, jak zjistit, ze zarizeni bylo pripojeno k desktopovymu PC pres ActiveSync. Hodi se to, kdyz potrebujete zprostredkovat PDAcku pripojeni k internetu, ale nemate/nechcete se pripojovat pres GPRS/WiFi/atd. Pokud je desktop pripojenej do netu, tak jde vyuzit tohoto spojeni, k cemuz vam pomuze ActiveSync. Do celkem dlouhem hledani jsem na to tedy nejak prisel a delal jsem to takhle:

u_long deviceIP = GetDeviceIP();
// zmenila se IP adresa?
if (deviceIP != LastDeviceIP) {
  if (deviceIP == GetUsbCableIp()) {
    // Cradled!
    return TRUE;
  }
  LastDeviceIP = deviceIP;
}
return FALSE;

Funkce GetUsbCableIp() enumeruje sitove adaptery a kdyz najde adapter s nazvem ‘USB Cable:’, tak vrati jeho IP adresu. Tohle mi funguje celkem spolehlive, presto si nekteri uzivatele stezovali, ze detekce cradlingu nejak pokulhava.

Kdyz jsem hledal, proc mi poradne nefunguje spojeni pres ActiveSync, nasel jsem zminku o domenovem jmenu ppp_peer. Pokud zavolame gethostbyname(”pp_peer”), ziskame nasledujicim kodem IP adresu desktopoveho PC, ke kteremu jsme pripojeni:

u_long nRemoteAddr = 0;
lpHostEntry = gethostbyname("ppp_peer");
if (lpHostEntry == NULL) {
  nRemoteAddr = INADDR_NONE;
}
else {
  nRemoteAddr = *((u_long *) lpHostEntry->h_addr_list[0]);
}

Pokud jsme pripojeni, IP adresa by mela byt vzdy 192.168.55.100, coz je pry jeste z historickych dob Windows CE 1.0 a 2.0. Takze zjisteni, zda jsme pripojeni se nam zasadne zjednodusuje. Pokud neni zadne pripojeni funkce vrati 255.255.255.255, pokud jsem pripojeny pres dial-up (BTH k telefonu), vratila funkce 0 a pokud jsem byl pripojen pres NAP nebo WiFi, tak jsem dostal zase 255.255.255.255.

Jeste uvidim, jak to projde beta testovanim. Verim ale, ze to bude ok.

Spojeni pres ActiveSync v pRSSreaderu II.

Takze konecne jsem se dostal k otestovani spojeni pres ActiveSync. Nastavil jsem, aby AS pouzil misto ‘The Internet’ spojeni ‘Work’, pustil plnej update. Vysledek? Porad to ma problemy se to pripojit. Chybovy kod je 10061, coz je ‘Connection refused’ - sluzba nebezi. To je ale kravina, protoze sluzby bezi, jelikoz se na ne da pripojit. Takze jsem tam, kde jsem byl. A porad to vypada na neco vyprasenyho v ActiveSync, ale co to je, to teda nevim a nevim, jak to ten PIE dela, ze se porad dokaze pripojovat.

Nejaky tutorialek od MS by neskodil…

No nic, jdu zkoumat dal, treba na neco narazim. Zkusim zdrojaky k minimo, tam bych na neco narazit mohl…

Cachovani priloh (enclosures) v pRSSreaderu

Dneska jsem opravil chybu v cachovani priloh - enclosures. Kde byl problem? Pokud feed nabizel prilohu, ktera mela URL ve tvaru server-cesta-soubor-pripona, bylo vse ok. Pokud ale bylo URL ve tvaru server-cesta-soubor-pripona-parametery, tak priloha nesla otevrit. Problem byl v tom, ze se spatne zjistovala priloha.

Takze jsem predelal zachazani s priponou. Vzal jsem soubor, zjistil cim ho otevrit, predal shellu a celak, ze shell se o zbytek postara. Ale ouha. Shel sice pustil aplikaci, ale soubor neotevrel. Problem je v tom, ze soubor nekonci tou spravnou priponou.

Takze jsem kompletne upravil prepisovani URL na soubory v cache. Nyni se pripisuji do tvaru server-cesta-soubor-paramtery-pripona. Tim padem uz se otevre vsechno dobre, ale problem je v tom, ze to neni uplne zpetne kompatibilni. Takze to co bylo nacahovano drive nemusi pRSSreader v cachi videt :(

V souvislosti s tim jsem jeste opravil chybu pri mazani obrazku, ktere jsou linkovany primo feedem. V testech cachuji obrazky z feedu google news a slashdotu. Ale obrazky se nemazaly. Dneska jsem prisel na to proc. Vtipne umistena podminka if (!IsFileExists) pri ziskavani seznamu obrazku ve feedu toho byla pricinou. A pak se divim, proc to vraci prazdny seznam.