Optimer Din ASP.NET MVC App til Mobil

I en verden, hvor mobiltelefoner og tablets i stigende grad dominerer internetadgangen, er det blevet afgørende for webudviklere at levere en optimeret browsingoplevelse på tværs af alle enheder. At ignorere mobilbrugere kan betyde tab af potentielle kunder og en forringet brugeroplevelse. Denne artikel dykker ned i, hvordan du effektivt kan tilføje et dedikeret mobilt område til din ASP.NET MVC-applikation, hvilket giver dig fuld kontrol over, hvordan dit indhold præsenteres for mobile besøgende.

Historisk set har ASP.NET haft sine udfordringer med mobilunderstøttelse. Tidligere versioner (2.0 til 3.5) inkluderede ASP.NET Mobile Controls, der var designet til ældre mobiltelefoner og WAP-browsere. Disse kontroller er dog forældede i dag, da den moderne mobilweb er domineret af HTML og responsive designs. Derfor er det vigtigt at omfavne nye tilgange, der adresserer nutidens mobile landskab.

Udfordringerne ved Mobil Understøttelse i Dag

Selvom de fleste moderne mobilbrowsere understøtter HTML, står udviklere stadig over for betydelige udfordringer, når de skal skabe en fremragende mobiloplevelse:

• Skærmstørrelse: Mobile enheder varierer dramatisk i form og skærmstørrelse. Det betyder, at du ofte skal designe helt forskellige sidelayouts for at sikre optimal visning. En side designet til en stor desktop-skærm vil sjældent fungere godt på en lille mobilskærm uden justeringer.
• Inputmetoder: Nogle enheder har tastaturer, andre stylusser, og de fleste moderne enheder er touch-baserede. Dette kræver overvejelser om forskellige navigationsmekanismer og datainputmetoder, så brugerne nemt kan interagere med din applikation. Store knapper og tilstrækkelig afstand mellem links er eksempelvis afgørende for touch-baserede grænseflader.
• Standardoverholdelse: Selvom HTML er universelt, kan mange ældre mobilbrowsere have begrænset understøttelse af de nyeste HTML-, CSS- eller JavaScript-standarder. Dette kan gøre det vanskeligt at opnå et ensartet udseende og funktionalitet på tværs af alle enheder.
• Båndbredde: Ydeevnen på mobilnetværk varierer voldsomt, og nogle brugere er på takster, der opkræver pr. megabyte. Det er derfor vigtigt at optimere indhold og ressourcer for at minimere dataforbrug og sikre hurtig indlæsningstid.

Der findes ingen universal løsning. Din applikation skal sandsynligvis se og opføre sig forskelligt afhængigt af den enhed, der tilgår den. Dette kan være en større udfordring for webudviklere end selv de berygtede 'browserkrige' for desktop-browsere.

Arkitektoniske Muligheder for Mobil Web

Generelt har webudviklere tre hovedmuligheder for at understøtte mobilbrowsere. Ofte er en kombination af disse den mest effektive tilgang:

1. Gør intet

Du kan simpelthen oprette en standard, desktop-orienteret webapplikation og stole på, at mobilbrowsere gengiver den acceptabelt. Dette er den billigste mulighed at implementere og vedligeholde, da den ikke kræver ekstra arbejde. Ulempen er dog en dårlig brugeroplevelse. Brugere vil ofte være tvunget til at zoome og scrolle horisontalt og vertikalt, hvilket er langt fra optimalt. Ældre enheder vil sandsynligvis slet ikke kunne gengive indholdet tilfredsstillende.

2. Løs problemet på klienten

Med omhyggelig brug af CSS (især CSS3 media queries) og progressiv forbedring kan du oprette markup, stilarter og scripts, der tilpasser sig den browser, der kører dem. For eksempel kan et multi-kolonne layout blive til et enkelt kolonne layout på enheder med smalle skærme. Fordelen er, at renderingen optimeres for den specifikke enhed, selv fremtidige ukendte enheder. Det giver også nem deling af server-side logik. Ulemperne inkluderer dog, at mobil- og desktop-enheder kan være så forskellige, at du ønsker helt forskellig information eller arbejdsgange, hvilket er svært at opnå robust med kun CSS. Det giver heller ingen understøttelse af varierende server-side logik og kan være ineffektivt med hensyn til båndbredde, da serveren måske skal sende markup for alle mulige enheder.

