Windows Phone 7 – Elégtelen vagy csillagos ötös?
Itt és most leszögezném. 2010 márciu 21 reggel 10:26 CET van ebben a pillanatban és ebben a szent másodpercben én egy IPhone 3GS rendkívül elégedett tulaja vagyok. Fél évvel ezelőtt még én is a Windows Mobile 6.1-es user-ek nem tűl népes, de annál elégedetlenebb csoportjának voltam roppant frusztrált tagja. (Ez a készülék egyébként egy HTC Touch Diamond volt.) Ezt azért tartom fontosnak kihangsúlyozni, hogy ne lehessen elfogultsággal vádolni 🙂
Szóval a Mix 2010-en ugye megtörtént a várva várt Windows Phone 7 bejelentés, ahol meg tudtunk jó sok információt arról, hogy mit várhatunk a platformtól. Rögtön ki is tört a frász developer körökben pár hiányosság miatt. Szeretném most ezeket tisztázni és egy helyen összefoglalni a veleményem ahelyett, hogy különböző forum post-okban tenném ezt meg.
1. Nincs Multi-Tasking.
Éééés tényleg nincs. Ebben a pillanatban a wp7 nem támogatja az alkalmazások párhuzamos futtatását és EZ jó! Mégis mekkora a kijelző azon a telefonon? Fogunk tudni rajta nyitva tartani 2-3 ablakot egyszerre? Dehogy! Arra a kis kijelzőre mindig azt az alkalmazást kell kirakni, amivel éppen dolgozunk! Ritka az a szitu, amikor tényleg szükséged van arra, hogy a háttérben fusson vmi extra alkalmazás. A legtöbb natív funkció párhuzamosított akárcsak az iphone esetén azaz (bár ezt még nem próbáltam ki) de pl lehetőséged lesz egyszerre zenét hallgatni és netezni. Képzeld el a szitut, amikor a háttérbe berakja a User az alkalmazásodat, ott hagyja, és az meg jó leszívja az aksiját… kicsit kiakadna… és mi a sz*r? Nem a te alkalmazásod, hanem a telefon!
Erre te azt mondod, hogy najó, de az alklalmazásaim real-time adatokat kell fogadjanak és megjelenítsenek! Én pedig azt válaszolom, hogy erre való a push notification. Van vmi üzenet, a push notification kirakja, a user rábök és elöjön az alkalmazásod egyetlen pillanat alatt. A Taskok közötti váltás baromi gyors, ezt az IPhone 3GS már bebizonyította. Ez az információ még nem is létezett a wp7-ről mikor már azt mondtam, hogy ha az MS észnél van, kihagyja a multitask-ot, mert ez mobil és nem PC. (Tanúm is van rá Orosz Gábor személyében! 🙂 )
2. Nincs Copy-Paste
Na igen a copy-paste tényleg egy olyan apróság, ami hiányzik. Akkor most építkeznék a saját és egy két imserősöm tapasztalatából, de pontosan mit is copy paste-elünk? Telefonszámot, email címet és hiperhivatkozást. Ha ezeket felismeri és a szükséges műveleteket el lehet végezni (call, create new contact, assign to contact stb…) akkor én erről le tudok mondani. Ettől függetlenül későbbi verziókba biztos bekerül ez a funkció is.
3. Nem fér az alkalmazás a filrendszerhez.
Helyes! Ne is férjen! Erre való az Isolated Storage! Valamit elbarmol a progi, mit mond a user? Sz*r a telefon! Dolgozzon csak oda, ahol senkit sem bánthat… Ez nem egy PC!
4. Nincs alklalmazás telepítés USB-rőr, csak a Marketplace-ről.
Na most a user 2 dolgot nem akar. 1: Ne legyen elég profi alkalmazás a telefonjára. 2: Hekkelni, hogy egy alkalmazás felmenjen. Mit akar a user? Két dolgot: 1: Stabil, ellenőrzött minőségi programokat. 2: Egy kattintásos telepítést… Kinéz vmit a marketplace-en és egy gombnyomással telepíti… esetleg olvasi némi review-t az alkalmazásról. Ismét bevált modell az Apple AppStore-ja a követendő példa.
Mit akar egy profi fejlesztő? Azt, hogy az alkalmazását könnyen tudja disztributálni, ne legyen vele probléma és el kérhesse az árát. (Ha ingyen adja, az ő dolga) Ha jó az alkalmazása, akkor szeretné, hogy a review-k, rating-ek ezt tükrözzék. Mi a megoldás? A marketplace!
Őszinte leszek, ha ez nem így lenne, hanem bárhogy fel lehetne kalózkodni a programokat a telefonra, engem, mint fejlesztőt abszolút nem érdekelne ez a platform!
5. Csak menedzselt kódot tudsz futtatni
Még jó! Gagyi kód –> memory leak –> user szerint sz*r a telefon! Erre való a garbage collector.. legalább miután az alkalmazásod leáll, hadd takarítsa ki a memóriát… Különben is mihez szeretnél hozzáférni alacsony szinten? A sensorok, GPS vevők, multitouch stb rendelkeznek normális menedzselt felületekkel. Az alap OS taskokat, sms küldés, email küldés stb elérhetjük szintén menedzselt felületen. Több dolog default 3d gyorsítást, vagy hardware gyorsítást kapott… Mi kellene még?
6. Túl sok a kényszer a megkötés miért van ez?
Ez nem egy PC. Nem a geekeknek, fejlesztőknek készült. A cél közönség az átlag egység sugarú user. A UX extrém fontosságot kap. Innentől kezdve, nem lehet semmi lassú, nem lehet semmi komplex, vagy átláthatatlan, one click experience mindehova ahováa csak kell… Alapvetően mire fogják használni ezt a telefont? Netezésre, email olvasásra, social networkingre, és játékra! Ez a main priority. Aztán jönnek az extra kisebb alkalmazások és a végén kullog valahol jelenleg az üzleti alkalmazás stb… Ennek megfelelően muszáj olyan megkötéseket bevezetni, ami nem engedi a felhasználót elveszni, nem engedi, hogy az alkalmazások hibájából a felhasználó azt mondja, hogy ez a telefon sz*r…
7. Beépített belső memória, ami nem bővíthető
Ha így is van / lesz… és? Én 16GB-on csellengek most és még nem csúsztam be 8GB alá… pedig használok ezt azt!
Összegezve, hogy csillagos ötös-e ez azt nem tudom, előbb a kezemben kell fogjak egy igazi nem prototípus release példányt. De az hogy egyes vagy akár hármas, magasan kizárnám. A developer élmény a csillagokban van még így is (pedig pár dolog azért hiányzik), a UX magáért beszél, az átlag user szeretni fogja! Pár hete olvastam egy közvélemény kutatást az IPhone-nal kapcsolatban, ahol arról volt szó, hogy a felhasználók egy jelentős része körében érzelmi kötödés alakul ki a telefonja iránt, elvesztése számukra egy nagyobb tragédia lenne, és gyakrabban hagyják otthon a pénztárcájukat, mint a telefonjukat. Ezt jelenleg egyetlen más telefon sem mondhatja el magáról… Ez az a piac ahova be kell törnie a Microsoftnak. És most jön el az a pont, amikor a Címeket olvasd át most MÉGEGYSZER! Szerinted melyik fog hiányozni a user-nek? Megsúgom. Egyik sem! És most szerencsére élhetek azzal a luxussal, hogy tapasztalatból mondhatom, hogy ha a fejlesztői gondolkodás átáll arra, hogy ez nem PC, hanem a felhasználó egy része!!!!! ami kapcsolattartást biztosít az online világgal, akkor a fejlesztőknek sem.
Ha érdekelnek további információk és részletek a Windows Phone 7-el kapcsolatban, akkor 1 hónapon belül 2 Mo-i eseményen is hallhatsz róla:
1. Silverlight Klub március utolsó hetében
2. Visual Studio 2010 Launch konferencia április 12-én – Windows Phone Session
Végül pedig, hadd idézzem egy MSFT-s fickó szavait: “Focus, focus, focus” … “focus on the end user”
Silverlight 4 RC és Windows Phone 7 tools
No, hát megvolt a MIX 2010 Keynote is és olyan dolgokat láttunk hogy a hajam letettem… a legnagyobb durranás persze a Windows Phone 7 volt, a hangsúly is 90%-ban azon volt. Mint kiderült a Windows Phone fejlesztés ingyenes lesz VS2010 Express-szel De az örömhír most jön. Lehet kedzeni fejleszteni:
Silverlight 4 RC Tools for Visual Studio 2010
Windows Phone Developer Tools CTP
Expression Blend 4 Beta Add-in for Windows Phone
Expression Blend 4 Beta SDK for Windows Phone
Nyomás kipróbálni!!!
Jogosultság kezelés Team Foundation Server-ben
Többekben felmerült a kérdés, hogy miként lehet létrehozni különböző user group-okat majd azokhoz több szinten hozzáférést meghatározni. Ha már amúgy is írtam volna rá egy tutoriált, inkább hadd lássa hát mindenki. Plussz a JetLag sem segít az alvásban…
Hát az első és legfontosabb, hogy ha van egy user group-unk, mondjuk developers, akkor vegyük őt fel a TFS-be.
A TFS alapból 4 fő role-t definiál:
- Readers – csak olvasási joggal rendelkeznek, ide vesszük fel azokat a csoportokat, akik nem járulnak hozzá a projekthez, csak felügyeleti, követési szerepük van
- Contributors – tudnak írni és olvasni is, általában ebbe vesszük fel a fejlesztőinket
- Project Administrators – A projektűnk admin-ja, aki lényegében szinte bármit végrehajthat a projekten.
- Builders – Olyan felhasználók, akik a buildeket tudják menedzselni. Build definíciókat tudnak létrehozni, módosítani, buildeket futtatni stb…
Vegyük hát fel a groupunk / user-ünk a Contributors-ba:
Projekten jobb klikk, Team Project Settings / Group membership…
Kiválaszthatjuk a Contributors-t, majd properties, kiválasztjuk a Windows User or Group lehetőséget, és klikk Add:
Visszatérve a Project Groups ablakba láthatjuk, hogy saját custom group-ot is létre lehet hozni, amihez saját jogosultság készletet párosíthatunk, az add-ra klikkelve:
Klikk Close. Oké, de most milyen csoportjaink vannak, milyen hozzáféréssel pontosan? Újra klikkeljünk a Team Projet-ra egy jobbklikket, majd Team Project Settings / Security… A saját custom group-unk nincs a listában, de egy add-dal felvehetjük! Majd hozzárendeljünk a szükséges jogokat:
Hogyan lehet tovább finomhangolni a jogosultságokat?
Jobb klikk a Team Project-en / Team project settings / areas and iterations. Itt tovább finomíthatjuk, hogy melyik csoport melyik területen belül, melyik iterációban láthatja az információkat!
Egy tetszőleges területet, vagy area-t kiválasztva, nyomjunk a security-ra! Akár a root node-okra is klikkelhetünk!
Hozzá addoljuk a kérdéses group-unkat, majd hozzáadjuk a szükséges jogosultságokat. A fenti példában, pl a CustomGroup az adott Area-n belül módosíthat workitem-eket, teszt terveket, illetve az ebbe a node-ba tartozó workitem infókat láthatja.
Egy fontos dolog maradt még hátra, mégpedig a source control-hoz való hozzáférés! Dupla klikk a Source Control node-ra a team projekten belül, majd a source control folderből válasszunk ki egy tetszőleges folder-t, amihez a hozzáférést szeretnénk definiálni a CustomGroup-unk számára! Jobb klikk rajta, majd properties és security tab:
Jól látható, hogy egészen az alap lehetőségeket is be tudjuk állítani. Olvasás, becsekk, kicsekk, cimkézés, lockolás, Merging, branching stb…. Ha már itt tartunk, nem csak foldereken te brancheken is definiálhatjunk hozzáférési szabályokat. Ebben az esetben a teljes branch-re definiáljuk azt, amit az előbb csak folderekre:
Work-item szinten, work-item szinten is definiálhatunk szabályokat. Team Explorer-ben Team Project-en belül Work Items / Team Queries, majd ezen jobb klikk és security… Itt definiálhatjuk hogy az össze query-re vonatkozóan mit tehet meg az adott group. Olvasás, létrehozás, törlés, hozzáférés vezérlés.
Természetesen, nem csak a teljes Team Query node-ra, hanem a benne található egyes query-kre is külön definiálhatjuk a hozzáférési szabályokat.
Végül, de nem utolsó sorban a Builds node-on is van egy Security… ahol definiálhatjuk, hogy az összes build-re vonatkozóan az adott group milyen jogokkal rendelkezik… ezt persze buildenként is definiálhatjuk:
Gyakori probléma még, hogy az új user-ek a documents és a reports mappán egy kis piros X-et látnak. Ez azt jelenti (jobb esetben :D), hogy nincs hozzáférésük a sharepoint-on elhelyezett Team Site-hoz és a ReportServer által menedzselt reportokhoz. Ezeket az jogosultásokat a reporserveren, illetve a sharepoint-ban kell külön meghatározni, nem pedig a Team Explorerből.
No hát ezek lennének, a legfontosabb authorizációs mechanizmusok TFS alatt. Remélem extra gyors talpalónak hasznos volt, ha van valami kérdés, hát hadd záporozzon 🙂 Illetve érdekelne egy kis vélemény is: Jobb lenne ez a tutorial inkább egy 5-10 perces screencast-ban?
Silverlight Klub: MVVM, LOB demo és ppt
Tegnap este tartottuk a Silverlight Klub 2. összejövetelét, a téma a Line Of Business alkalmazások fejlesztése során felmerülő probléma halmaz, valamint az ehhez kapcsolódó prezentációs rétegben használható architektruális tervezési minták használata volt, közülük is kiemelve az MVVM (Model-View-ViewModel) pattern-t.
Volt szó sima Silverlight 4-ről, “építsd magad MVVM-ről”, Laurent Bugnion MVVM Toolkit-jéről, illetve a Composite Application Guidance (PRISM)-ről a Patterns & Practices csapattól. Akit érdekel, a demókat és ppt-m elérhetővé teszem most:
http://cid-51c821ae48394a3d.skydrive.live.com/embedicon.aspx/.Public/SLKlub_LOB_MVVM/MVVMDemos.rar
Továbbá, a kezdők számára korábban készítettem egy nagyon bevezető jellegű screencastot MVVM ügyben:
Visual Studio 2010 RC és .NET 4.0 Release Candidate elérhető
Bizony bizony, az MSDN előfizetők már rángathatják is le a kicsikét. Annyit tudunk róla elmondani, hogy a studio eszeveszett gyors lett. Agybafőbe veri a bétát és sokak szerint (twitter alapú hír) a 2008-at is! Február 10-től a teljes publikum számára elérhető, szóval már csak 1-et kell aludni 🙂
Kis negatívum, hogy bár az SL3-as projekteket teljes mértékben használhatjuk, addig a jelenlegi SL4 beta projectek nem támogatottak, szóval aki ilyesmi dolgozik, az jól beragadt egyenlőre 🙂 A hivatalos álláspont hogy meg kell várni a következő silverlight 4 biteket (remélem a napokban kapunk egy rc-t abból is…)
A csapat természetesen jelzi, hogy ez nem a végleges termék, már most is tudnak hibákról, egy csúnyább bug, hogy multitouch képes eszközökőn igen csúnyán becrash-sel, de természetesen már dolgoznak a hibán.
Természetesen a szerver termék sem maradhatott ki a buliból, így a Team Foundation Server 2010 Release Candidate is elérhetővé vált!
Itt érdemes körbenézni:
http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx
Tessék kipróbálni, aztán halljam azokat a feedbackeket!!!!!
Mi az a Managed Extensibility Framework?
Előfordult már valaha, hogy szerettél volna olyan alkalmazást késziteni, ami kellőképpen moduláris? Szerettél volna olyan alkalmazást irni, amelyhez könnyen készítenek kiegészitőket, plugin-eket mások? Persze, szinten minden fejlesztő találkozott már ilyen jellegű problémákkal, és amikor körül nézett a piacon a lehetséges megoldások után, azt kellett tapasztalja, hogy valami nehezebb súlyú megoldás kell választania. Épithet saját Interface alapú DI-s megoldásokat erősen Reflection alapokon (amit persze szintén maga implementál), de dönthet valamiféle 3rd party, netán MS megoldásokon.
Az egyik ilyen legismertebb technológia a PRISM, vagy a Composite Application Library. Ez lényegében egy óriási Toolbox számunkra, aminek a segitségével a fenti problémákra bevethetjük a Unity-t, mint IoC támogatást, illetve haszlnálhatjuk a Prism Module managementjét, amit szintén jó és kiforrott. Azonban egy ilyen keretrendszer nehézsúlyú, elég sok “extra” kódot és strukturálást igényel, amivel még megbarátkozik az ember, de azonkivül még, hogy elsajátitása abszolút nem egyetlen perc alatt történik 🙂 bizony a kiterjeszthetőségnek, hát hogy is mondjam szab némi határt. Persze ezzel is mindent meg lehet csinálni, lehet trükközni, passzolgatni UnityContainereket meg RegionManagereket, de a nap végén akkor sem épp az a legegyszerűbb, pehelysúlyú megoldás lesz, amit valójában szerettünk volna összehozni.
A .NET 4.0 részeként debütál a Managed Extensibility Framework, amely a fenti (rész)problémára nyújt egy könnyen emészthető, nagyon okos és elegáns megoldást. Lényegében, ha plugin baráttá szeretnénk alakitani az alkalmazásunkat,, ez a technológia lehet az első amihez érdemes nyúlnunk. Komplex alkalmazásoknál, ahol nem a külső kiterjeszthetőség elődleges szempont, továbbra is inkább a PRISM-et ajánlanám, de ha még sosem dolgoztunk PRISM-mel, akkor érdemes első körben megismerkednünk a MEF-fel.
Miről is van szó? Hogy Glenn Block-ot idézzem, a MEF alapjai összefoglalhatók 3 szóban:
- Exportálás
- Importálás
- Kompozícionálás
1. lépés – Exportálás
Oké, van egy Modulunk, ez a modul akármi lehet, mondjuk ebben fogalmaztunk meg egy ViewModel-t, vagy egy Repository-t, netán egy komplett kis UserControl van benne, ez mindegy is. Fel kell készitenünk őt arra, hogy valaki majd dinamikusan betöltse őt, abban az esetben, ha megfelel egy Contract-nak. Jelezününk kell a MEF-felé, hogy ez itt egy modul és betöltésre vár. Ez az exportálás folyamata.
Segitségül az ExportAttribute-ot fogjuk hivni, megjelöljük a modul-t a MEF számára, valamint ellátjuk egy jelzéssel, hogy mely csatolási ponthoz lehet őt kapcsolni. Ez a contract. A Contract több féle is lehet, én preferálom az interface-eket, vagy az absztrakt ősosztályokat, igy jobban lehet “kényszeríteni” a modul iróját a modul elvárt kialalkitására, működésére. De lehetséges csupán stringekkel hivatkozni arra, hogy én bizony egy adott tipusú modul vagyok.
String alapú contract:
1: [Export("MainModule")]
2: public class PluginAModule
3: {
4: //...
5: }
Absztrakt ősosztály alapú contract:
1: [Export(typeof(VisualComponent))]
2: public class PluginAModule : VisualComponent
3: {
4: //...
5: }
Ez mehet egy DLL-be (SL esetén akár egy külön XAP-be) stb…. A betöltésért a MEF lesz felelős.
2. lépés – Importálás
Oké, van egy alkalmazásunk, ahova szeretnék a modulokat betölteni. Ez az Importálás folyamata. Persze itt számos kérdéssel foglalkoznunk kell, hogy hova töltjük be a modult, mire jó az, hol helyezzük be, milyen memória menedzsmentet szánunk hozzá, hol van a modul stb… Az Importálást az ImportAttribute segitségével végezhezjük el, amelyen meghatározzuk, hogy milyen contract-nak megfelelő modulokat szeretnék hozzárendelni változóinkhoz, vagyis a csatolási pontjainkhoz.
String alapú contract esetén:
1: public class ExtensionManager
2: {
3: [Import("MainModule")]
4: public VisualComponent Component;
5:
6: //..
7: }
Absztrakt ősosztály alapú contract esetén:
1: //Egy modul esetén
2: public class ExtensionManager
3: {
4: [Import(typeof(VisualComponent))]
5: public VisualComponent Component;
6:
7: //..
8: }
9:
10: //Több modul esetén
11: public class ExtensionManager
12: {
13: [ImportMany(typeof(VisualComponent))]
14: public IEnumerable<VisualComponent> Components;
15:
16: //..
17: }
Abban az esetben, ha egy adott tipusú contract-nak megfelel több modul is, akkor a csatolási pont célszerűen egy lista kell legyen. Ez önmagában még nem elég, meg kell mondani a MEF-nek hogy ebbe a csatolási pontba bizony több modul példányt is várunk. Ezt az ImportMany attribútum segitségével érhettjük el.
3. lépés – Kompozícionálás
A 3. lépés lényegében a varázsütés “MÚKOGGY” 🙂 Ez az a pont, amikor azt mondjuk a MEF-nek, hogy oké, meghatároztuk a csatolási pontokat, légyszives csináld a dolgod és töltsd is be őket. Silverlight esetén az alábbi kis kódblokkal jelezzük ezt a MEF számára.
1: public class ExtensionManager
2: {
3: [ImportMany(typeof(VisualComponent))]
4: public IEnumerable<VisualComponent> Components;
5:
6: public ExtensionManager()
7: {
8: PartInitializer.SatisfyImports(this);
9: }
10: }
Most azt csinálunk a komponensekkel, amit csak akarunk, betöltjük őket egy ItemsControl-ba (már végig tudunk iterálni a Components-en), a funkcionalitásuknak megfelelően használhatjuk őket.
Hogy honnan tudja a MEF-hogy honnan kell betölteni a modulokat? Hát bizony meg kell neki mondani. A fenti példában lényegében a Silverlight alkalmazásunk XAP fájlában található dll-ek közt fog kutatni. De használhatjuk a Silverlight 4 Toolkit-ben debütált PackageCatalog objektumot, letölthetünk egy másik XAP fájlt és betölthetjük a modulokat onnan. Vagy hagyományos .NET Esetén használhatunk speciális objektumokat, amik a katalógusként szolgálhatnak. Igy például egy adott könyvtárban található dll-eket néz végig, vagy egy előre definiált xaml-fájlból olvashatjuk fel, hogy mely dll-ek hol találhatók, mely tipusok kellenek belőle stb…
A Managed Extensibility Framework hatalmas rugalmasságot ad a kezünkbe, éljünk hát vele, igazán egyzserű a használata.
Silverlight Out Of Browser alkalmazás debuggolása
Silverlight alkalmazásokat épp olyan könnyű debuggolni, mint bármely más .NET-es alkalamzást Visual Studio-ból. Picit furább a helyzet, hogy ha Out of Browser (OOB) alkalmazással van dolgunk, amikor az alkalmazásunk képes Offline, a böngészőn kivül is élni. Kis odafigyeléssel és körültekintéssel ugyan, de még mindig hatékonyan tudunk debuggolni VS alól. Silverlight 4.0-ban azonban megjelent a Silverlight azon képessége, hogy képes magasabb jogosultság készlettel futni, ez az ún. Elevated Permission, ezt a képességét azonban csak OOB módban tudja gyakorolni. És innentől kezdve a hagyományos debuggolás már nem is használható:
Az előző cikk épp arról szólt, hogy a Twitter API-val csak OOB módban, Elevated Permission-ök segitségével tudtunk kommunikálni. Ha elkezdjük hagyományos módon debug-olni az alkalmazást a következő történik:
Hopp egy SecurityException, de nem is csodálkozunk ugyanis böngészőben kezdi el futtatni az alkalmazást. Mit tegyünk?
1. Kézenfekvő megoldás, hogy kirakjuk az alkalmazást, elindítjuk, majd Debug / Attach To Process / sllauncher.exe.
A megoldás hátránya, hogy állandóan kézzel indithatjuk az alkalmazásunkat, majd a futó process-hez tudunk csak kapcsolódni, ami további problémákat felvet. Nem az igazi na! Nézzük mit tehetünk még!
2. Szerencsére van lehetőség azt mondani a Visual Studio-nak, hogy hagyja ezt a böngészőben futtatást, és a már lokálisan megtalálható Silverlight OOB instance-t debuggolja közvetlenül, minden egyes F5-ünkre!
Irány a Silverlight projekt / jobb klikk / properties / Debug / Installed out-of-browser application: Saját app beállitása
Ezt követően győződjünk meg róla, hogy a startup projet-ünk a silverlight alkalmazás, nem pedig az őt beágyazó website! (Jobb klikk az SL projekt-en / Set as StartUp Project)
És kész is… máris futtathatjuk az alkalmazásunkat és mostmár közvetlen OOB-ben tudjuk debuggolni F5-re.
Azaz OOB projekt debuggolásához három dolog kell:
- OOB alkalmazás már kint üljön a desktopon (install megtörtént)
- Project Properties / Debugban megmondjuk, hogy a telepitett OOB alkalmazást használja
- A Solution-ünkben a startup project az SL alkalmazás legyen, nem az ASP WebSite.
Visual Studio 2010 és .NET 4.0 dátum
Rövid és lényegre törő post:
A Microsoft a héten nyilvánosságra hozta a launch időpontját: 2010 április 12! (Barátnőm akkor ezt fogja kapni a szülinapjára :D)
Nem is kell olyan sokat szenvednünk, csupán 3.5 hét csúszás, valljuk be ezzel azért együtt tudunk élni 🙂
Közvetlen hozzáférés a Twitter API-hoz Silverlight 4.0 alól
Nem titok, hogy egy speciális anyagot fejlesztünk Fülöp Dávid kollegámmal, ahol a hangsúlyt a módszertanra helyezzük. A demó alkalmazás alapja egy Twitter modul lesz, azonban elég komoly problémába ütköztünk rögtön az első lépésnél. Azt hiszem Dávid barátunk meg is fog ölni pusztán azért, hogy 6-odszor iratom át vele a Twitter API-ját 😀 A probléma a következő:
A Twitter API gyakorlatilag REST alapú hozzáférést biztosit a twitterhez, igy HTTP GET és POST üzenetekkel tudunk lekérdezni státuszokat, illetve posztolni saját státuszt. Na most, mint minden tisztességes rendszerbe, ide is be kell tudni jelentkezni. Na de hogyan? Hát természetesen erre való a HttpWebRequest objektum Credentials property-je. (ami egy két verizóval ezelőtt még nem is létezett ugye….)
No hát akkor nagy vagányan már irjuk is a kódot:
1: public void LoadTweets(string username, string password)
2: {
3: HttpWebRequest request = (HttpWebRequest)WebRequest.Create(new Uri(homeUrl));
4: request.Method = "GET";
5: request.UseDefaultCredentials = false;
6: request.Credentials = new NetworkCredential(username,password);
7:
8: request.BeginGetResponse(new AsyncCallback(OnHomeCallback), request);
9: }
F5, futtat, meglepődik… Miért?
Mert egy óriási nagy NotImplementedException-t kapunk, miszerint a “Credentials property is not implemented”!!!!! Hát ez elég nagy szivás…. hogy lehetne akkor innen tovább menni? Hát másik ésszerű gondolat, hogy akkor az Authorization Header-t kézzel állitsuk be:
1: request.Headers[HttpRequestHeader.Authorization] = "Basic ......";
Újabb exception, miszerint az Authorization header nem settelheztő be. Agyviz 200 fok, vérnyomás 250, “akkor most állunk át WPF-re”, “menjen akkor egy proxy webszolgáltatáson keresztül”….. “ de miért NEEEEEMMMM????”, “hogy a manóba”, Na hát kb ezek hangzottak el (persze kicsit életszagúbban:D).
Beszélgettünk is erről Velvárt András (vbandi) kollegámmal, aki beizzitva Insideres kapcsolatait 7 másodperccel később közölte a választ. (Ami amúgy koránt sem triviális)
A megoldás a következő:
1: HttpWebRequest request = (HttpWebRequest)WebRequestCreator.ClientHttp.Create(new Uri(homeUrl));
2: request.Method = "GET";
3: request.UseDefaultCredentials = false;
4: request.Credentials = new NetworkCredential(username, password);
5:
6: request.BeginGetResponse(new AsyncCallback(OnHomeCallback), request);
Figyelem: WebRequestCreator.ClientHttp. Azaz nem a browser networking stackjét használjunk, hanem a silverlight saját client stack-jét!!! Egy apró dolog marad hátra: Out-of-browser módba küldeni az alkalmazást méghozzá elevated permission-ökkel!
Futtat, F5 és boldog, mert exception nélkül képes futni az alkalmazásunk! Azaz a 3 dolog ami kell a Twitter API közvetlen bizgerálásához Silverlight 4.0 alól:
- ClientHttp stack használata
- Out of Browser mód
- Elevated Permission-ök
Szóval minden visszatért a régi kerékvágásba, Dávid ismét átirhatja az API-ját meg a DataProvider-jét 🙂 A tanulmányi anyag, meg készülhet.
Szolgáltatásaink védelme WCF RIA Services-zel
Ha Silverlight-tal dolgozunk, bármit is csinálunk kliens oldalon, hogy “védjük” az alkalmazásunk, az adataink, pusztán illúzió. Ez is .NET, simán vissza lehet olvasni. A Refelector is megteszi, vagy egyéb szofisztikáltabb módzserek, akár hogy is trükközünk. A megoldás hogy nem kliens oldalon végezzünk a jogosultság kezelést, hanem a szerver oldalon! Szerencsére ez egy rendkivül egyszerű feladat!
Segitségünkre a RequiresAuthenticationAttribute, illetve a RequiresRoleAttribute szolgál! Mig az előbbi arról biztosit minket, hogy a dekorált tagot csak és kizárólag hitelesitett felhasználók hivhatják meg, addig az utóbbi attribútum azt ellenőrzi, hogy egy adott szerepkör tagjai vagyunk-e.
1: [EnableClientAccess()]
2: public class TestDomainService : LinqToEntitiesDomainService<TestDatabaseEntities>
3: {
4:
5: [RequiresAuthentication]
6: public IQueryable<Customers> GetCustomers()
7: {
8: return this.ObjectContext.Customers;
9: }
10:
11: [RequiresRole("Admin")]
12: public void InsertCustomers(Customers customers)
13: {
14: ...
15: }
Abban az esetben, ha minden műveletünket csak authentikált felhasználók hivhatják meg, az egész szolgáltatás objektumot elláthatjuk ezekkel az attributumokkal. Innentől kezdve ha valami nincs rendben, szorgosan kapjuk majd a SecurityException-öket!
1: [EnableClientAccess()]
2: [RequiresAuthentication]
3: public class TestDomainService : LinqToEntitiesDomainService<TestDatabaseEntities>
4: {
5: ....
6: }
Végül pedig elképzelhető, hogy egy szolgáltatás műveletet bár engedünk meghivni tetszőleges authentikált user számára, de szerepkör függően különböző képpen viselkedik a kódunk. Erre alkalmas a HttpContext.Current.User.IsInRole() metódus, ami segit kideriteni, hogy a hivó user-ünk hova tartozik.
1: [RequiresAuthentication]
2: public IQueryable<Customers> GetCustomers()
3: {
4: if (HttpContext.Current.User.IsInRole("Admin"))
5: {
6: return this.ObjectContext.Customers.Include("CustomerPrivateSomething");
7: }
8: else return this.ObjectContext.Customers;
9: }
Ahogy a művelt francia is mondja: Easy as Pie! 🙂
Árvai Zoltán Blogja 