Monthly Archives: October 2012

Microsoft Virtual Academy

Jópofa ez a Microsoft Virtual Academy oldal, érdemes megnézni: https://www.microsoftvirtualacademy.com

A Tracks oldalon lévő keresőben már lehet szűrni fejlesztői kurzusokra is, de egyelőre sajnos nincs rájuk találat. Reméljük hamarosan lesz. Addig elsősorban a Windows Server 2012 témákkal lehet ismerkedni, abból már van bőven.

Ha a jobb felső sarokban az országot átállítjuk Hungary-re, akkor a Top Students oldalon megjelennek a helyi ászok is Mosolygó arc

 

Technorati-címkék: ,

JavaScriptes Windows Store alkalmazások teljesítményelemzése

A Windows Áruházban közzétett alkalmazásoknak megfelelően gyorsnak kell lenniük, különben elutasíthatják őket az alábbi követelményre hivatkozva:

3.8 Az alkalmazásnak meg kell felelnie a teljesítményre vonatkozó alapvető követelményeknek a kis teljesítményű számítógépeken
Az alkalmazásnak legfeljebb 5 másodperc alatt el kell indulnia
Az alkalmazás felfüggesztése legfeljebb 2 másodpercet vehet igénybe

Mindennek a tesztelésére sajnos nem elég az Windows Application Certification Kit, az ugyanis a teljesítménnyel kapcsolatban csak minimális teszteket futtat. Szerencsére JavaScriptben írt alkalmazások esetén használhatjuk a Windows 8 SDK-ban található Performance Analyzer for HTML5 Apps segédprogramot. A Visual Studio telepítése után ez az alkalmazás nem lesz kivezetve a Start képernyőre, tehát kézzel kell elindítanunk a C:\Program Files\Windows Kits\8.0\bin\<platform>\AppPerfAnalyzer mappából a appperfanalyzer_js.exe-t. Ilyen gyönyörű (?) modern (?) a felülete (az eredeti élményért katt a képre a teljes méretért):

appperf-start

A Please select an app to analyze listából ki kell választanunk az alkalmazásunkat (de kiválaszthatjuk a Microsoft alkalmazásait is Mosolygó arc), ami után már rákattinthatunk a Let’s Get Started gombra. Az Advanced gombra kattintva kicsit testreszabhatjuk, hogy milyen teszteket akarunk futtatni:

appperf-advanced

Az indítás után egy 8 lépéses varázslón vezet végig az alkalmazás, ahol minden egyes lépésnél részletes útmutatót kapunk a teendőkről:

appperf-step

A megadott időket vegyük komolyan, különben nem lesz elég adatunk az elemzéshez. A végeredmény egy bőséges HTML formátumú jelentés számokkal és grafikonokkal, amit a C:\Users\<felhasználónév>\AppData\Local\Microsoft\HTML5AppAnalyzer\Traces mappában találunk.

A teszt az alábbi területeket érinti:

  • Activation time
  • UI responsivemess
  • Layout passes
  • Synchronous XMLHttpRequest on UI thread
  • Image scaling
  • Memory footprint
  • Runtimer broker memory reference set
  • Memory leaks
  • Idle state CPU usage
  • Successful suspend
  • Memory reduction when suspended
  • App memory growth
  • Runtime broker memory growth

Érdemes tehát kipróbálni, sokat tudhatunk meg az alkalmazásunk viselkedéséről. A JavaScriptes alkalmazások teljesítményével kapcsolatban itt találhatók további ajánlások angolul: http://msdn.microsoft.com/en-us/library/windows/apps/hh465194.aspx

Korhatár besorolás a Windows Áruházban

Van a A Windows 8 alkalmazások minősítési követelményei c. doksiban legalább két olyan rész, ami az alkalmazás által megjelenített tartalommal és az alkalmazáshoz tartozó életkor besorolással kapcsolatos, és amelyre hivatkozva már nem egy alkalmazást utasítottak el:

5.1 Az alkalmazás nem tartalmazhat felnőtt tartalmat, valamint a metaadatoknak mindenki számára megfelelőnek kell lenniük

