HTML5 címkéhez tartozó bejegyzések

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

Reklámok

HTML5 MIME típusok IIS 8-on

Ha IIS 7/7.5 alatt olyan alkalmazást futtattunk, amely intenzíven használt HTML5-közeli fájl típusokat, akkor bizony a hozzájuk tartozó kiterjesztéseket fel kellett vennünk az IIS MIME Types listájába, különben a webkiszolgáló nem volt hajlandó kiszolgálni az ilyen fájlokra érkező kéréseket. Például így:

<staticContent>
  <mimeMap fileExtension=".mp4" mimeType="video/mp4" />
  <mimeMap fileExtension=".m4v" mimeType="video/m4v" />
  <mimeMap fileExtension=".ogg" mimeType="video/ogg" />
  <mimeMap fileExtension=".ogv" mimeType="video/ogg" />
  <mimeMap fileExtension=".webm" mimeType="video/webm" />
  <mimeMap fileExtension=".oga" mimeType="audio/ogg" />
  <mimeMap fileExtension=".spx" mimeType="audio/ogg" />
  <mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
  <mimeMap fileExtension=".svgz" mimeType="image/svg+xml" />
  <remove fileExtension=".eot" />
  <mimeMap fileExtension=".eot" mimeType="application/vnd.ms-fontobject" />
  <mimeMap fileExtension=".otf" mimeType="font/otf" />
  <mimeMap fileExtension=".woff" mimeType="font/x-woff" />
</staticContent>

Ez szép és jó, de sajnos amikor frissítjük a szervert IIS 8-ra, akkor az IIS egy gyönyörű 500.19 Internal Server Error hibával fog megörvendeztetni minket.

iis8-duplicate-mime-type

Ha bekapcsoljuk a részletes hibaüzenet megjelenítését, akkor láthatjuk, hogy a hiba:

Cannot add duplicate collection entry of type ‘mimeMap’ with unique key attribute ‘fileExtension’ set to ‘.4v’

Mindez annak köszönhető, hogy az IIS 8 már több MIME típust ismer, ráadásul ezek szerver szinten vannak beállítva, így minden website örökli őket.

A megoldás természetesen az, hogy a saját web.configunkból töröljük a problémás sorokat. Nálam ezek váltak feleslegessé:

mp4, m4v, m4a, ogv, oga, ogg, webm, spx, svg, svgz, otf, woff

Ne felejtsétek el frissíteni a telepítőket!

 

Technorati-címkék: ,,

HTML5 mobil böngészőkön

A HTML5 kapcsán számomra az egyik legzavaróbb dolog, hogy nem egyetlen szabványról van szó, hanem több tucat, egymástól többé-kevésbé függetlenül fejlődő szabványról. Természetesen nem csak a szabványok fejlődnek önállóan, hanem a böngészők is, amit kicsit nehéz is követni. Én a html5test.com oldalon szoktam megnézni, hogy éppen mit tudnak az egyes böngészők.

Az asztali böngészőknél most éppen ez a helyzet:

html5test-desktop

És természetesen ugyanilyen verseny van a mobil világban is:

html5test-mobile

Ami nem látszik az ábrákon, az az egyes szabványok aktuális fejlettségi szintje. Vannak egészen késznek mondható és vannak még teljesen éretlen szabványok.

A W3C közzétette a Standards for Web Applications on Mobile: current state and roadmap című jelentésének májusi kiadását, amiből jól látszik, milyen sokféle technológia kapcsolódik ide, azoknak a szabványosítása milyen fázisban jár, és hogy az egyes böngészők mennyire támogatják. Még arra is van némi utalás, hogy mi várható a jövőben. Aki mobilra fejleszt, annak jó referencia lehet, amikor dönteni kell, hogy valamit merjünk-e már használni vagy még ne.

w3c-mobile-appstate

 

 

Technorati-címkék: ,,

Kimaradhat a XAML a Windows 8-ból

ms-days-logoAkik esetleg követnek Facebookon vagy Twitteren már tudhatják, hogy múlt héten Dávid Zoli barátommal Szófiában voltunk.

A bolgár Microsoft múlt héten rendezte meg az MS Days 2012 konferenciát, ami egy meglehetősen komoly rendezvény fejlesztők és üzemeltetők számára. Csak hogy a méreteket érezni lehessen: két nap, 8 párhuzamos szekció, 72 előadás (melynek kb. a fele angolul), 49 előadó (akik közül sokat külföldről reptettek oda) és minderre több, mint 1000 résztvevő.

A szervezés nagyon profi volt, minden egészen flottul ment, talán csak a helyi Lurdy Ház, a Кино Арена volt egy kicsit szűkös ennyi embernek:

Кино Арена

Zolival két előadást tartottunk JavaScriptről, HTML5-ről, MVC-ről és Azure-ról, főként tapasztalatokról és legjobb gyakorlatokról. Akit érdekel, letöltheti az előadásokhoz tartozó prezentációkat és demókat innen. Büszkén jelenthetem, hogy mindkét előadás nagyon népszerű volt, sokkal többen jöttek, mint ahányan a terembe befértek, még a “falakon is lógtak”. Az értékelőlapok összesítését még nem kaptuk meg, de a Twitteren már jött néhány pozitív visszajelzés (kettőnk közül csak én vagyok Twitteren, ezért csak engem emlegetnek, de az előadásokat együtt tartottuk):

ms-bg-twitter1

ms-bg-twitter2

A második előadás után megkeresett minket a Microsoft Research két munkatársa és elmondták, hogy az egyik kiemelt projektjükben kompatibilitási problémák megoldásán dolgoznak és az előadások alapján arra gondoltak, hogy szívesen bevonnának minket is. Konkrétan azon elmélkednek, hogy a XAML egy gigantikus zsákutca, mert már sok “dialektus” van belőle (Silverlight, WPF, Windows Phone, Windows 8) és mindegyik jelentősen eltér a másiktól.

Erről egyébként bárki meggyőződhet: a CODE Magazin atyja, Markus Egger egy nagyon hasznos eszközt tett közzé a CodePlexen XAML Dialect Comparer Tool néven. Az eszköz annyit tud, hogy megadunk neki egy forrás és egy cél XAML változatot, ő pedig végigszántja a névtereket és megmondja, mennyire kompatibilisek egymással. Például ha Silverlight 5-ről Windows 8 Metro-ra akarunk átállni, akkor csak 55,19%-os kompatibilitással számolhatunk. Mindenki eldöntheti, hogy a saját esetében ez mire elég.

XamlComparer

Vissza Bulgáriához. Szóval az MSR-nél két projekten dolgoznak és mivel egy szóval sem mondták, hogy ne beszéljünk róla, elmesélem. Az egyik projekt célja, hogy XAML markupot HTML-re fordítsanak, a másiké pedig, hogy a HTML+JavaScript alkalmazásoknak 100%-osan kompatibilis környezetet biztosítsanak minden platformon. Komolyan elkezdtek azon gondolkodni, hogy a Windows 8 Metro stílusú alkalmazásoknál kínált JavaScript lehetőségek pontosan ugyanabba az irányba viszik a HTML+JS párost, mint a XAML-t: dialektikus zsákutcába. Márpedig ezt a hibát az MS nem akarja még egyszer elkövetni, így nem csoda, hogy Steven Sinofsky-t is komolyan érdeklik ezek a kutatások.

Íme egy példa! Windows 8 Metro stílusú alkalmazásban használhatunk WinJS.UI.ListView vezérlőt, így:

<div id="playeritemtemplate" data-win-control="WinJS.Binding.Template">
    <div data-win-bind="innerText:Name" style="height: 20px;" />
    <img data-win-bind="src:Photo" style="width: 200px; height: 150px;" />
</div>

<div id="PlayerListView" 
    style="height: 185px;" 
    data-win-control="WinJS.UI.ListView"     
    data-win-options="{itemRenderer:playeritemtemplate,
                       layout:{type:WinJS.UI.GridLayout,maxRows:1}}" />

Ez működik kiválóan Windows 8 esetén, de sehol máshol. Arról nem beszélve, hogy a kód elég nehezen olvasható, hiszen a WinJS.UI.ListView vezérlő hozza azt a produktivitást, ami miatt az egészet csináljuk, de fogalmunk sincs, hogy az hogyan működik. Íme egy másik példa, ezúttal egy datepicker:

<div data-win-control="WinJS.UI.DatePicker" 
     data-win-options={maxYear:2020,minYear:2000}" />

