En titt på Windows 8-utvikling med HTML og JavaScript

En av de mer interessante utviklingen i Windows 8-historien er muligheten til å skrive Metro-applikasjoner ved hjelp av HTML og JavaScript. Dette var et smart trekk fra Microsoft på noen måter: Mange utviklere vet og har et komfortnivå med HTML og JavaScript; det er mange gode verktøy for å jobbe med HTML og JavaScript; og systemer som Appcelerators Titanium og PhoneGap har hatt stor suksess med å la utviklere skrive native applikasjoner med HTML og JavaScript.

Det er fordeler og ulemper med å jobbe med HTML og JavaScript på Windows 8. En stor ulempe er at du jobber med det nye WindowsRT API, noe som betyr at i motsetning til noen av de andre alternativene der ute, vil ikke applikasjonene dine være plattformkompatible . På den annen side gir WindowsRT API deg tilgang til funksjoner og funksjonalitet som enten fremdeles modnes i HTML5, ikke eksisterer eller kan være vanskeligere å få tilgang til. All den kjekkeste funksjonaliteten i WindowsRT rundt "hubs" og "kontrakter" med andre applikasjoner og selve operativsystemet er et flott eksempel på ting du ikke kan gjøre med andre systemer. En annen underlighet er at programmeringsmodellen virker som XAML-modellen.

Det er enkelt å komme i gang med en Metro-applikasjon i HTML. Start et nytt Visual Studio-prosjekt, utvid JavaScript, og utvid deretter Windows Metro Style for å velge malen du ønsker ( figur A ). Når prosjektet er opprettet, vil du se en grunnleggende applikasjon. Figur A

Velge riktig mal (Klikk på bildet for å forstørre.)
Det første jeg plukket opp var en default.js-fil som styrer programmets oppstart, hvordan den samhandler med operativsystemet (som håndtering av suspensjon), og så videre; det ligner veldig på hva app.xaml gjør. Faktisk er prosjektstrukturen ganske lik det jeg har sett i XAML Metro-prosjekter ( figur B ). Figur B

Et øyeblikksbilde av standard prosjektstruktur
Jeg er litt overrasket over at systemet ikke bruker jQuery ut av boksen, fordi Microsoft har gjort mange trekk i den retningen for ASP.NET MVC. I stedet er det vi ser en samling av funksjoner ( figur C ) som sendes til en funksjon som kartlegger funksjonene til sidens hendelser. Figur C

Kode som registrerer seg selv til siden. (Klikk på bildet for å forstørre.)

Sluttresultatet er et HTML / JavaScript Metro-prosjekt ligner veldig på en XAML Metro-applikasjon. Dette virker som en fornuftig tilnærming, selv om det kan være forskjellig fra hvor mange som for tiden skriver og administrerer HTML5 + JavaScript-applikasjonene sine.

Det er tre viktige API-komponenter: WinRT-brikkene, HTML / CSS DOM og LiveConnect API. WinRT-brikkene er nesten helt identiske med det som er tilgjengelig for Metro XAML-applikasjoner; de store forskjellene er i brukergrensesnittkontroller, og noen få ting relatert til XAML-modellen. HTML / CSS DOM som er tilgjengelig, er en delmengde av hele HTML5-stabelen. LiveConnect er et system for å utføre pålogginger og lagring av data på en rekke plattformer (iOS, Android, Web, Windows 8 og Windows Phone).

Da .NET først kom ut, hadde Microsoft en tosidig strategi for å fange utviklerens tankeløsning: De hadde VB.NET til å appellere til VB6-utviklerne, og de hadde C # til å trekke inn Java-programmererne. I begge tilfeller var likheten mellom hva folk migrerte fra og .NET-tilbudet i beste fall overflatenivå. Selv om resultatene var imponerende, følte mange mennesker (spesielt VB6-utviklere) seg dårlig brent av opplevelsen; de lærte raskt at en hovedsakelig delt syntaks på språknivå ikke var det samme som en jevn overgang. Så lenge du ikke prøver å tilnærme HTML / JavaScript Metro-prosjektene som "bare en webside som kjører av det lokale filsystemet", vil dine skuffelsesnivåer holdes på et minimum, og du vil ha riktig syn på ting.

J.Ja

© Copyright 2021 | pepebotifarra.com