Costruire applicazioni web mobile con ASP.NET
ASP.NET ha da sempre un supporto nativo per lo sviluppo di applicazioni mobile. Fin dalla prima versione, infatti, è stato dotato di una tecnologia chiamata adaptive rendering, che adatta l'output dei web control (nel caso di WebForm) in base al browser che lo richiede, usando le browser capabilities, la capacità, cioè, di stabilire un dato browser cosa è in grado di supportare.
In passato c'erano i mobile controls, capaci di emettere output in diversi formati (cHTML, XHTML, WML), ma oggi sono deprecati. Nel corso degli anni, infatti, il web mobile si è radicalmente trasformato. Mentre, in passato, era una miriade diversa di formati e protocolli, tutti incompatibili tra di loro, oggi, possiamo dirlo con certezza, stiamo assistendo a una convergenza verso HTML5, sulla falsa riga di quanto già accaduto con il desktop. Perché è importante progettare applicazioni mobili? Perché molte stime lo danno compreso tra il 5% ed il 15% del traffico web mondiale, che è un numero di tutto rispetto se si pensa che in molte nazioni non è ancora così diffuso l'uso di reti cellulari.
In questo articolo cercheremo di analizzare quello che ASP.NET ci mette a disposizione e cosa possiamo fare per iniziare a costruire siti web per il mobile, analizzando ciò che gli strumenti e le tecnologie ci mettono a disposizione.
Prima di iniziare
Prima di iniziare, occorre precisare che lo sviluppo di un'applicazione web per mobile si basa su semplici regole: prima di tutto, quella di costruire la propria applicazione in maniera semplice, ricordando che, nella maggior parte dei casi, l'interazione dell'utente avverà attraverso le dita (il touch) e sfruttando uno schermo di dimensioni ridotte. Per questo motivo è bene evitare di costruire interfacce complesse: tutto sommato questo è un aspetto più di UX (User eXperience) che di sviluppo, ma bisogna tenerne comunque conto.
Generalmente, quando si approccia la creazione di un'applicazione mobile, le strade che possiamo prendere sono due:
- creiamo un sito parallelo rispetto a quello "normale";
- procediamo con l'ottimizzare, solo dove necessario, le nostre viste per un uso mobile.
Ciascuno dei due approcci ha pro e contro. Creare un sito parallelo ha dei costi di sviluppo e manutenzione, ma ci consente di avere un'usabilità tarata al massimo per il mobile; viceversa, adattare le view esistenti ci consente di essere produttivi sin da subito, ma c'è da pagare lo scotto di non avere un'usabilità sempre pensata per il mobile, che, come abbiamo visto, ha caratteristiche diverse rispetto ad un sito non-mobile.
Molto spesso la scelta migliore è, come spesso accade, nel mezzo: predisporre delle view ottimizzate per il mobile dove queste abbiano senso, iniziando a offrire lo stesso sito con una skin differente.
Prima di addentrarci ulteriormente, facciamo un passo indietro e iniziamo a capire come poter individuare il tipo browser.
Come individuare il tipo di browser?
La tecnica denominata browser detection consiste nell'identificare il browser e capire, in base allo user agent, da che tipo di device arriva la richiesta. Benché queta tecnica sia molto potente, ha il difetto di subire i cambiamenti, che al giorno d'oggi, con il susseguirsi di rilasci di browser ed il proliferare di piattaforme mobile, possono portare ad un errato riconoscimento delle funzionalità disponibili. Per questo motivo, generalmente, si preferisce fare la cosidetta feature detection, dove, di volta in volta, si procede al riconoscimento del supporto di una data funzionalità.
L'approccio che applicheremo, ancora una volta, è un ibrido: cercheremo di capire se il device è già riconosciuto da ASP.NET come mobile device, offrendo una skin (una Master Page, in fin dei conti...) adattata al mobile, così da risparmiare byte da inviare al client. Nel caso non lo fosse, provvederemo ad offrire la skin normale, dove, però, avremo opportunamente aggiunto un CSS che applica le stesse formattazioni che avremmo nel sito mobile, sfruttando le Media Queries di CSS3.
Ci torniamo tra un attimo. Prima di partire, capiamo come poter identificare, in maniera programmatica, se un certo device è un mobile device oppure no:
C#
bool mobile = Request.Browser.IsMobileDevice;
Visual Basic
Dim mobile as Boolean = Request.Browser. IsMobileDevice
Questa istruzione non fa nient'altro che andare a recuperare le informazioni nelle browser capabilities di ASP.NET, che sono anche sfruttate dall'adaptive rendering. Navigando con un device mobile, come Windows Phohe o iPhone, quella proprietà diventa, ovviamente, positiva.
Come testare le applicazioni
Se volete testare questa prima pagina, dovete procurarvi un emulatore: quello di Windows Phone è incluso nell'SDK di Windows Phone e funziona sotto Windows. Quello per iPhone no, perché necessita di MacOSX. Fermo restando che quando si sviluppano applicazioni per il mondo mobile è necessario, sempre, testarlo sulle piattaforme che andremo a supportare, è più facile, come sviluppatori Windows, procurarci l'emulatore per Windows Phone, che per i nostri test va benissimo.
Dobbiamo ricordarci, a tal proposito, che il server web di Visual Studio non accetta richieste da remoto e l'emulatore, di fatto, è un'altra macchina remota: per questo motivo, dovremo caricare il nostro sito su un vero server IIS, così da poterlo raggiungere in rete.
Ecco di seguito i link ai più diffusi emulatori per il test:
- Windows Phone (nell'SDK di Windows Phone);
- Opera Mobile Emulator;
- Apple Safari, con lo user agent impostato su iPhone;
- FireFox, con FireFox User Agent Switcher.
Fatte queste premesse, possiamo iniziare a cercare di fare passi in avanti.
Costruire applicazioni web mobile con ASP.NET WebForm
Entriamo nel vivo del nostro problema. Creiamo un nuovo sito web in Visual Studio. Per ora, inizieremo con ASP.NET WebForm, per poi proseguire con ASP.NET MVC.
Partiamo con il definire le nostre due master page, che chiameremo "MasterPage.master" e "MasterPage-Mobile.master". ASP.NET WebForm consente di definire le master page anche in maniera programmatica, attraverso l'evento Pre_Init.
Fermo restando che potremmo prendere diverse strade per risolvere questa problematica (come creare una classe di base da cui tutte la pagine debbano ereditare), la più elegante e meno invasiva è quella di costruire un HttpModule. Gli HttpModule sono parte importante dell'architettura di ASP.NET, perché consentono, in maniera pluggabile, di intercettare gli stati dell'applicazione (e quindi delle richieste). In maniera specifica, noi intercetteremo l'evento PreRequestHandlerExecute, che si verifica quando ASP.NET ha già stabilito l'HttpHandler che deve eseguire la richiesta, ma non l'ha ancora eseguita effettivamente. A questo punto, potremo accedere all'istanza della pagina attraverso la proprietà CurrentHandler di HttpContext, per poter intercettare l'evento Pre_Init della pagina ed eseguire il cambio di master page. Ecco di seguito il codice necessario:
C#
public class MobileModule : IHttpModule
{
public void Dispose()
{
}
public void Init(HttpApplication context)
{
context.PreRequestHandlerExecute += new EventHandler(context_PreRequestHandlerExecute);
}
void context_PreRequestHandlerExecute(object sender, EventArgs e)
{
var ctx = HttpContext.Current;
// patch per richieste senza nome file (es /sito/)
// queste richieste vanno ignorate, perchè ASP.NET poi rimappa sull'handler vero
if (ctx.CurrentHandler is DefaultHttpHandler)
{
return;
}
var page = ctx.CurrentHandler as Page;
// è una pagina, vediamo se è mobile
if (page != null && ctx.Request.Browser.IsMobileDevice)
{
// cambiamo la master page
page.PreInit += (o, e2) =>
{
page.MasterPageFile = "/MasterPage-Mobile.master";
};
}
}
}
Visual Basic
Public Class MobileModule
Implements IHttpModule
Public Sub Dispose()
End Sub
Public Sub Init(context As HttpApplication)
context.PreRequestHandlerExecute += New EventHandler(AddressOf context_PreRequestHandlerExecute)
End Sub
Private Sub context_PreRequestHandlerExecute(sender As Object, e As EventArgs)
Dim ctx = HttpContext.Current
' patch per richieste senza nome file (es /sito/)
' queste richieste vanno ignorate, perchè ASP.NET poi rimappa sull'handler vero
If TypeOf ctx.CurrentHandler Is DefaultHttpHandler Then
Return
End If
Dim page = TryCast(ctx.CurrentHandler, Page)
' è una pagina, vediamo se è mobile
If page IsNot Nothing AndAlso ctx.Request.Browser.IsMobileDevice Then
' cambiamo la master page
page.PreInit += Function(o, e2)
page.MasterPageFile = "/MasterPage-Mobile.master"
End Function
End If
End Sub
End Class
Attenzione: Questo articolo contiene un allegato.
Contenuti dell'articolo
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Ottimizzare il mapping di liste di tipi semplici con Entity Framework Core
Mascherare l'output di un valore all'interno dei log di un workflow di GitHub
Load test di ASP.NET Core con k6
Eseguire una query su SQL Azure tramite un workflow di GitHub
Generare file PDF da Blazor WebAssembly con iText
Miglioramenti agli screen reader e al contrasto in Angular
Implementare il throttling in ASP.NET Core
Utilizzare HiLo per ottimizzare le insert in un database con Entity Framework
Evitare (o ridurre) il repo-jacking sulle GitHub Actions
Personalizzare l'errore del rate limiting middleware in ASP.NET Core
Evitare la script injection nelle GitHub Actions
Autenticarsi in modo sicuro su Azure tramite GitHub Actions
Top Ten Articoli
- Blazor e il pattern Model-View-ViewModel
di Giampaolo Tucci - Le novità in ASP.NET Core e Blazor con .NET 7
di Morgan Pizzini - Gestire le chiamate a servizi esterni in ASP.NET Core e Blazor tramite Polly
di Morgan Pizzini - Realizzare una Progressive Web Application con Blazor e ASP.NET Core
di Giampaolo Tucci - Creare API GraphQL con ASP.NET Core e HotChocolate
di Moreno Gentili - Usare gRPC come infrastruttura per i nostri servizi web
di Morgan Pizzini - Introduzione a Blazor WebAssembly
di Marco De Sanctis, Moreno Gentili - Utilizzare scene 3D in Windows Presentation Foundation
di Marco Leoncini - Abilitare e gestire il prerendering nelle applicazioni Blazor WebAssembly
di Marco De Sanctis - Le novità di ASP.NET Core 5
di Marco De Sanctis
Articoli via e-mail
Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!
In primo piano
I più letti di oggi
In evidenza
- Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
- Disabilitare automaticamente un workflow di GitHub (parte 2)
- Ottimizzazione dei block template in Angular 17
- Utilizzare il trigger SQL con le Azure Function
- Paginare i risultati con QuickGrid in Blazor
- Come EF 8 ha ottimizzato le query che usano il metodo Contains
- Evitare (o ridurre) il repo-jacking sulle GitHub Actions
- Definire stili a livello di libreria in Angular