3. Løs problemet på serveren

Hvis din server ved, hvilken enhed der tilgår den (eller i det mindste enhedens karakteristika såsom skærmstørrelse og inputmetode), kan den køre forskellig logik og outputte forskellig HTML-markup. Dette giver maksimal fleksibilitet. Der er ingen grænse for, hvor meget du kan variere din server-side logik for mobiler eller optimere din markup. Det giver også effektiv båndbreddebrug, da du kun behøver at sende den information, som målenheden vil bruge. Ulempen er, at det nogle gange tvinger til gentagelse af kode (f.eks. at skulle oprette lignende, men let forskellige kopier af dine sider). Enhedsgenkendelse er heller ikke triviel og kræver en liste eller database over kendte enhedstyper, som ikke altid er perfekt opdateret.

For at opnå de bedste resultater kombinerer de fleste udviklere ofte klient-side og server-side teknikker. Mindre stilistiske forskelle håndteres bedst på klienten med CSS, mens store forskelle i data, arbejdsgange eller markup mest effektivt implementeres i server-side kode. Denne artikel vil fokusere på server-side teknikker, da ASP.NET Web Forms og MVC primært er server-side teknologier.

Browser- og Enhedsgenkendelse

Nøgleforudsætningen for alle server-side teknikker til understøttelse af mobile enheder er at vide, hvilken enhed din besøgende bruger. Endnu bedre end at kende producenten og modelnummeret er at kende enhedens karakteristika, såsom:

• Er det en mobil enhed?
• Inputmetode (mus/tastatur, touch, tastatur, joystick, …)
• Skærmstørrelse (fysisk og i pixels)
• Understøttede medie- og dataformater
• Osv.

Det er bedre at træffe beslutninger baseret på karakteristika end modelnummer, da du så er bedre rustet til at håndtere fremtidige enheder.

Brug af ASP.NET's indbyggede browsergenkendelse

ASP.NET Web Forms og MVC-udviklere kan umiddelbart opdage vigtige karakteristika ved en besøgende browser ved at inspicere egenskaber i Request.Browser-objektet. Eksempler inkluderer Request.Browser.IsMobileDevice, Request.Browser.MobileDeviceManufacturer, Request.Browser.ScreenPixelsWidth og Request.Browser.SupportsXmlHttp. Bag kulisserne matcher ASP.NET-platformen den indkommende User-Agent (UA) HTTP-header mod regulære udtryk i et sæt Browser Definition XML-filer. Platformen indeholder som standard definitioner for mange almindelige mobile enheder, og du kan tilføje brugerdefinerede definitioner for andre, du ønsker at genkende.

Brug af WURFL-enhedsdatabasen via 51Degrees.mobi Foundation

Selvom ASP.NET's indbyggede browsergenkendelsesunderstøttelse vil være tilstrækkelig for mange applikationer, er der to hovedtilfælde, hvor den måske ikke er nok:

• Du ønsker at genkende de nyeste enheder uden manuelt at oprette Browser Definition-filer for dem. .NET 4's Browser Definition-filer er for eksempel ikke opdaterede nok til at genkende Windows Phone 7, Android-telefoner, Opera Mobile-browsere eller Apple iPads.
• Du har brug for mere detaljeret information om enhedens funktioner, såsom inputmetode (touch vs. tastatur) eller hvilke lydformater browseren understøtter. Denne information er ikke tilgængelig i de standard Browser Definition-filer.

Wireless Universal Resource File (WURFL)-projektet vedligeholder meget mere opdateret og detaljeret information om mobile enheder. Den open source 51Degrees.mobi Foundation-biblioteket kan tilføjes dit projekt som et ASP.NET IHttpModule eller Browser Capabilities Provider. Det læser WURFL-data direkte og kobler det ind i ASP.NET's indbyggede browsergenkendelsesmekanisme. Når modulet er installeret, vil Request.Browser indeholde langt mere nøjagtig og detaljeret information, herunder korrekt genkendelse af mange nye enheder og deres avancerede funktioner.