Nem engedélyezettek az olyan alkalmazások, amelyek besorolása PEGI 16, ESRB MATURE feletti, illetve a hasonló besorolást kapnának. […]

6.2 Az alkalmazásnak rendelkeznie kell egy Windows korhatár-besorolással […]

[… ] Ha az alkalmazás ellenőrizetlenül biztosít lehetőséget a felhasználónak: (i) online közösségi oldalak elérésére, illetve (ii) személyes adatok harmadik féllel történő megosztására, beleértve a játékostársakat vagy online ismerősöket, akkor legalább 12+ besorolással kell ellátni a Windows Áruházban. […]

Másként megfogalmazva:

  • Semmilyen felnőtt tartalom nem lehet az alkalmazásban (a Windows Áruház ezt nem támogatja).
  • Ha az alkalmazás olyan online adatforráshoz kapcsolódik, ahol mások esetleg felnőtt tartalmakat tehetnek közzé, akkor legalább 12+ korhatárt kell megadni. Ha például az alkalmazásod egy Twitter kereső (ld. WallOfSilver), akkor máris 12+ besorolásúnak kell lennie, mert a Twitterre bárki bármit írhat. A közösségi tapasztalatok alapján úgy tűnik, hogy jobban járunk (több esélyünk van a sikeres minősítésre), ha inkább 16+ besorolást adunk meg.

Ha elég bátrak vagyunk, megpróbálkozhatunk a nem odaillő tartalom szűrésével is, amiben ezek segíthetnek:

Tudtok még hasonló forrást vagy szolgáltatást?

 

Technorati-címkék: ,

WinJS trükkök: üzenet ablakok egyedi gombokkal

A WinJS trükkök sorozat legutóbbi részében megtanultuk, hogyan készíthetünk egyszerű üzenet ablakokat, ha JavaScript nyelven készítünk Windows Store alkalmazásokat. A mai epizódban kicsit mélyebbre ásunk, több gombot teszünk az ablakra, testreszabjuk a felirataikat, beállítjuk a gyorsbillentyűket és természetesen egyedi eseménykezelőket is írunk hozzájuk.

Mint ahogy az üzenet ablakot sem “message box”-nak hívják Windows Store alkalmazások esetén, hanem “message dialog”-nak, a gomb se button, sőt még a gomb paramétereit is máshogy hívják az új platformon. Az alábbi videóból kiderül, hogyan:

(720p, teljes képernyős nézet ajánlott)

Ha tetszett és érdekel a folytatás, lájkold, vagy értékeld, hogy tudjam. Köszi!

 

Technorati-címkék: ,,,,

Biztonsági fejlesztések az ASP.NET 4.5-ben

Az ASP.NET számos funkcióját már kezdettől fogva a biztonsági szempontok szem előtt tartásával tervezték, – lásd például a ViewState védelmét – ez a kezdet azonban nem tegnap volt. A funkciók többsége utoljára a .NET 2.0-ban változott komolyabban és annak is már pár nap híján 7 éve, márpedig a biztonság alapjául szolgáló kriptográfia felett pedig ennyi év alatt könnyen eljárhat az idő. A másik probléma a kriptográfiával, hogy tudni kell helyesen használni, ami viszont nem mindig magától értetődő, és ez könnyen óriási hibákhoz vezethet (lásd MS10-070).

Ezen elvektől vezérelve az ASP.NET 4.5-ben jelentős változásokat vezettek be a biztonsági szolgáltatásokban, melyekről a .NET Web Development and Tools Blogon az elmúlt napokban Levi Broderick egy kiváló háromrészes sorozatot publikált Cryptographic Improvements in ASP.NET 4.5 címmel:

  1. Background regarding the use of cryptography in ASP.NET 4.
  2. Changes that were introduced in ASP.NET 4.5.
  3. Usage notes and miscellaneous Q&A.

Mindenkinek javaslom a teljes cikkek végigolvasását, nem zavaróan hosszúak, de azért röviden összefoglalom a lényeget:

  • Megnövelték a machine key entrópiáját, biztonságosabbá tették a használatát és újabb alkalmazás izolációs lehetőségeket vezettek be.
  • Szétválasztották a machine key felhasználási területeit (purpose), így ha az egyik helyen (például ScriptResource.axd) később hibát találnak, az nem veszélyeztet másik helyeket (például ViewState).
  • Új MachineKey.Protect és MachineKey.Unprotect függvények, ahol megadható a felhasználási terület, valamint egyszerre titkosít és MAC-kel. Egyúttal a korábbi Encode és Decode függvények deprecated-dé váltak.

Mindez persze nagyon mélyen érinti az ASP.NET számos területét, ami kompatibilitási problémákhoz vezethet. A problémák minimalizálása érdekében a fejlesztő csapat minden felhasználási területre egyedileg meghatározta, hogy alapértelmezés szerint a régivel kompatibilis, vagy az új rendszer szerint működik-e ASP.NET 4.5 esetén. Ezek gyönyörűen le vannak írva a sorozat 2. és a 3. részében az ide kapcsolódó web.config beállításokkal együtt, érdemes őket átnézni.

Ide kapcsolódó hír, hogy a Windows Azure Web Site-ok már ASP.NET 4.5-ön mennek, ami ugye in-place upgrade!

 

Technorati-címkék: ,

Minden fizetős appnak van próbaverziója a Windows Áruházban?

Íme Scott Dorman Flash Cards Sight Words alkalmazásához tartozó Windows Áruház oldal egy részlete, amelyet a  Windows 8-as Windows Áruház appból készítettem:

try-store

Tökéletesen látszik rajta, hogy az alkalmazás fizetős, de van próbaverziója is.

Nézzük ugyanezt az oldalt az Áruház webböngészőben megjelenő felületén:

try-web

Itt már csak az látszik, hogy az alkalmazás fizetős, az már nem, hogy van próbaverziója. Némi utánajárás után kiderült, hogy a webáruház azt feltételezi, hogy minden fizetős alkalmazásnak van próbaverziója, ezért csak annyit mutat, hogy az app fizetős vagy ingyenes.

Ha a metrós IE-ben nézi a felhasználó, akkor megjelenik számára egy gomb, amire ha rákattint, megtudhatja ezt is:

try-web-storelink

Csak ne lenne ott az a két “ha”.

Fejlesztőként egyelőre annyit tehetünk, hogy beleírjuk a próbaverzió létezését az app leírásába. De vajon meg fogják tanulni a felhasználók, hogy ott is kell keresni?

 

Technorati-címkék: ,

Alkalmazásfejlesztés Windows RT tableten

Most, hogy hivatalosan is megjelent a Windows 8 és elérhetővé váltak a Windows RT-t futtató tabletek, végre nem csak az emulátoron próbálhatjuk ki az alkalmazásainkat, hanem valódi hardveren is. Ilyenkor persze azonnal felmerül a kérdés, hogyan kell tableten fejleszteni?

A legelső, amit érdemes tudnunk, hogy a Visual Studio nem fut ARM-os eszközön, hanem csak x86/x64 platformon. Helyette a Remote Tools for Visual Studio 2012-t kell letöltenünk és elindítanunk az eszközön. Ne akadjunk fenn azon, hogy egyáltalán nem tűnik Metrós alkalmazásnak, fog működni.

Térjünk vissza a Visual Studiohoz és az alkalmazás indításakor válasszuk a Remote Machine opciót:

remote-machine

Innentől kezdve szinte elrontani sem lehet: varázsló, távoli gép megadása, tűzfal nyitása, fejlesztői licenc igénylése stb.

Hasonlóan egyszerűen működik a távoli tesztelés és a profilozás is, melyekről bővebben Jason Zander cikkében olvashatunk.

 

Technorati-címkék: ,,

Próbaverziós alkalmazások publikálása a Windows Áruházba

A Windows Áruházba kerülő alkalmazások egy részét a tesztelők az alábbi követelményre hivatkozva dobják vissza:

1.2 Your app must be fully functional when the customer gets it from the Windows Store

The Windows Store offers only fully functional apps to provide customers with the best experience. Anything that might cause our testers to think that your app is not completely finished will cause your app to fail certification.

You can help us by testing your app thoroughly before you submit it, and by providing us the information we need to test your app thoroughly. For example, if your app requires login credentials, provide us with a demo account. If your app requires access to a server, tell us what we need to do to verify that it’s working correctly.

A közösségi tapasztalatok alapján úgy tűnik, hogy olyan esetekben is célszerű teszt felhasználó nevet és jelszót megadni, amikor az ember azt gondolná, hogy tutira van a tesztelőknek is. Például ha az alkalmazás a Facebookhoz vagy a Twitterhez kapcsolódik, akkor készítsünk egy olyan fiókot, aminek az adatait megoszthatjuk a tesztelőkkel.

A kérdés még izgalmasabb olyan alkalmazások esetén, ahol a teljes funkcionalitás csak fizetés után érhető el. Tehát az ingyenes változat csak próba verzió, és a tesztelő is csak akkor lát mindent, ha átverekedte magát a fizetési folyamaton. Mi a teendő ilyenkor?

Ne örüljünk előre, nem fognak csak azért fizetni a tesztelők, hogy kipróbálhassák az alkalmazásunkat Mosolygó arc  Azok az alkalmazások, melyek az Áruház fizetési rendszerét használják, egyszerű helyzetben vannak: elég a tesztelésnél használt CurrentAppSimulator osztályt kicserélni a CurrentApp osztályra, és a tesztelők máris boldogulni fognak a fizetés kikerülésével. Ám ha az alkalmazásunk más fizetési rendszert használ, akkor meg kell adnunk azokat az adatokat, amik a fizetés teszteléséhez használhatók (pl. teszt hitelkártya adatok). Ezeknek az információknak a helye a publikációs varázsló Notes to testers fázisában az Instructions to testers rovatban van.

Sajnos szólnak hírek olyan alkalmazásokról, amelyek az Áruház fizetési rendszerét használják és mégis visszadobták arra hivatkozva, hogy nem sikerült a teljes funkcionalitást kipróbálni. Elméletileg ilyen nem lehetne…

A fórumokon többen javasolták már azt a megoldást, hogy építsünk kuponos fizetés kikerülést az alkalmazásunkba: azaz ha az alkalmazásban például a névjegy oldalon a felhasználó beír egy általunk megadott kódot, akkor nincs szüksége fizetésre, máris használhatja a teljes alkalmazást. A kódot (vagy annak egy időlimites változatát) megoszthatjuk a tesztelőkkel, sőt mi is használhatjuk az alkalmazásunk promótálására.

Van jobb ötletetek?

 

Technorati-címkék: ,

Az ASP.NET Medium trust halála

A .NET Framework egyik nagy újdonsága volt 11 évvel ezelőtt, hogy a code access security (CAS) segítségével kordában lehet tartani az alkalmazásokat: már nem csak az számít, hogy a futtató felhasználónak milyen jogosultságai vannak, hanem a CAS-nak köszönhetően az is megszabható, hogy egy adott kódnak milyen jogosultságai legyenek.

Bármennyire is ígéretesnek tűnt, sajnos a CAS soha nem terjedt el igazán, pedig szerver oldalon segíthetne megoldani az alkalmazások egymástól való elszigetelésének problémáját is. Egy 2005-ös Patterns & Practices ajánlás szerint például ASP.NET esetén a Medium trust jól használható alkalmazás izolációra.

Azóta sok idő telt el, az API-k és a rendszerek bonyolódtak, a CAS pedig nem fejlődött az 1.1 verzió óta. Nem is csoda, hogy Jeroen Frijtersnek sikerült találni benne egy olyan gyenge pontot, aminek az lett az eredménye, hogy a korábbi ajánlást átgondolták a Microsoftnál.

A KB2698981 tudásbázis cikk szerint most már az ASP.NET Medium Trust nem alkalmas arra, hogy alkalmazásokat szigeteljünk el egymástól egy gépen és egy processzen belül. Az új ajánlás felhagy az “egy processz” lehetőséggel, helyette azt ajánlja, hogy futtassuk az alkalmazásokat különálló application poolban, ami valójában különálló processzeket jelent. Ez jogos is, hiszen az app poolt pont erre találták ki még az IIS 6-ban.

