A .NET alapvetően a COM rendszer mellé készítette a Microsoft. Célirányosan C# nyelvhez, de idővel mindig megjelent az adott keretrendszer az általa támogatott programozási nyelveken is (VB, J#). A CF típusjelölés ezen keretrendszerek Compact változata, amit az MS a mobil rendszereihez szán. Alapvetően ezek a mobil rendszerek Windows CE (Embedded Compact) alap kernellel rendelkeznek, és ezt specifikálják az adott eszközhöz. Ezért a CE dobozos változatban nem is kapható, csak OEM for Device Maker, azaz közvetlenül a gyártótól az adott eszköz fejlesztőnek (Original Equipment Manufacturer). Mivel a MS fő üzletprofilja nem a mobil piac volt, így alapvetően a CF keretrendszer, az eredetihez képest igen visszamaradott volt. A GUI támogatást leszámítva, szinte minden mást C++ metódusok importálásával kellett megoldani, ezért ezen platformokon a fő programozási nyelv a C++ maradt (illetve a Basic-PPC). A 1.0 Open source változat után, sorra jelentek meg (évről-évre) az újabb változatok, amik egyre szélesebb körben támogatták a beágyazott rendszereket, és hozták át az asztali platformon már használatos featureket. A .NET 4.0 után közvetlenül megjelent .NET CF-re szánt változata, amit leginkább a Xbox 360 és a Windows Phone 7-re optimalizáltak. Eddigiekkel ellentétben a Framework nem is tölthető le, az adott rendszerekben közvetlenül bele van integrálva. Hatalmas erőpróba a Microsoftnak, hogy a fent felsorolt két platform csak a .NET CF 4.0 (sőt ez első napokban csak C#.NET ) segítségével programozható. Részletes bemutatásra ki is emelném a WP7 platformot, amin bemutatnám a kommunikációs elgondolást, a támogatott elemeket, és megoldásokat.
A WP7-el a MS a mobil piacon igen könnyen feladott pozícióját szerette volna visszavenni. Ehhez triviális, hogy nem elég szép és jó telefont adni, hanem arra megbízható, jó programokat is kell szolgáltatni. Erre a redmondi cég egyedül alkalmatlan. Ezért hívja segítségül a „szabad világ programozóit”.
Ez azonban nem garantálhatja hogy a WP7 stabil, és üzembiztos marad. Így megszorításokat alkalmaz több szinten is, ellenbem a teljes fejlesztő környezetet ingyen adja, sőt még Piacteret is a szolgálatunkra bocsátja. A fent látható kommunikáció majdnem triviálisnak mondható, kivéve a felső harmadot. De kezdjük alulról:
Mint minden piactéren, itt is szabályok vannak. A két legszigorúbb szabály a METRO design, és a performancia. A .NET 4.0 CF-et alapvetően úgy alkották meg, hogy a fejlesztő környezetben már használja a METRO design szabályait. Egyik legszignifikánsabb dolog, a gombok kiterjesztése. Komoly méréseket folytatott a MS azért, hogy meghatározza, hogy mi az a legkisebb gomb, amit még a felhasználó nagy valószínűséggel eltalál, illetve mennyivel talál mellé. Ezt kihasználva, a gombok, sőt minden UI Control rendelkezik kiterjesztéssel, azaz nem csak a látható felületen érzékeli az interakciót, hanem egy nála valamivel nagyobb térben is a malájénak tudja. Performancia téren leginkább tárhely, és reakció időben vannak kitételek, nem beszélve arról, hogy a platform nem támogatja a natív kódot, azaz egy Just In Time complier is lassítani fogja a processeinket.
A UI kezelésére Windows Presentation Fundation nyújt nekünk segítséget. A Silverlight és a .NET ezen integrációval először a 4.0-ban találkozhatunk, megjegyezve, hogy az asztali keretrendszer tartalmaz olyan várva-várt elemeket is, amik bizonyos okok miatt nem kerültek bele a CF-be. Silverlight közel azonos eszközkészlettel rendelkezik, mint a sima .NET, de mivel ez alapvetően a Webes és erősen animált felületek megjelenítésére lett tervezve, így vannak változtatások:
A MS telefonjainak megbízhatóságát, a szolgáltatások kárára maximalizálta (ná). A tárhelyet teljes egészében a telefon használja. Nincs Browser, nincs semmi, amivel belenyúlhatnánk, vagy tárolhatnánk rajta. Ezért az applikációnk tárhely igényét az izolált tárhely elégítheti ki. Az izolált tárhely a programjaink sandboxában rendelkezésre bocsátott storage. Csak ő fér hozzá, és csak akkor, amikor a program benn van a homokozóban. Miután ezt a megoldást már a SilverLight is alkalmazza, így ez nem a Microsoft.Mobil névtérben található – mint ahogy sejtenénk – hanem a System.IO-ban
Elérése tökéletesen megegyezik az asztali keretrendszeren használatossal. (lásd WCF)
Azzal, hogy egy sandbox van a kezünkben, a MS ideiglenesen (tudtommal már tervben van a Multi-task bevezetése a mobil platformon) kivette a kezünkből a multitaskot. Azért, hogy a felhasználó érzetét megtartsa, a MS a tombstoningot hívja segítségül. A tombstoning az alkalmazás életciklusába szól bele, úgy hogy megkülönbözteti az Indítást az Újraaktiválástól, illetve a bezárást a deaktiválástól. Különböző események segítségével elmenthetjük a programunk állapotát az Izolált tárhelybe, vagy a direkt erre a célra készített PhoneApplicationService-be, ami egy kulcs / objektum párba menti az applikációnk adatait.
Abban az esetben, a készített szoftverünknek mégis szüksége lenne arra, hogy folyamatosan információkat kapjon az internetről, annak ellenére is, hogy deaktiválva van, a MS lehetőséget nyújt egy úgynevezett Notification Service segítségével. A Service-re feliratkozhatunk, és a kliens oldalnak megmondhatjuk, hogy milyen programnak érkezik, milyen azonosítójú és típusú üzenet. Az üzeneteknek 3 típusa van: