Az első Windows 8 alkalmazásom

A múlt héten körutaztam a Visual Studio 11-ben, telepítettem a Team Foundation Server 11-et, és elindítottam egy alapvető Windows 8 Metro / WinRT alkalmazást egy sablonból. Ma az alkalmazásban szereplő minta adatforrásokat kicserélem a Microsoft Research OData forráshoz való kapcsolatokra.

A múlt hét egyik mulasztása az volt, hogy nem jelenítettem meg a Visual Studio 2011 teljes képernyős nézetét. Mint láthatja, az észrevételekben kifejezett néhány aggodalom, amely szerint a felhasználói felület "lapos" és nehéz megkülönböztetni a dolgokat, megalapozott. Ez számos ismert webhely és író közös panasza, és remélhetőleg a Microsoft úgy dönt, hogy ide helyezi az űrlap funkciót, különösen mivel a Visual Studio 11 nem Metro alkalmazás, és nem kell megosztania a Metro megjelenését. A ábra

A Visual Studio 11 úgy néz ki, mint egy holdképe, mindegyik szürke, kráterszerű ikonokkal. (Kattintson a képre a nagyításhoz.)

Miután a sablon segítségével létrehoztam az alkalmazás alapvető belekét, itt az ideje, hogy adatokat gyűjtsön a Microsoft Research-ből. Megpróbáltam követni Samidip Basu oktatóprogramját erre a célra, de nem pontos, mivel olyan osztályokat hoz létre, amelyek a System.Data-tól függnek, amely a WinRT-n belül nem érhető el. A Visual Studio 11 Szolgáltatási referencia varázslója sem proxy osztályokat hoz létre az OData számára.

Végezzük el ezt egyenesen: a Microsoft egy csomó munkát helyez az Azure Data Marketbe (OData használatával), az OData használatával megkapja az embereket a LightSwitch és az Entity Framework használatából stb., Mindenféle más OData-technológiát kiszorít, majd nem szállít illetékes OData támogatás a Visual Studio 11-ben Metro / WinRT alkalmazásokhoz? Gyere a Microsoft, hogyan számíthat arra, hogy komolyan vesszük az OData-t, ha nem? A "nem támogatott" -ról szólva a WinRT jelenleg nem rendelkezik beépített HtmlDecode funkcióval.

Tehát itt az ideje, hogy megpróbálja a hátsó ajtó útvonalat, kézzel csinálva. Elviszem a SampleDataSource.cs fájlt, és átnevezem azt és az osztályokat megfelelőbb nevekre (a "Minta" helyébe a "MicrosoftResearch" lép.) Ezután felveszem a MicrosoftResearchDataItem osztályt, és hozzáadom egy Uri tulajdonságot az URI tárolásához az aktuális elemhez. Az összes órám alapfokon készül fel.

A MicrosoftResearchDataSource (nee SampleDataSource) osztály keményen kódolt adatokkal rendelkezik. Egyetlen adatelemet használ, amelyet néhányszor hozzáad minden csoporthoz. Elég könnyű dinamikusan elvonni a csoportinformációkat. Az OData szolgáltatás végpontja a http://odata.research.microsoft.com/odata.svc, és amikor ezt felhívja, megkapja az elérhető csoportok listáját. WebClient hívást használok az adatok letöltésére. Ne feledje, hogy a WinRT-vel (hasonlóan a Windows Phone 7-hez) minden potenciálisan hosszan futó műveletet aszinkron módon kell elvégezni. Már írtam ezt a kódot a Airport Status Checker WP7 alkalmazásban, de elég különbségek vannak a WP7 osztályai és a WinRT között, hogy nem történik közvetlen fordítás. Például a WP7 rendelkezik a "WebClient" objektummal, amely aszinkron módon kérést készít, és akár bájt tömböt, akár karakterláncot ad vissza, és eseménykezelőt indít, amikor megtörténik. A WinRT rendelkezik a "HttpClient" -nel, amely az új "async" rendszert használja a kérelem benyújtásához, tehát a "várni" gombbal hallgathatja meg az eredményeket. Ez szintén szükségessé teszi a szerkezet kicsit megváltoztatását az aszink / elvárások követelményei miatt.

A kód írása az adatok felhasználásához szörnyű élmény. Fent fentről lefelé ez a fajta dolog, amelyet a számítógépek automatikusan kezelésére találtak. Ehelyett a megfelelő proxy osztály-készítő hiánya azt jelenti, hogy mindent kézzel kell írnom és hibakeresni, megtudva, hogy mely mezők választhatóak és kötelezőek, általánosak és melyek, és ennek kódolása. Őszintén szólva, ezt a munkát kézzel végezni abszolút brutális, nyomorúságos és értelmetlen, és egy-két órát telt el, hogy észrevegyem, hogy kézzel kell írni, és hogy a képernyőn adatok legyenek. Íme a kód, amit írtam:

 nyilvános zárt osztályú MicrosoftResearchDataSource 

{

private ObservableCollection _itemGroups = új ObservableCollection ();

nyilvános megfigyelhető gyűjtő elemcsoportok

{

get {return this._itemGroups; }

}
 private async érvénytelen GetGroups () 

{

{

var letöltő = új HttpClient ();

downloader.MaxResponseContentBufferSize = int.MaxValue;

var groupXml = várja meg a letöltőt. GetStringAsync ("http://odata.research.microsoft.com/odata.svc/");

var groupData = XDocument.Parse (groupXml);

var workspaceName = XName.Get ("munkaterület", "http://www.w3.org/2007/app");

var titleName = XName.Get ("cím", "http://www.w3.org/2005/Atom");

var collectionName = XName.Get ("gyűjtemény", "http://www.w3.org/2007/app");

var entryName = XName.Get ("entry", "http://www.w3.org/2005/Atom");

var contentName = XName.Get ("tartalom", "http://www.w3.org/2005/Atom");

var propertiesName = XName.Get ("tulajdonságok", "http://schemas.microsoft.com/ado/2007/08/dataservices/metadata");

var idName = XName.Get ("id", "http://www.w3.org/2005/Atom");

var summaryName = XName.Get ("összefoglaló", "http://www.w3.org/2005/Atom");

var nameName = XName.Get ("Név", "http://schemas.microsoft.com/ado/2007/08/dataservices");

var descriptionName = XName.Get ("Leírás", "http://schemas.microsoft.com/ado/2007/08/dataservices");

var urlName = XName.Get ("Url", "http://schemas.microsoft.com/ado/2007/08/dataservices");

XElement ÖsszefoglalásElement;

XElement nameElement;

XElement descriptionElement;

XElement urlElement;
 foreach (var gyűjtemény a groupData.Root.Element (munkaterületnév) .Elements ()) 

{

próbáld ki

{

if (collection.Name == collectionName)

{

var groupName = collection.Element (titleName) .Value;

var group = új MicrosoftResearchDataGroup (groupName, groupName, "", "", "");
 var itemsXmlStream = várja meg a letöltőt.GetStreamAsync ("http://odata.research.microsoft.com/odata.svc/" + collection.Attribute ("href"). Érték); var itemData = XDocument.Load (itemsXmlStream); 
 foreach (var cikk az itemData.Root.Elements () tételben) { 
 if (item.Name == entryName) 

{

var tulajdonságok = elem.Element (contentName) .Element (propertiesName);

próbáld ki

{

ÖsszegzésElement = elem.Element (Összegzésnév) ?? új XElement ("összefoglaló");

nameElement = tulajdonságok.Element (nameName) ?? új XElement ("név");

descriptionElement = tulajdonságok.Element (descriptionName) ?? új XElement ("dekódolás");

urlElement = tulajdonságok.Element (urlName) ?? új XElement ("URL");

var dataItem = új MicrosoftResearchDataItem (elem.Element (azonosítónév) .érték, elem.Element (címnév) .érték, összefoglaló elem értékrend "", névElement.Value, descriptionElement.Value, urlElement.Value, csoport);

group.Items.Add (dataItem);

}

fogás (kivétel kivételével)

{
 } 

}

}
 this._itemGroups.Add (csoport); 

}

}

fogás (XmlException ex)

{
 }} 

Miután működésbe hoztam, kissé megcsúsztatom az XAML-et, elsősorban a képtől való megszabadulás érdekében (mivel az adatokban nincs felhasználható kép), és hozzá kell adni az elemek URL-jét. Azt is felfedeztem, hogy az XAML hivatkozásokat tartalmazott az eredeti SampleDataSource osztályra (annak ellenére, hogy a "Átnevezés" állítólag az összes fájlt ellenőrzi) a tervezési időre vonatkozó adatokkal kapcsolatban. Megpróbálom új adatforrásosztályra változtatni, de ez egy rendkívül nyomorult folyamat volt, mert folyamatosan próbálta az adatforrásosztályomat megtestesíteni; ennek az adatforrásnak nagy mennyiségű adatot kell eltávolítania a hálózatról, és elemeznie kell azt. Ennek eredményeként úgy döntöttem, hogy készítek egy "SampleMicrosoftResearchDataSource" -ot, amely elraktározza a MicrosoftResearchDataSource-t (és valamilyen keményen kódolt tartalmat használjon), és azt a tervezési idő megjelenítéséhez használom. Mellesleg, az az alkalmazás, amely futtatásakor az adatokat azonnal felhasználja / összekapcsolja az alkalmazással, az App.xaml.cs; létrehozza a MicrosoftResearchDataSource objektumot, és átadja a gyökérkeret navigációs módszerének. Ez meglehetősen csúnya, nem túl intuitív, és nehéz felfedezni, hogy pontosan honnan származnak az adatok, ami bonyolítja a rázkódást, amivel már hosszú ideje kapcsolatban voltam az XAML-rel kapcsolatban.

Az alkalmazás jól működik. Például a B ábra egy elem nézetet mutat (a HTML-et ki kell szedni a szövegből). Szeretem a jobb és bal oldali vezérlőelemeket, hogy lehetővé tegyék a személyhívást, bár egy érintőképernyős eszközön, ha a "Vissza" és a "Következő" oldalak mindkét oldalán vannak, mint például a Kindle lapozógombjai, valószínűleg jobb a használata (bár kevésbé intuitív). Nagyon érzem, hogy "valami szinte semmit" kaptam az alkalmazássablonnal, ami ritka; Általában úgy érzem, hogy a nullától kezdve a legjobb módszer az alkalmazások készítésére, mivel a sablonok soha nem tűnnek hasznosnak. B. ábra

Tétel nézet (Kattintson a képre a nagyításhoz.)

Az alkalmazás jelenlegi állapotában a legnagyobb probléma a teljesítmény. Abszolút kutya, és az ok egyértelmű: a forrásadatok sok, sok megabájtos XML formátumúak voltak, amelyeket a navigáláshoz használt memória adatstruktúrá alakítottak, és időnként egyszerre egy oldalra dobták.

A megoldás egyértelmű: képesnek kell lennie arra, hogy egyszerre csak maroknyi darabot töltsön be, akár akár néhány száz is. Ezt állandóan látjuk a mobil eszközökön, hogy időt takarítsunk meg a sávszélességnek. A következő 100 tétel elő- vagy igény szerinti lehívása érdemes lenne, ám a felszínen ez egy nagyon bonyolult technika. Lehetséges, hogy elmulasztottam a hajót egy olyan hasznos lehetőségnél, amely lehetővé teszi ezt; Többet fogok ásni, és remélhetőleg megfelelő választ találok erre. Alternatív megoldásként talán csak valami igazán egyszerű dolgot kell tennem, például be kell illeszteni az adatgyűjtési osztályok "hozam" viselkedését, és csak akkor kell betölteni az elemeket, ha nem vannak betöltve, majd tölteni őket az a fájl. Azt is gyanítom, hogy az URL elérési útjának teljes eltávolítása az adatobjektumokból és az UI-sablonok szerkesztése a képek megjelenítésének megkísérlése nélkül hatalmas segítséget jelent (gondoljon az üres, alapértelmezett képek betöltésére!). Eltart egy kis idő, amíg kitalálom, hogyan kell megválaszolni ezt a teljesítmény kérdést.

A következő célom ennek a projektnek a célja a keresés végrehajtása és a Szerződések felhasználása, hogy az alkalmazást keresési szolgáltatóvá tegyük a Windows 8-ra. Ezután tovább dolgozom az UI hozzáigazítását, mivel ez jelenleg nem felel meg az alkalmazás igényeinek. .

J.Ja

Tartsa naprakészen mérnöki készségeit, regisztrálva a TechRepublic ingyenes szoftvermérnök hírlevelére, amelyet minden kedden kézbesít.

© Copyright 2020 | mobilegn.com