Üzemeltetőknek és fejlesztőknek is mindenképp érdemes elolvasni a KB2698981-et, mert leírja:

  • Hogyan hozzunk létre önálló application poolokat az alklamazásoknak.
  • Hogyan állítsuk be az alkalmazást futtató felhasználói fiókot (process identity).
  • Hogyan állítsuk be a hozzáférés szabályozási listákat (DACL) a webhelyek mappáin.
  • Hogyan korlátozzuk, hogy a mappákon az IIS milyen műveleteket hajlandó végrehajtani.
  • Hogyan állítsuk be a Temporary ASP.NET Files mappa helyét és hozzáférés szabályozási listáit.
  • Hogyan távolítsuk el az érzékeny konfigurációs adatokat a gyökér konfigurációs fájlokból.

Érdemes komolyan venni az application poolokat és főleg az általam nagyon kedvelt ApplicationPoolIdentity-t, nyugodtabban alhatunk tőle.

 

Technorati-címkék: ,

Kell adatvédelmi nyilatkozat a Windows Áruházba

Aki a Windows Store-ba szeretné publikálni a Windows 8-ra készült alkalmazását, jobban teszi, ha ellátja korrekt adatvédelmi nyilatkozattal, az utóbbi időben ugyanis egyre több helyen lehet arról olvasni, hogy hiányzó, vagy nem megfelelő adatvédelmi nyilatkozatra hivatkozva utasították el egyik-másik alkalmazást.

Konkrétan erre szoktak hivatkozni:

4.1.1 Your app must have a privacy statement if it collects personal information

Miért kell adatvédelmi nyilatkozat?

Kérdés, hogy a publikálás során a tesztelők honnan tudják, hogy az alkalmazás ilyen adatokkal dolgozik? Hát persze, hogy az alkalmazáshoz tartozó manifest fájlból! Gyakorlatilag ha bármi be van pipálva a Capabilities oldalon, az már olyan, mintha az alkalmazás valóban hozzá is férne ezekhez a személyes adatokhoz (akkor is, ha valójában nem is teszi, de megtehetné). És itt jön a buktató: a Visual Studio 2012 által generált projekt sablonokban alapból be van pipálva az Internet (Client) képesség:

default-capabilities

Ez egészen jogos, hiszen a legtöbb alkalmazás ma már valóban kapcsolódni szeretne a nethez, csakhogy ilyenkor a felhasználó IP címe eljut a szerverhez, ami viszont már egyértelműen személyes adatnak számít. Ha tehát az alkalmazásunk nem internetezik, ezt mindenképp kapcsoljuk ki, megspórolhatunk egy-két felesleges kört magunknak. Viszont ha az app semmi mást nem csinál, csak letölt a netről, máris elkerülhetetlen, hogy megírjuk a nyilatkozatot.

Személyes adatnak számít:

  • IP cím
  • Kamera képek
  • Hang és képfelvételek
  • Név, cím, születési dátum és egyéb személyhez köthető adatok (PII)
  • Fényképek
  • Kapcsolatok
  • Dokumentumok

Milyen egy jó adatvédelmi nyilatkozat?

Általánosságban:

  • Tájékoztatja a felhasználót arról, hogy milyen adatokkal dolgozik az alkalmazás.
  • Tájékoztatja a felhasználót arról, hogy mi történik az adatokkal.
  • Leírja, hogy a felhasználó hogyan szabályozhatja az adatok felhasználását és megosztását.
  • Leírja, hogy a felhasználó hogyan tekintheti meg a vele kapcsolatos adatokat.
  • Megfelel a törvényi előírásoknak.

Az ajánlás az, hogy ha az alkalmazás nem dolgozik személyes adatokkal, akkor ez a tény szerepeljen az adatvédelmi nyilatkozatban. Tehát úgy tűnik, hogy így is, úgy is szükség van rá.

Ha az alkalmazásunk külső szolgáltatáshoz kapcsolódik, ne felejtsük el belinkelni annak a szolgáltatásnak az adatvédelmi nyilatkozatát.

Minták, források