Ez is csak Windows 8-on fog bármit is produkálni, miközben dátumválasztásra mindenhol szükség van. Persze vannak tökéletes megoldások: az adatkötés megoldható például KnockoutJS-sel, a dátumválasztás pedig jQueryUI DatePickerrel. Ezek tisztán JavaScript alapú megoldások (beszéltünk is róluk az előadásunkban), tehát nincs platform probléma, feltéve persze, hogy a JavaScript futtatás nem okoz gondot az adott környezetben. Weben mindez természetes, tehát ahol webböngészőt tudunk beágyazni, ott a probléma megoldva. Nézzük sorban:

Silverlight: átfordítjuk a XAML-t HTML-re, a code behindot pedig JavaScriptre és ha a hoszt egy böngésző, akkor máris készen vagyunk. A C#-JavaScript konverzióra Nikhil Kothari Script# projektje szolgáltat megoldást. Ha out-of-browser SL alkalmazásról van szó, akkor sincs nagy gond, hiszen akkor a hoszt az explorer.exe, ami szintén beépítetten támogatja a HTML-t és a JavaScriptet (mindenki emlékszik még a böngésző beépítése körüli jogi hercehurcára). Ez egyben a SL jövője körüli kérdést is megoldja.

WPF: csakúgy mint SL-nél, itt is átfordítjuk a XAML-t HTML-re, a code behindot pedig JS-re, és mivel a hoszt itt is az explorer.exe, futni is fog vidáman. Itt már gyakrabban jöhet elő egy olyan nehézség, ami SL5-nél is, konkrétan a P/Invoke, ez ugyanis kimutat a .NET runtime adta környezetből. Erre még nincs teljeskörű megoldás, egyelőre ott tartunk, hogy aki P/Invoke-ra épít, annak valószínűleg kevésbé fontos a hordozhatóság, de ez még nem kielégítő válasz.

Windows Phone: biztos hallottátok már azt a pletykát, hogy a Windows Phone 8-nál cserélni fogják a kernelt, ami már a Windows 8-ra fog épülni. Ezt egyelőre sem megerősíteni, sem cáfolni nem tudom (ugye értitek Kacsintó arc), a mi szempontunkból csak az a lényeg, hogy ez lesz a legkevésbé fájdalommentes. Ami a Windows Phone 7-et illeti, ott szóba se jöhet egy kernel szintű módosítás, ezért valószínűleg egy runtime réteg fog bekerülni valamelyik frissítésbe, ami gyakorlatilag egy transzparens böngésző lesz a HTML alapú alkalmazások futtatására.

Windows 8: ez a legrizikósabb terület, ugyanis pont itt reklámozta az MS legjobban az új HTML lehetőségeket és most ebből kellene visszalépni a helyes útra, ami persze egy marketing öngyilkosság lenne. Bár erre bármikor lehet azt mondani, hogy eddig csak “preview” változatok láttak napvilágot, ami magában hordozta a változtatás lehetőségeit, és hogy csak az a fontos, hogy a végeredmény hosszú távon jó legyen. A Microsoft Research-ös srácokkal arról beszélgettünk, hogy Sinofsky képes lenne szembemenni a cégen belüli marketing gépezettel a profi végeredmény érdekében.

Felmerülhet persze még kérdésként a sokféle “form factor”, azaz a cél eszközök különböző mérete. Hogyan fognak megjelenni az alkalmazásaink egy kicsi telefonon vagy egy nagyobb monitor képernyőjén? Ezzel kapcsolatban szerencsére pont a Windows 8 miatt már kitalálták a megoldást, érdemes elolvasni Nacsa Sándor idevágó Standards-based adaptive layouts in Windows 8 (and IE10) című írását.

layout

Szintén érdekes problémakör az adattárolás kérdése. Itt az a szerencse, hogy a sok XAML környezet közül már a legkisebb is hozza a közös nevezőt: a Mango óta Windows Phone-on is lehet SQL Compact Editiont használni. Ha pedig külső SQL Serverre van szükség, akkor pedig maradnak a HTTP alapú REST-es API-k az adatbázis elérésére.

Mindezek a projektek gyönyörűen haladnak az MSR-nél, vannak működő megoldásaik nem csak egyszerű, hanem összetettebb alkalmazásokra is. Az igazi probléma az időzítés. Az MSR nem elég nagy ahhoz, hogy az igazi bevételt termelő Windows gépezetet visszatartsa, márpedig ha a Windows 8 megjelenik a Consumer Preview-ban található XAML és a HTML lehetőségekkel, akkor már nincs visszaút, az MS végérvényesen belezöttyen a kátyúba, ahonnan évekig nem mászhat ki (lásd VB6 és ASP támogatás Windows 8-on).

Ennek a meccsnek két eredménye lehet:

1. Marad a mostani felállás, amivel útjára indítják a Windows 8-at mint egy gigantikus kísérletet, és az esetleges problémákat, zsákutcákat majd a Windows 9-ben kijavítják. Ebben az esetben a történelem a Vista-Windows 7 párost ismételné.

2. Sinofsky a sarkára áll és azt mondja, hogy tiszta szerencse, hogy időben észbe kaptunk, szorítsuk egy kicsit háttérbe a saját érdekeinket és adjunk ki egy olyan Windows 8 verziót, ami tényleg hosszú távon jó irányba mutat, hiszen operációs rendszert nem cserélnek sűrűn sem a végfelhasználók, sem a cégek.

Sinofsky már letett valamit az asztalra, és én arra tippelek, hogy elfogadnák az érvelését, bár ez nagy érvágás lenne a Microsoftnak. Ebben az esetben ugyanis jelentősen csúszna a Windows 8 kiadása (az idén biztosan nem lenne belőle semmi), hozzá kellene igazítani az eddig elkészült alkalmazásokat, fejlesztőeszközöket, mindent. Viszont arra is nagyon jó esély van, hogy a végeredmény nagyon jó termék lenne, amivel az MS tiszteletet érdemelhetne ki, ami persze végül a bevételi oldalon is éreztetné a hatását. Így nem meglepő, hogy jelenleg ez a valószínűbb lehetőség.

De mi lesz a fejlesztőkkel ebben az esetben? A XAML halála a WPF és a Silverlight bizonytalan jövője körüli homályos információk óta egyre valószínűbb. A XAML diverzitása a saját halálát okozza, miközben lényegében semmi előnyt nem hordoz a HTML-hez képest, hiszen csak címke parszolásról van szó. Elég csak az ASP.NET MVC 4-ben lévő Razor parserre gondolni és máris tisztán látszik, hogy a HTML alapú megoldások egyszerűen jobbak. (Egyébként a Razor parser is bekerült ebbe a projektbe) Nincs értelme fenntartani egy olyan szintaktikát, ami megosztja a fejlesztői tábort, miközben van egy olyan alternatíva, ami inkább újabb fejlesztőket hozna a Windows platformra.

Ti örülnétek, ha a XAML halála miatt csúszna a Windows 8 kiadása?

 

 

UPDATE: Fontos kiegészítés a fentiekhez: http://bit.ly/xamltohtml

 

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

Adobe: Nincs több Flash Player, irány a HTML5!

Danny Winokur, az Adobe alelnöke nemrég bejelentette, hogy felhagynak a Flash Player fejlesztésével mobil eszközökre:

“Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores.  We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.)”

És a magyarázat:

“HTML5 is now universally supported on major mobile devices, in some cases exclusively.  This makes HTML5 the best solution for creating and deploying content in the browser across mobile platforms. We are excited about this, and will continue our work with key players in the HTML community, including Google, Apple, Microsoft and RIM, to drive HTML5 innovation they can use to advance their mobile browsers.”

Persze desktopon a helyzet változatlan, készül a Flash Player 12 és mindenki “super excited”.

Szerintetek ez mit jelent?

 

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

HTML5 média formátumok böngésző támogatása

Az idei Web Konferencián Dávid Zoli barátom tartott egy remek előadást a HTML5 játékfejlesztésről JavaScript reneszánsz címmel, amelynek a felvétele egyébként megtekinthető a devPortal TV oldalán.

Az előadás utáni kérdések között merült fel, hogy tényleg nincs egy olyan audio formátum, amit minden böngésző támogatna? A HTML5 támogatja az AAC, MP3 és Ogg Vorbis audio formátumokat, illetve az Ogg Theora, WebM és MPEG-4 video formátumokat, de hogy állnak ezzel a böngészők?