Sådan Præsenterer ASP.NET MVC-applikationer Mobilspecifikke Sider

Da Model-View-Controller (MVC)-mønsteret adskiller applikationslogik (i controllere) fra præsentationslogik (i views), kan du vælge mellem flere tilgange til håndtering af mobilunderstøttelse i server-side kode:

1. Brug de samme controllere og views for både desktop- og mobilbrowsere, men render views med forskellige Razor-layouts afhængigt af enhedstypen. Dette fungerer bedst, hvis du viser identiske data på alle enheder, men blot ønsker at levere forskellige CSS-stylesheets eller ændre et par HTML-elementer på topniveau for mobiler.
2. Brug de samme controllere for både desktop- og mobilbrowsere, men render forskellige views afhængigt af enhedstypen. Dette fungerer bedst, hvis du viser nogenlunde de samme data og leverer de samme arbejdsgange for slutbrugere, men ønsker at rendere meget forskellig HTML-markup.
3. Opret separate områder (Areas) for desktop- og mobilbrowsere, og implementer uafhængige controllere og views for hver. Denne mulighed fungerer bedst, hvis du viser meget forskellige skærme, der indeholder forskellig information og fører brugeren gennem forskellige arbejdsgange optimeret til deres enhedstype. Det kan betyde en vis gentagelse af kode, men du kan minimere dette ved at udskille fælles logik i et underliggende lag eller en service.

Hvis du vælger den første mulighed og kun varierer Razor-layoutet pr. enhedstype, er det meget nemt. Du skal blot ændre din _ViewStart.cshtml-fil:

@{ Layout = Request.Browser.IsMobileDevice ? "~/Views/Shared/_LayoutMobile.cshtml": "~/Views/Shared/_Layout.cshtml"; }

Nu kan du oprette et mobilspecifikt layout kaldet _LayoutMobile.cshtml med en sidestruktur og CSS-regler optimeret til mobile enheder.

Resten af denne artikel fokuserer på den tredje mulighed – at oprette separate controllere og views for mobile enheder – så du kan styre præcis, hvilken delmængde af funktionalitet der tilbydes mobile besøgende.

Opsætning af et Mobilt Område (Area) i din ASP.NET MVC-applikation

Du kan tilføje et område kaldet "Mobile" til en eksisterende ASP.NET MVC-applikation på den normale måde: Højreklik på dit projektnavn i Solution Explorer, og vælg derefter Tilføj -> Område. Du kan derefter tilføje controllere og views, som du ville gøre for ethvert andet område i en ASP.NET MVC-applikation. Tilføj for eksempel en ny controller kaldet HomeController til dit Mobile-område, der skal fungere som en startside for mobile besøgende.

Sikring af at URL'en /Mobile når den mobile startside

Hvis du ønsker, at URL'en /Mobile skal nå Index-handlingen på HomeController inde i dit Mobile-område, skal du foretage to små ændringer i din routing-konfiguration. Først skal du opdatere din MobileAreaRegistration-klasse, så HomeController er standardcontrolleren i dit Mobile-område, som vist i følgende kode:

public override void RegisterArea(AreaRegistrationContext context) { context.MapRoute( "Mobile_default", "Mobile/{controller}/{action}/{id}", new { controller = "Home", action = "Index", id = UrlParameter.Optional } ); }

Dette betyder, at den mobile startside nu vil være placeret på /Mobile snarere end /Mobile/Home, fordi "Home" nu er det implicit standardcontroller-navn for mobile sider.

Dernæst skal du bemærke, at ved at tilføje en anden HomeController til din applikation (dvs. den mobile, ud over den eksisterende desktop-controller), vil du have brudt din almindelige desktop-startside. Den vil fejle med fejlen "Multiple types were found that match the controller named 'Home'". For at løse dette skal du opdatere din routing-konfiguration på topniveau (i Global.asax.cs) for at specificere, at din desktop HomeController skal have prioritet, når der er tvetydighed:

public static void RegisterRoutes(RouteCollection routes) { routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); routes.MapRoute( "Default", "{controller}/{action}/{id}", new { controller = "Home", action = "Index", id = UrlParameter.Optional }, new[] { "YourApplication.Controllers" } ); }

Nu vil fejlen forsvinde, og URL'en http://yoursite/ vil nå desktop-startsiden, og http://yoursite/mobile/ vil nå den mobile startside.

Omdirigering af Mobile Besøgende til dit Mobile Område

Der er mange forskellige udvidelsespunkter i ASP.NET MVC, så der er mange mulige måder at injicere omdirigeringslogik på. En elegant mulighed er at oprette et filterattribut, [RedirectMobileDevicesToMobileArea], der udfører en omdirigering, hvis følgende betingelser er opfyldt:

• Det er den første anmodning i brugerens session (dvs. Session.IsNewSession er sandt).
• Anmodningen kommer fra en mobilbrowser (dvs. Request.Browser.IsMobileDevice er sandt).
• Brugeren anmoder ikke allerede om en ressource i det mobile område (dvs. sti-delen af URL'en starter ikke med /Mobile).

Dette kan implementeres som et autorisationsfilter, der er afledt af AuthorizeAttribute, hvilket betyder, at det kan fungere korrekt, selvom du bruger output-caching. Du kan vælge enten at anvende det på specifikke controllere og handlinger, eller du kan anvende det på alle controllere og handlinger som et globalt MVC 3-filter i din Global.asax.cs-fil. Det er også muligt at oprette underklasser af dette attribut, der omdirigerer til specifikke placeringer inden for dit mobile område, hvilket giver finmasket kontrol over omdirigeringer.

Konfigurering af Formularautentificering til at Respektere dine Mobilsider

Hvis du bruger Formularautentificering, skal du bemærke, at når en bruger skal logge ind, omdirigerer den automatisk brugeren til en enkelt specifik "logon"-URL, som som standard er /Account/LogOn. Dette betyder, at mobile brugere kan blive omdirigeret til din desktop "logon"-handling.

For at undgå dette problem skal du tilføje logik til din desktop "logon"-handling, så den omdirigerer mobile brugere igen til en mobil "logon"-handling. Hvis du bruger standard ASP.NET MVC-applikationsskabelonen, skal du opdatere AccountController's LogOn-handling som følger:

public ActionResult LogOn() { string returnUrl = Request.QueryString["ReturnUrl"]; if ((returnUrl != null) && returnUrl.StartsWith("/Mobile/", StringComparison.OrdinalIgnoreCase)) { return RedirectToAction("LogOn", "Account", new { Area = "Mobile", ReturnUrl = returnUrl }); } return View(); }

... og derefter implementere en passende mobilspecifik "logon"-handling på en controller kaldet AccountController i dit Mobile-område.

Håndtering af Output-Caching

Hvis du bruger [OutputCache]-filteret, skal du tvinge cache-posten til at variere efter enhedstype. Ellers er det muligt, at en desktop-bruger besøger en bestemt URL (hvilket får dens output til at blive cachet), efterfulgt af en mobilbruger, der derefter modtager det cachede desktop-output. For at undgå dette problem skal du tilføje en VaryByCustom-parameter til din sides OutputCache-deklaration:

[OutputCache(Duration = 60, VaryByParam = "*", VaryByCustom = "isMobileDevice")]

Dernæst skal du tilføje følgende metode til din Global.asax.cs-fil:

public override string GetVaryByCustomString(HttpContext context, string custom) { if (string.Equals(custom, "isMobileDevice", StringComparison.OrdinalIgnoreCase)) return context.Request.Browser.IsMobileDevice.ToString(); return base.GetVaryByCustomString(context, custom); }

Dette vil sikre, at mobile besøgende på siden ikke modtager output, der tidligere er cachet af en desktop-besøgende.

Yderligere Vejledning og Forslag

Følgende diskussion gælder både for Web Forms- og MVC-udviklere, der bruger de teknikker, der er beskrevet i dette dokument.

Forbedring af Omdirigeringslogik med 51Degrees.mobi Foundation

Den omdirigeringslogik, der er vist i dette dokument, kan være perfekt tilstrækkelig for din applikation, men den fungerer ikke, hvis du har brug for at deaktivere sessioner, eller med mobilbrowsere, der afviser cookies (disse kan ikke have sessioner), fordi den ikke vil vide, om en given anmodning er den første fra den pågældende besøgende.

Du har allerede lært, hvordan den open source 51Degrees.mobi Foundation kan forbedre nøjagtigheden af ASP.NET's browsergenkendelse. Den har også en indbygget evne til at omdirigere mobile besøgende til specifikke placeringer konfigureret i Web.config. Den kan fungere uden at være afhængig af ASP.NET Sessions (og dermed cookies) ved at gemme en midlertidig log over hashes af besøgendes HTTP-headers og IP-adresser, så den ved, om hver anmodning er den første fra en given besøgende. Eksempelvis kan følgende element i fiftyOne-sektionen af web.config omdirigere den første anmodning fra en opdaget mobil enhed til ~/Mobile/Default.aspx:

<redirect firstRequestOnly="true" mobileHomePageUrl="~/Mobile/Default.aspx" timeout="20" devicesFile="~/App_Data/Devices.dat" mobilePagesRegex="/Mobile/" />

Deaktivering af Transkodere og Proxy-servere

Mobilnetværksoperatører har to brede mål i deres tilgang til mobilt internet: at levere så meget relevant indhold som muligt og maksimere antallet af kunder, der kan dele den begrænsede radionetværksbåndbredde. Da de fleste websider er designet til store desktop-skærme og hurtige fastnetforbindelser, bruger mange operatører transkodere eller proxy-servere, der dynamisk ændrer webindhold. De kan ændre din HTML-markup eller CSS for at passe til mindre skærme eller rekomprimere dine billeder, hvilket reducerer deres kvalitet.

Men hvis du har gjort en indsats for at producere en mobiloptimeret version af dit websted, ønsker du sandsynligvis ikke, at netværksoperatøren skal blande sig yderligere. Du kan tilføje følgende linje til Page_Load-begivenheden i en ASP.NET Web Form eller i en MVC-controller:

Response.Cache.SetNoTransforms();

For en ASP.NET MVC-controller kan du tilføje følgende metode-override, så den gælder for alle handlinger på den controller:

protected override void OnActionExecuting(ActionExecutingContext filterContext) { filterContext.HttpContext.Response.Cache.SetNoTransforms(); }

Den resulterende HTTP-besked informerer W3C-kompatible transkodere og proxier om ikke at ændre indhold. Der er dog ingen garanti for, at mobilnetværksoperatører vil respektere denne besked.

Stil Mobilsider til Mobilbrowsere

En vigtig teknik er viewport meta-tagget. Visse moderne mobilbrowsere render siden på et virtuelt lærred, også kaldet "viewport", og skalerer derefter resultatet ned for at passe til skærmens fysiske pixels. Dette tvinger brugeren til at zoome og panorere, hvilket er ubelejligt. Hvis du designer til mobil, er det bedre at designe til en smal skærm, så ingen zooming eller horisontal scrolling er nødvendig.

En måde at fortælle mobilbrowseren, hvor bred viewporten skal være, er gennem det ikke-standardiserede viewport meta-tag. For eksempel, hvis du tilføjer følgende til din sides HEAD-sektion:

<meta name="viewport" content="width=device-width">

...så vil understøttende smartphone-browsere layoutte siden på et virtuelt lærred, der matcher enhedens fysiske bredde. Dette betyder, at hvis dine HTML-elementer definerer deres bredder i procent, vil procenterne blive fortolket i forhold til denne bredde, ikke standard viewport-bredden. Som et resultat er brugeren mindre tilbøjelig til at skulle zoome og panorere horisontalt, hvilket betydeligt forbedrer mobilbrowsing-oplevelsen. For at dette skal fungere korrekt, må du ikke eksplicit tvinge elementer til at overskride denne bredde.

Ældre Windows Mobile- og Blackberry-enheder kan også acceptere følgende meta-tags i sidehovedet for at informere dem om, at indholdet er optimeret til mobil og derfor ikke bør transformeres:

<meta name="MobileOptimized" content="width" /> <meta name="HandheldFriendly" content="true" />

Ofte Stillede Spørgsmål

Her er nogle almindelige spørgsmål vedrørende mobiludvikling i ASP.NET MVC:

Hvad er de største udfordringer ved at understøtte mobile enheder?

De primære udfordringer inkluderer varierende skærmstørrelser, forskellige inputmetoder (touch, tastatur), inkonsekvent understøttelse af webstandarder på tværs af ældre browsere og behovet for at optimere for begrænset båndbredde på mobilnetværk. Der kræves en fleksibel tilgang til design og implementering.

Hvorfor er ASP.NET Mobile Controls forældede?

De ældre ASP.NET Mobile Controls var designet til WAP-browsere og WML/cHTML-markup, som var udbredt omkring 2005. I dag er HTML det universelle markup-sprog for både mobil- og desktop-browsere, hvilket gør de gamle kontroller irrelevante for de fleste moderne projekter.

Hvad er den bedste arkitektoniske tilgang til mobil understøttelse?

Den mest effektive tilgang er ofte en kombination af klient-side (f.eks. CSS Media Queries for stilistiske forskelle) og server-side teknikker (f.eks. separate views eller områder for store forskelle i data eller arbejdsgange). Dette giver maksimal fleksibilitet og effektivitet.

Hvordan kan jeg forbedre enhedsgenkendelse ud over Request.Browser.IsMobileDevice?

ASP.NET's indbyggede Request.Browser.IsMobileDevice er en god start, men den er ikke altid opdateret med de nyeste enheder eller detaljerede funktioner. Biblioteker som 51Degrees.mobi Foundation, der bruger WURFL-databasen, kan give langt mere nøjagtig og detaljeret information om enhedens karakteristika, hvilket er afgørende for avancerede løsninger.

Hvordan håndterer jeg output-caching med mobilsider for at undgå at servere desktop-indhold til mobilbrugere?

For at sikre, at mobile brugere får det korrekte cachede indhold, skal du bruge VaryByCustom="isMobileDevice" i dit [OutputCache]-filter og implementere GetVaryByCustomString-metoden i din Global.asax.cs-fil. Dette instruerer ASP.NET i at cache separate versioner af siden for mobile og desktop-brugere.

Kan jeg bruge jQuery Mobile med denne tilgang?

Ja, du kan sagtens integrere jQuery Mobile eller andre JavaScript-baserede mobilrammer med denne server-side tilgang. Serveren kan levere den grundlæggende HTML-struktur og derefter lade jQuery Mobile forbedre brugergrænsefladen på klienten, hvilket giver en kraftfuld kombination af server-side kontrol og klient-side responsivitet.

Er det nødvendigt at deaktivere transkodere og proxy-servere?

Det er stærkt anbefalelsesværdigt at forsøge at deaktivere transkodere og proxy-servere (via Response.Cache.SetNoTransforms()), især hvis du har investeret i at skabe en optimeret mobilversion af dit websted. Disse servere kan ellers ændre dit indhold og potentielt forringe den brugeroplevelse, du har designet. Selvom der ikke er nogen garanti for, at alle operatører respekterer dette, er det en bedste praksis.

Konklusion

At skabe en overlegen mobiloplevelse i din ASP.NET MVC-applikation handler om at mestre enhedsgenkendelse og implementere server-side teknikker, der giver dig kontrol over indhold og layout. Ved at oprette dedikerede mobile områder, håndtere routing og autentificering korrekt og optimere for caching og styling, kan du levere en problemfri og engagerende oplevelse for alle dine brugere, uanset hvilken enhed de benytter. Husk, at fleksibilitet og løbende tilpasning er nøglen i det dynamiske mobile landskab.

Hvis du vil læse andre artikler, der ligner Optimer Din ASP.NET MVC App til Mobil, kan du besøge kategorien Teknologi.