Cutting Edge

Sviluppo sito Mobile, Parte 2: Design

Dino Esposito Ci sono alcuni miti circa lo sviluppo del sito mobile che derivano principalmente dall'idea che una soluzione mobile è uno spin-off di un sito Web di desktop esistente. Penso che il termine spin-off è abbastanza appropriato descrivere la relazione tra un cellulare e un sito Web desktop. La questione cruciale riguarda i dettagli di come si gira in realtà il sito mobile fuori del sito desktop completo.

Si vuole offrire agli utenti la migliore esperienza di navigazione per il dispositivo hanno — si tratti di un normale PC, uno smartphone, un tablet o un cellulare vecchio stile. (Sto saltando sopra una famiglia emergente del grande schermo dispositivi quali televisori intelligenti, che richiederanno i propri rendering ad hoc nel prossimo futuro.) Si desidera presentare agli utenti una serie di pagine che può essere meglio visualizzato sul dispositivo richiedente. Come scegliete il markup che meglio si adatta un determinato dispositivo? A mio parere, questo è un punto dolente e merita un po' di attenzione e di analisi per tenervi da credere i miti e ignorando le condizioni reali.

Il mito di One-sito-Fits-All

Maggior parte degli sviluppatori di riconoscere la necessità di avere un cellulare e un sito Web desktop che sembrano diversi uno da altro. Dimensioni dello schermo sono diverse, la potenza di calcolo è diversa e casi d'uso soprattutto stanno per essere in gran parte diverso e meno in un sito mobile. Tuttavia, l'idea di costruire un sito Web che si adatta automaticamente alle diverse risoluzioni è attraente per molti sviluppatori. Ma può anche essere un percorso pericoloso con più contro che Pro. Realisticamente, il saldo pro/con sta andando a dipendere dalla natura della domanda: più sofisticati del sito, i più contro e i professionisti meno. Che cosa significa, esattamente, di avere un unico sito che si adatta a più dispositivi? Molti sviluppatori hanno brutti ricordi di quando, solo pochi anni fa, se non ancora oggi — costruzione di un sito Web era una questione di districarsi da soli dal pasticcio di diversi browser (desktop) e funzionalità di rendering diverso. Per questo motivo, la maggior parte dei sviluppatori benvenuto l'idea di un singolo sito che gli utenti possono visitare con qualsiasi dispositivo (computer portatili, tavolette, telefoni, e-lettori, smart TV e così via), ma con un'esperienza diversa.

Il punto è che, con browser desktop, la maggior parte delle differenze sono nello spazio di rendering. I dispositivi mobili, invece, aggiungere una dimensione più al problema: funzionalità diverse. Così l'obiettivo deve essere costruire un sito Web che propone automaticamente l'esperienza più appropriato per diversi dispositivi, piuttosto che un'eccessiva enfasi sul rendering più appropriato del contenuto.

Suona come una sottile differenza? Beh, client-side adattamento versus adattamento sul lato server di contenuti per dispositivi mobili è un punto aperto in questi giorni.

A me non funziona l'idea di un sito Web che serve lo stesso contenuto al quale il browser si regola secondo il dispositivo viene utilizzato solo come una regola, ma potrebbe funzionare come un'eccezione. Il mito di one-sito-fits-all si basa sulla cima la capacità del browser di selezionare dinamicamente il foglio di stile CSS più appropriato dato alcune caratteristiche del dispositivo fisico. Let's Scopri di più.

CSS Media query

Introdotto con CSS3 media query sono una caratteristica di browser destinata a semplificare la progettazione di siti che potrebbero essere consumati attraverso dispositivi di varie dimensioni di schermo. Dovrebbe essere notato che il dispositivo di termine in questo contesto specifico include anche i computer portatili e PC desktop. Per questo motivo, le dimensioni dello schermo potrebbero variare da 24 pollici di un monitor da tavolo a 3 pollici di smartphone più.

L'idea dietro media query CSS è che creare un sito Web con un singolo set di funzioni e quindi applicare diversi stili CSS ad esso da un foglio di stile diverso per i diversi mezzi di carico. Il grande miglioramento portato da CSS3 è che il mezzo di pagina schermo ora può essere limitato a tutti i dispositivi che soddisfano un insieme di regole di dato. Ecco un esempio di una query di media:

    <link type="text/css"
      rel="stylesheet"
      href="downlevel.css"
      media="only screen and (max-device-width: 320px)">

Una volta inseriti in una pagina Web (o ASP.NET MVC view), il precedente markup collega il file downlevel.css solo se viene visualizzata la pagina attraverso un browser con una larghezza di 320 pixel o meno. Utilizzando alcuni degli elementi precedenti consente di ottimizzare il rendering di qualsiasi pagina per dispositivi di dimensioni differenti dello schermo. Bene, basta, la regola del foglio di stile viene applicata in modo dinamico e regola anche il contenuto della pagina quando l'utente ridimensiona la finestra del browser sul desktop.

Dovrebbe essere notato che in media query CSS, non c'è nessuna verifica esplicita sul tipo di browser, mobile o desktop; tutto ciò che conta è la larghezza effettiva dello schermo. Tuttavia, quando si utilizza una query di media di filtrare i browser con una larghezza maggiore di 320 pixel, si sta sicuramente selezionando tutti i dispositivi mobili e telefoni cellulari con quel formato di schermo.

La parola chiave solo nella query media deve essere aggiunto al solo scopo di nascondere l'istruzione media dal browser che non supportano le media query. Questi browser, infatti, non capire il tipo di supporto e beatamente andare avanti con il loro rendering. È un pensiero comune in questi giorni che semplicemente aggiungendo media esegue una query in un sito di che renderlo pronto per client mobili. Il mio parere è leggermente diverso. Media query CSS contribuire a rendere la pagina di contenuto più mobile-friendly, ma essi non aiutano in alcun modo a ottimizzare il sito mobile per altri aspetti critici, come il numero di HTTP richieste per pagina e la quantità di dati scaricati.

Inoltre, media query può discernere solo un numero limitato di proprietà del browser. La documentazione completa sui media query può essere trovata alla bit.ly/yOuW7q.

Proprietà CSS media query dirvi qualcosa circa il dispositivo — ma non tutto quello che dovete sapere. Ad esempio, non si dispone di alcun indizio circa il sistema operativo, se il dispositivo è mobile o non, che si tratti di una tavoletta o una smart TV o forse un bot. Allo stesso modo, con media query CSS, non avete idea se il browser richiedente supporta Asynchronous JavaScript e manipolazione di XML e Document Object Model, come occupa di HTML5 e jQuery Mobile o quale tipo di markup preferisce.

Essendo una funzionalità CSS, media query vengono elaborate dal sottosistema di CSS del browser. Si scopre che in media query è possibile selezionare solo un insieme di stili di elemento che nascondere o ridimensionare alcuni elementi che sono o troppo grandi o che può essere ridotto su un piccolo schermo. Con le query di CSS media, si pagano ancora i costi di download e di mantenere questi elementi in memoria anche quando essi non vengono visualizzati. È possibile utilizzare alcuni JavaScript nelle pagine per scaricare a livello di codice o per configurare immagini. In questo modo, gli elementi pesanti possono essere gestiti in maniera più ottimizzata. Questo lavoro extra, tuttavia, sta a voi.

Ultimo ma non meno importante, media query richiede un browser che supporti i CSS3. Questo significa media query CSS grande lavoro su molti smartphone, ma non sui vecchi dispositivi — e non anche su Windows Phone 7. Può optare per una soluzione all-browser per media query ottenendo un jQuery plug-in da bit.ly/JcwwFY. Tuttavia, in questo caso, non c'è nessuna garanzia che il browser mobile dove si potrebbe utilizzare questo plug-in può realmente eseguire jQuery.

Nel complesso, media query CSS non sono una tecnologia specificamente mirata allo sviluppo mobile. Tuttavia, la flessibilità dei media query CSS li rende interessanti da utilizzare per servire diversi dispositivi con un solo codebase. Potrebbe essere una soluzione in alcuni casi, ma media query CSS non sono la strada da percorrere per qualsiasi scenario.

Multi-Serving

Il percorso sul lato server per lo sviluppo mobile è basato sull'idea che il sito Web riceve una richiesta, ottiene l'user agent e utilizza tali informazioni per capire l'effettiva funzionalità del browser. Successivamente, armati con tale conoscenza, il sito Web in modo intelligente decide che cosa sarebbe il contenuto più appropriato per la periferica richiedente.