A novemberi MSDN magazin egyik cikke pont ezzel a kérdéssel foglalkozik és egy az aktuális állapotot bemutató táblázat is szerepel benne:

Videó formátum Audió formátum
Böngésző

Ogg Theora

H.264

VP8 (WebM)

Ogg Vorbis

MP3

WAV

IE Telepíthető 9.0 Telepíthető +
Firefox 3.5 4.0 + +
Chrome 3.0 6.0 + + +
Safari Telepíthető 3 Telepíthető + +
Opera 10.50 10.60 + +

 

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

HTML 5 custom data attributes

A HTML 5 szabványba foglalt egyik legkedvesebb részem a custom data attribute lehetősége. Egyrészt azért tetszik, mert nagyon régóta fájó problémát old meg, másrészt mert nem kell megvárni hozzá a HTML 5 szabvány elkészültét, már ma is használható, a korábbi böngészők is elviselik.

Röviden a custom data attributes arra jó, hogy tetszőleges, nem látható információt ágyazzunk be kulturált módon a HTML markupba. Ehhez nem kell más tennünk, mint egy data- kezdetű attribútumot biggyesztenünk a kiszemelt HTML elemhez. Például így:

  <span data-rendezo="Michael Bay">Transformers</span>

Ha erre az adatra később szükségünk van JavaScriptben, akkor akár az element.dataset tulajdonságon keresztül, akár jQuery-vel a data() metóduson keresztül elérhetjük:

  alert( $('span').data('rendezo') );    // --> Michael Bay

Persze a jQuery támogatja az értékek írását, törlését és hozzáadását is. Sőt, akár összetett objektumokat is tehetünk ide, természetesen JSON formában (a tulajdonságok neveit idézőjelbe kell tenni):

  <span id="tr"
    data-film='{ "rendezo": "Michael Bay", "ev": 2007, "moziban": true }'>
    Transformers
  </span>

Kiolvasni nagyon egyszerű:

  var f = $("#tr").data('film');

És ahogy Firebugban is látszik, egy összetett objektumot kapunk vissza, méghozzá nem csak stringekkel, hanem ha lehet, típusokkal (Boolean, Number):

dataAttribute-Firebug

Sokkal jobb, mint JavaScriptbe írni a szerver oldalon előálló adatokat vagy hidden fieldeket generálni, nem?

Ez az a pont, ahol az ember úgy érzi, hogy ennél egyszerűbb és jobb dolog nincs a világon. Csakhogy a specifikáció nagyon pontosan definiálja, hogy hogyan kell kezelni a nagybetűs és a kötőjeles attribútumokat, ami nagyon érdekes hibákat tud eredményezni. Vegyük például ezt:

  <p data-productId="22">...</p>

Talán meglepő, de ez bizony undefined a javából:

  alert( $("p").data("productId") );

Helyesen:

  alert( $("p").data("productid") );

Ez nem bug, főként nem a szerver oldali keretrendszer hibája, hanem feature: úgy működik, ahogy a specifikáció előírja.

A jQuery próbál segíteni a programozói bénaságokon és gyakran többféleképpen is elérhetővé teszi ugyanazt az adatot. Például íme a markup:

  <p data-Id="22">...</p>

Ebből az Id két módon is elérhető:

  $("p").data("id")
  $("p").data("Id")

A Studio is tudja, mi a helyes, mert a Format Document vagy Format Selection parancs kiadásakor kisbetűsre alakítja ezeket az attribútumokat.

Mindenképp érdemes elolvasni azt a pár mondatot a specifikációban, ami erről szól (3.2.3.8 fejezet) és csak akkor használni ezt a lehetőséget, ha értjük is.

Keresztkérdés! Íme a markup:

  <p data-egy="1" 
     data-Ketto="2" 
     data-haromHarom="3" 
     data-Negy-negy="4" 
     data-ot-ot="5" 
     data-hat-Hat="6">...</p>

Milyen tulajdonságai lesznek az alábbi sor után az adat objektumnak?

  var adat = $("p").data();

Íme a megoldás (a szürke kosz egy mini kép, kattints rá a teljes mérethez): Kattints ide a megoldás megtekintéséhez!

 

Technorati-címkék: ,,