Ezen túlmenően a Microsoft további útmutatást, mintákat nem ad, mindenkinek magának kell megszülnie az adatvédelmi nyilatkozatot. Hát nem az a kimondott programozói feladat, lássunk tehát néhány mintát.

A jó hír az, hogy a neten számos nyilatkozat generátor található, amelyek persze angolul vannak, tehát fordítgathatunk a végén. Azt tapasztaltam, hogy ezeknek egy része sajnos regisztrálós, azaz végigcsináltatnak velünk egy igen hosszú varázslót, majd a végén közlik, hogy regisztráljunk, ha látni szeretnénk a generált adatvédelmi nyilatkozatot.

A teljesen ingyenesek közül nekem legjobban az Association for Competitive Technology (ACT) által ajánlott Privacy Choice Policy Maker jött be. Itt első lépésben 6 kérdésre válaszolva generálhatunk egy ilyen badge-et:

policy-kids-badge

Ez a Windows Áruház szempontjából haszontalan, de a logó kezdeményezés nekem tetszik. Innen az I need a privacy policy linkre kattintva jutunk a 12 lépéses varázslóra, ahol bőven kapunk opciókat, magyarázatot és még szerkeszthetjük is a szöveget.

Amennyiben igen rövid nyilatkozatra van szükségünk, példaként használhatjuk Robert MacLean verzióját:

This application does not collect or transmit any user’s personal information, with the exception of technical information included in HTTP requests (such as your IP address). No personal information is used, stored, secured or disclosed by services this application works with. If you would like to report any violations of this policy, please contact us using the contact form.

Robert kicsit kibővített változata itt található meg: http://www.sadev.co.za/app-privacy

Jómagam egy olyan alkalmazást készítettem, ami a Bing Maps térképszolgáltatáshoz kapcsolódik és ezt a nyilatkozatot elfogadták:

Személyes adatok
Ez az alkalmazás nem gyűjt és nem továbbít semmilyen személyes adatot a hálózaton keresztül.
               
Harmadik fél
Ez az alkalmazás az interneten keresztül a Microsoft által üzemeltetett Bing Maps térképszolgáltatáshoz kapcsolódik, így annak a szolgáltatásnak az üzemeltetőihez eljut az Ön számítógépének IP címe, valamint a térképen megjelenített információk.
A térképszolgáltatás adatkezelésével kapcsolatban a
Bing adatvédelmi nyilatkozatban tudhat meg többet.

További információk
Amennyiben további információkat szeretne kapni vagy észrevétele van az alkalmazás adatkezelésével kapcsolatban, írjon nekünk!

Hol jelenjen meg

A következő kérdés, hogy hol kell megjelenítenünk az adatvédelmi nyilatkozatot? Az alkalmazás publikálásakor a Description lépésben az űrlapon találunk egy Privacy policy mezőt:

appreg-policy

Ugyan az áll mellette, hogy akár 2048 karaktert is beírhatunk, a súgó ikon felett megjelenő tooltipből azonban egyértelmű, hogy ide URL-t kell beírnunk. Igen, bármilyen nonszensznek is tűnik, kell az alkalmazásnak egy webcím. Van rá példa, hogy akár egy SkyDrive-ra feltöltött Word doksira mutató URL-t is elfogadtak… Az űrlap megengedi, hogy anélkül küldjük be az alkalmazást, hogy ezt a mezőt kitöltenénk, de később vissza fogják dobni, tehát inkább töltsük ki.

Az alkalmazáson belül az ideális hely a beállítások panel (Settings charm):

policy-settings-charm

Persze azt is megtehetjük, hogy ide linket teszünk, ami a webes változatra mutat.

Végül pedig a tapasztalatok alapján nem árt, ha az alkalmazás publikálásakor a Notes to testers lépésben az Instructions for testers rovatba beírjuk, hogy itt kell keresni.

 

Ezek az eddig tapasztalatok és gyűjtött információk. Ha van adatvédelmi nyilatkozatos ötletetek vagy élményetek, osszátok meg, hogy tanulhassunk belőle és zökkenőmentesebb legyen az alkalmazások publikálása.

 

Technorati-címkék: ,,