Come sarebbe trovare le funzionalità del browser? Attualmente, la strategia più efficacia sembra essere utilizzando un dispositivo descrizione Repository (DDR) — vale a dire un database che memorizza quasi tutte le possibili proprietà di quasi tutti i dispositivi e che viene costantemente aggiornato come nuovi dispositivi ha colpito il mercato. In che modo è diverso dall'oggetto Request ASP.NET un DDR? In un certo senso, l'oggetto Request può essere visto come un semplice DDR che contiene buone informazioni sul browser desktop ma non particolarmente accurate informazioni sui dispositivi mobili.

Il numero di diversi modelli di dispositivi mobili è nell'ordine di migliaia e in crescita. Le proprietà che uno sviluppatore può trovare interessante per ogni profilo del dispositivo in un caso particolare potrebbero variare in modo significativo, ma se si prende l'Unione di tutti loro si raggiunge facilmente a poche centinaia. Quali opzioni hai oggi per ottenere informazioni sul dispositivo preciso?

Il DDR chiamato Wireless Universal Resource File (WURFL) è un database XML che attualmente contiene più di 15.000 profili di dispositivi mobili e corrisponde a metà un stringhe agente milioni utente. Ogni profilo contiene più di 500 funzioni. WURFL è un framework open source rilasciato sotto un classico schema doppia licenza AGPL v3 e commerciale. WURFL è anche disponibile un servizio di cloud e alcuni piani di base, limitati ad alcune proprietà, sono gratuiti. Per ulteriori informazioni, visitare scientiamobile.com. WURFL non è solo DDR là fuori, ma WURFL può essere considerato uno standard de facto. Tra le altre cose, WURFL è impiegato nella piattaforma mobile di Facebook e Google. WURFL dispone di API per PHP, Java e Microsoft .net Framework, e si inserisce senza problemi in applicazioni ASP via NuGet.

Per quanto riguarda la piattaforma ASP.NET, un'altra soluzione interessante DDR è 51Degrees (51Degrees). 51Degrees originariamente invocata WURFL come la fonte di informazioni sul dispositivo, ma è stato rilanciato recentemente con una nuova architettura interna e vocabolario. 51Degrees è un'iniziativa puramente commerciale, ma offre una versione gratuita del quadro limitato a quattro proprietà: isMobile, ScreenPixelWidth, ScreenPixelHeight e LayoutEngine, che si riferisce al motore di rendering del browser. Per quanto riguardano le loro offerte gratis, sono quasi equivalenti, a parte le licenze WURFL e 51Degrees.

Comprensione desideri e bisogni

Sviluppo mobile è principalmente di capire che cosa i clienti vogliono e hanno bisogno. Questo è un punto cruciale e si è risolto quando si dispone di una selezione ben scelta di casi d'uso. Per siti di telefonia mobile, in particolare, stimo che ottenere una buona selezione di casi di utilizzo di attuare è la maggior parte del lavoro. Di là di questo, lo sviluppo mobile richiede riconoscendo che la navigazione mobile è diversa. Questo significa che avere un solo sito Web che si trasforma in diversi rendering per diversi dispositivi è il tuo obiettivo, ma non raggiunto gratis con solo la magia di alcuni file CSS. CSS non contiene quasi nessuna logica, e probabilmente si desidera avere logica coinvolto nel decidere quale contenuto di servire a una determinata classe di dispositivi.

Nel prossimo articolo, verrà illustrato come passare da un desktop ad un sito mobile, offrendo così due siti, ma forse un esperienza per l'utente. Più tardi potrai approfondire segmentazione del browser e delle alternative a media query.

Dino Esposito è l'autore di "Architettura Mobile soluzioni per l'impresa" (Microsoft Press, 2012) e "programmazione ASP.NET MVC 3" (Microsoft Press, 2011) e coautore di "Microsoft .net:” (Microsoft Press, 2008). Vive in Italia e partecipa spesso come relatore a eventi del settore in tutto il mondo. Seguirlo su Twitter a twitter.com/despos.

Grazie all'esperto tecnica seguente per la revisione di questo articolo: Steve Sanderson

Condividi tramite