Cos'è WebKit e come si relaziona ai CSS? Motori dei browser Web: cosa sono e cosa sono E quindi, tutti i WebKit ora sono completamente diversi. Ho paura

Traduzione

Per molti di noi sviluppatori, WebKit è una scatola nera. Inseriamo HTML, CSS, JS e un mucchio di immagini e WebKit, in qualche modo... magicamente, ci dà una pagina web che sembra e funziona bene.
Ma in realtà, come dice il mio collega Ilya Grigorik :

Un web kit non è una scatola nera. Questa è una scatola bianca. E non solo bianco, ma anche una scatola aperta.
Allora proviamo a capire alcune cose:

Cos'è WebKit?
Cosa non è WebKit?
Come viene utilizzato WebKit dai browser WebKit?
Perché molti WebKit non sono uguali?

Ora, soprattutto dopo la notizia che Opera è passata a WebKit, siamo circondati da molti browser WebKit, ed è abbastanza difficile dire cosa li unisce e dove vanno per la loro strada. Di seguito, spero che cercheremo di fare luce su questo problema. Di conseguenza, sarai in grado di identificare meglio le differenze tra i browser, segnalare i bug al tracker corretto e condurre lo sviluppo di più browser in modo più efficiente.Componenti standard del browser WebElenchiamo alcuni componenti dei browser moderni:

Analisi (analisi HTML, XML, CSS, Javascript)
Disposizione
Rendering di testo e grafica
Decodifica delle immagini
Interazioni con GPU
Accesso alla rete
Accelerazione hardware

Quali sono comuni a tutti i browser WebKit? Praticamente solo i primi due.

Ciascuna "porta" WebKit implementa i componenti rimanenti in modo diverso. Scopriamo cosa significa.

Porte WebKit

Ci sono molti "port" di WebKit e io fornisco Ariya Hidayat, hacker e tecnologia WebKit. Il direttore di Sencha ha il diritto di parlare di questo:

L'associazione più popolare con il concetto di WebKit è solitamente la versione di WebKit di Apple, che funziona su Mac OS X (la prima e originale libreria WebKit). Come puoi immaginare, le varie interfacce sono implementate utilizzando varie librerie native di Mac OS X, principalmente focalizzato nel componente CoreFoundation. Ad esempio, se definisci un pulsante piatto colorato con un raggio di contorno specifico, WebKit sa dove e come disegnare quel pulsante. Allo stesso tempo, il rendering finale del pulsante (come pixel sul monitor dell'utente ) ricade su CoreGraphics.

Come accennato in precedenza, la CoreGraphics utilizzata è unica per ciascuna porta WebKit. Chrome per Mac, ad esempio, utilizza Skia.

Ad un certo punto, WebKit è stato “portato” su diverse piattaforme, sia desktop che mobili. Questa variazione è solitamente chiamata "porta WebKit". Per Safari Windows, Apple ha anche "portato WebKit" in modo indipendente per l'esecuzione su Windows utilizzando la sua libreria CoreFoundation (implementazione limitata).

...nonostante Safari su Windows sia ormai morto.Oltre a questo c'erano anche molti altri "port" (vedi elenco completo). Google ha creato e continua a supportare il suo porting su Chromium. C'è anche WebKitGtk, che è basato su Gtk+. Nokia (e ora Trolltech, che l'ha acquistata) supporta il port WebKit Qt, che è diventato popolare come modulo QtWebKit.
Alcuni port WebKit

Safari
- Safari per OS X e Safari per Windows sono due porte diverse
- La build notturna di WebKit è una build del "port" del codice sorgente del Mac utilizzato per Safari, solo più recente
Safari sul cellulare
- Sviluppato in una filiale privata, ma è stato successivamente aperto.
- Chrome per iOS (utilizza WebView di Apple; maggiori informazioni sulla differenza più avanti)
Cromo (Cromo)
- Chrome per Android (utilizza direttamente il "port" di Chromium)
- Chromium è anche la base dei browser: Yandex, Sogou e presto Opera.
browser Android
- Utilizza l'ultimo codice sorgente WebKit disponibile al momento del rilascio.
Ancora più porte: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, la porta EFL (Tizen), wxWebKit, WebKitWinCE, ecc.

Porti diversi possono concentrarsi su compiti diversi. Il focus del port su Mac è la separazione tra browser e sistema operativo e la fornitura di collegamenti Obj-C e C++ per incorporare il motore di rendering nelle applicazioni native. Il focus del porting di Chromium è interamente sul browser. QtWebKit offre il suo port da utilizzare insieme alla sua architettura applicativa multipiattaforma come motore di rendering. Ciò che è comune in tutti i browser WebKit

Innanzitutto, diamo un'occhiata alle funzionalità comuni utilizzate in tutti i browser WebKit:

Sai che è divertente, ho fatto diversi tentativi per scrivere questo paragrafo. E ogni volta i membri del team di Chrome mi correggevano, come vedrai...

Quindi, prima di tutto, WebKit analizza l'HTML allo stesso modo. Bene, tranne che Chromium è l'unico port al momento che include il supporto per i thread per l'analisi HTML.

... Ok, ma dopo aver analizzato l'HTML, l'albero DOM viene costruito allo stesso modo. Bene, in realtà Shadow DOM è abilitato solo per il port di Chromium, il che significa che la costruzione del DOM varia. Anche per elementi personalizzati.

…Ok, WebKit crea oggetti finestra e documento allo stesso modo per tutti. Vero, sebbene le proprietà e i costrutti forniti possano dipendere dall'uso dei flag di funzionalità.

... L'analisi CSS è la stessa. Mangiare il tuo CSS e trasformarlo in CSSOM è piuttosto standard. Sì, anche se Chrome supporta solo i prefissi -webkit- quando Apple e altri browser supportano i prefissi legacy -khtml- e -apple-.

...Layout...posizionamento? È come pane e burro. È lo stesso ovunque, vero? Già, beh! Il layout subpixel e l'aritmetica del layout avanzato fanno parte di WebKit, ma differiscono da porta a porta.

Super.

Quindi è difficile.

Ora proviamo a riassumere cosa ha in comune il mondo WebKit...

Ciò che è comune a ciascuna porta WebKit.

DOM, finestra, documento
Più o meno
CSSOM
Analisi CSS, Proprietà/Valore
differenze nei prefissi del produttore
Analisi dell'HTML e costruzione del DOM
È lo stesso se dimentichiamo i componenti Web.
Disposizione e posizionamento
Flexbox, Float, contesto di formattazione a blocchi... tutto è comune
Strumenti dell'interfaccia utente e strumenti per sviluppatori, come Chrome DevTools, ovvero l'ispettore WebKit.
Anche se dallo scorso aprile Safari utilizza il proprio Safari Inspector, un software closed source non WebKit.
Funzionalità come contenteditable, pushState, File API, la maggior parte di SVG, matematica di trasformazione CSS, API Web Audio, localStorage
Sebbene l'implementazione possa variare. Ciascuna porta può utilizzare il proprio sistema di archiviazione per localStorage e può utilizzare un'API audio diversa per l'API Web Audio.

La situazione sta diventando un po' confusa, quindi proviamo a osservare alcune differenze. Ora, cosa non è comune ai port WebKit:

Tutto ciò che riguarda la GPU
- Trasformazione 3D
-WebGL
- Decodifica video
Rendering 2D sullo schermo
- Tecnologie anti-aliasing
- Rendering dei gradienti SVG e CSS
Rendering e sillabazione del testo
Tecnologie di rete (SPDY, pre-rendering, trasporto WebSocket)
Motore JavaScript
- Il motore JavaScriptCore si trova nel repository WebKit. Ma ci sono collegamenti in WebKit sia per questo che per V8.
Elementi del modulo di rendering
Comportamento dei tag video e audio e supporto dei codec
Decodifica delle immagini
Navigazione avanti/indietro
- Parte pushState()
Funzionalità SSL come Strict Transport Security e Public Key Pin

Diamo un'occhiata ad uno di questi: la grafica 2D dipende dalla porta, utilizziamo librerie completamente diverse per il rendering sullo schermo:

O per entrare più nel dettaglio, una funzionalità aggiunta di recente: CSS.supports() è stata abilitata per tutti i port tranne win e wincairo, che non hanno le funzionalità condizionali css3 abilitate.

Adesso passiamo al tecnico... è tempo di diventare pedanti. Anche quanto detto sopra non è del tutto corretto. Questo è in realtà WebCore, un componente generico. WebCore è una libreria di layout, rendering e DOM per HTML e SVG, ed è fondamentalmente ciò a cui la gente pensa quando dice WebKit. In effetti, "WebKit" è tecnicamente uno strato di collegamenti tra WebCore e "porte", sebbene in una normale conversazione questa distinzione sia in gran parte irrilevante.

Il diagramma dovrebbe aiutare:

Molti dei componenti di WebKit sono commutabili (mostrati in grigio).

Ad esempio, il motore JavaScript di WebKit, JavaScriptCore, è il motore predefinito in WebKit. È originariamente basato su KJS (da KDE) dai tempi in cui WebKit iniziò come fork di KHTML. Allo stesso tempo, il port Chromium passa al motore V8 e utilizza collegamenti DOM esclusivi.

I caratteri e il rendering del testo sono una parte molto importante della piattaforma. Ci sono 2 percorsi separati per il testo in WebKit: Veloce e Difficile. Entrambi richiedono un supporto specifico per la piattaforma (implementato sul lato porta), ma Fast deve solo sapere come eseguire il blit dei glifi (che WebKit memorizza nella cache per la piattaforma), mentre Complex sposta il rendering delle stringhe interamente a livello di piattaforma e dice semplicemente "disegna questo, Per favore."

“WebKit è come un panino. Altrimenti, nel caso di Chromium, è più simile a un taco. Taco delizioso dalle tecnologie web.
Dmitri Glazkov, hacker di Chrome WebKit. Campione dei componenti Web e dominio ombra.

Ora espandiamo l'ambito e osserviamo diverse porte e diversi sottosistemi. Di seguito sono elencate le cinque porte WebKit, nota come il set di strumenti per ciascuna sia diverso nonostante i componenti comuni:

Chrome (OS X) Safari (OS X) QtWebKit Browser Android Chrome per iOSRendering Rete Caratteri JavaScript


Scià	CoreGraphics	QtGui	Stack Android/Skia	CoreGraphics
Stack di rete Chromium	CFNetwork	QtNetwork	Fork dello stack di rete di Chromium	Pila di cromo
CoreText tramite Skia	CoreText	Interni Qt	Pila Android	CoreText
V8	JavaScriptCore	JSC (V8 è usato altrove in Qt)	V8	JavaScriptCore (senza JIT) *

*Nota a piè di pagina su Chrome per iOS. Utilizza UIWebView, come probabilmente saprai. Secondo le capacità di UIWebView, ciò significa che può utilizzare solo lo stesso motore di rendering di Mobile Safari, JavaScriptCore (non V8) e un modello a thread singolo. Tuttavia, parte del codice è preso in prestito da Chromium, come il sottosistema di rete, l'infrastruttura di sincronizzazione dei segnalibri, la omnibox, le metriche e la segnalazione degli arresti anomali. (Inoltre, JavaScript è così raramente un collo di bottiglia sui dispositivi mobili che la mancanza di un compilatore JITting ha un impatto minimo.)

Ok, allora da dove veniamo? E così, tutti i WebKit ora sono completamente diversi. Ho paura.

Non ne vale la pena! La copertura di WebKit dei test "layoutTest" è enorme. (28.000 test all'ultimo conteggio), e non solo per le funzioni esistenti, ma anche per tutte le regressioni trovate. Infatti, ogni volta che impari funzionalità DOM/CSS/HTML-5 nuove o "segrete", le suite di test "layoutTest" di solito hanno un'eccellente demo minima.

Inoltre, il W3C si sta impegnando per standardizzare la suite di test. Ciò significa che possiamo aspettarci che sia i port di WebKit che tutti gli altri browser vengano testati con le stesse suite di test, il che ci porterà a meno stranezze e ad un web più interoperabile. A tutti coloro che si sono impegnati partecipando all'evento Test The Web Forward...grazie!

Opera è appena passata a WebKit. Cosa ne verrà fuori? Robert Nyman e Rob Hawkes hanno già toccato questo argomento, ma aggiungerò che una delle parti importanti dell'annuncio era che Opera si sposterà su Chromium. Ciò significa che WebGL, Canvas, moduli HTML5, implementazione della grafica 2D, tutte queste cose saranno le stesse su Chrome e Opera ora. Stessa API e implementazione di basso livello. Poiché Opera è basato su Chromium, potresti avere la sensazione di ridurre il carico di lavoro per verificare la compatibilità tra Opera e Chrome.
Dovrei anche notare che tutti i browser Opera verranno migrati su Chromium. Cioè, Opera per Windows, Mac, Linux e Opera Mobile (un browser mobile a tutti gli effetti). Anche Opera Mini, il thin client, passerà dall'attuale rendering farm basata su Presto a una basata su Chromium... e una build notturna di WebKit. Cos'è questo? Questo è WebKit, che funziona con lo stesso codice di Safari (anche se alcune librerie interne sono state modificate). È in gran parte gestito da Apple, quindi il comportamento e il set di funzionalità sono coerenti con ciò che troverai in Safari. In molti casi, Apple è conservatrice quando si tratta di includere funzionalità che altri port implementano o stanno sperimentando. Ad ogni modo, per usare un'analogia, pensala come... una build notturna di WebKit per Safari è come Chromium per Chrome.

browser web

sviluppo web

Aggiungere etichette

In questo articolo esamineremo tre browser basati sul popolare motore WebKit. Quando si tratta di scegliere un browser web, gli utenti tendono a guardare ai programmi più famosi: Google Chrome, Opera, Mozilla Firefox, Internet Explorer. Allo stesso tempo, molte persone dimenticano o non sanno che Firefox, Chrome e, più recentemente, Opera sono creati sulla base di progetti open source, il che significa che questi programmi possono essere modificati.

Questa opportunità porta al fatto che molti programmatori hanno creato diversi analoghi dei browser più diffusi che offrono funzionalità piuttosto interessanti. Quindi, diamo un'occhiata a diversi rappresentanti di tale software.

È distribuito gratuitamente, ha un'interfaccia russa, funziona su Windows, Android, Mac, iOS. Questo browser dieci anni fa era conosciuto come MyIE2 ed era un'aggiunta a Internet Explorer, ma da allora sono cambiate molte cose e ora il programma utilizza il motore Webkit per impostazione predefinita.

Nell'ultima versione, la 4a, il browser offre diverse funzioni utili, tra cui la più interessante è la possibilità di archiviare informazioni nel cloud. Ciò ti consente di utilizzare il tuo account nel programma per trasferire informazioni tra diversi dispositivi, che si tratti di un gadget Android, di un prodotto della campagna Apple o di un PC desktop.

L'interfaccia di Maxthon Cloud Browser, sebbene realizzata nello stile di Chrome, ha molte più funzionalità. La barra laterale mostra le icone per accedere alle estensioni. È conveniente che con un clic sia possibile disabilitare o abilitare tutti i componenti aggiuntivi installati e scaricarne di nuovi da un sito Web speciale.

È distribuito gratuitamente, ha un'interfaccia russa e funziona su Windows. Un prodotto di Comodo, meglio conosciuto come sviluppatore di software di sicurezza. Comodo Dragon non è più uno sviluppo, ma una build, poiché la sua funzionalità non è molto diversa da Chrome.

Non ci sono molte differenze rispetto al browser originale e riguardano tutte questioni di sicurezza. La prima differenza fondamentale rispetto a Google Chrome è la vera modalità di navigazione in incognito, Comodo Dragon non utilizza un ID utente univoco e HTTP-REFERRER, che non consente di tracciare l'utente online.

La seconda differenza risiede nel core business di Comodo: la sicurezza degli utenti. Presuppone la presenza di propri server DNS sicuri per la trasmissione del traffico. Inoltre, su richiesta dell'utente, il traffico può attraversarli non solo da Dragon, ma anche da tutte le altre applicazioni. I server DNS sicuri bloccano automaticamente l'accesso ai siti che sono stati contrassegnati come non attendibili dalla rete di rilevamento delle minacce web proprietaria di Comodo.

È distribuito gratuitamente, ha un'interfaccia russa e funziona su Windows. "Yandex.Browser" è un browser recentemente rilasciato basato su Chromium della società russa Yandex. In questo prodotto, gli sviluppatori hanno semplicemente aggiunto i servizi Yandex al pannello dei collegamenti rapidi. Anche la modalità “Turbo”, che si trova in Opera, è stata aggiunta e migliorata. Nel complesso, non è un brutto browser rivolto agli utenti Yandex.

Android e iPhone: guerre tra browser

Parte 1. WebKit in soccorso

Sviluppo di un'applicazione browser responsabile del monitoraggio dello stato della rete

Serie di contenuti:

In totale, le piattaforme iPhone e Android hanno più di 100.000 applicazioni disponibili per il download da una varietà di fonti. Si tratta di applicazioni “native”, ovvero applicazioni sviluppate e assemblate utilizzando l'SDK appropriato e quindi installate su un dispositivo mobile. Tali applicazioni "native" consentono di implementare in modo efficace le capacità tecniche di un dispositivo mobile, incluso il supporto per reti wireless, Bluetooth e archiviazione dati, funzioni di accelerometro o bussola e altre meraviglie e innovazioni tecnologiche che rendono i dispositivi mobili così attraenti per gli utenti. La popolarità delle applicazioni “native” per le piattaforme iPhone e Android è estremamente elevata, ma inoltre i dispositivi mobili offrono ampie opportunità per lo sviluppo di applicazioni Web. Le tecnologie mobili hanno da tempo abbandonato l'infanzia e con esse Internet mobile ha raggiunto una certa maturità.

Questo articolo è il primo di una serie in due parti sullo sviluppo di app browser per iPhone e Android. Lo scopo di questa serie è introdurre il lettore ai principi di base per creare le proprie applicazioni Web mobili. Le funzionalità delle applicazioni mobili non si limitano all'esecuzione di un sito Web su un dispositivo mobile. Esamineremo le tecnologie e gli approcci di base utilizzati nello sviluppo di applicazioni mobili, che consentono di distinguere questa sezione dello sviluppo del software in una disciplina indipendente separata.

La popolarità della piattaforma Web è spiegata dal fatto che il suo utilizzo consente di risolvere molti problemi che tradizionalmente sono stati la rovina degli sviluppatori e degli amministratori di sistema. Tra loro:

Problemi di installazione: l'installazione delle applicazioni Web è semplice: basta installarle o copiarle sul server e indicare ai client a quale URL puntare nel browser.
Problemi di scalabilità: le applicazioni Web si adattano facilmente a un pool di server in un data center ad alte prestazioni e per servire le applicazioni vengono utilizzati strumenti di gestione del sito Web già pronti.
Problemi di archiviazione e ripristino dei dati: le applicazioni Web utilizzano l'archiviazione centralizzata dei dati, semplificando così l'attività di ripristino in caso di guasti.
Considerazioni sull'interfaccia utente: la combinazione di HTML, fogli di stile a cascata (CSS), JavaScript e grafica consente di creare un'interfaccia utente ricca che è significativamente superiore in termini di funzionalità e aspetto alle interfacce sviluppate utilizzando SDK nativi. Questi ultimi, di norma, non sono in grado di fornire un vero e proprio effetto di presenza per le applicazioni di gioco e non garantiscono la funzionalità necessaria per i terminali di informazione interattivi.
Facilità d'uso: la maggior parte delle applicazioni richiede elementi dell'interfaccia utente semplici e facili da usare, che consentano di eseguire facilmente le operazioni quotidiane.

L'aspetto più interessante del modello di distribuzione delle applicazioni Internet è che consente al software di diventare una sorta di servizio in abbonamento, un modo reciprocamente vantaggioso per fornire software. "Come?" - tu chiedi. Diamo un'occhiata a questo problema in modo più dettagliato.

Il modello di distribuzione del software basato sul Web consente ai clienti di provare il prodotto prima dell'acquisto con un rischio minimo e ad un prezzo minimo. Se al cliente è piaciuta la versione di prova, tutto ciò che gli è richiesto per utilizzare ulteriormente il prodotto software è pagare l'acquisto con carta di credito (o tramite PayPal). Inoltre, il modello SaaS (Software as a Service) offre agli utenti un modo conveniente ed economico per acquistare software senza costi iniziali significativi, garantendo un ritorno sull'investimento entro il primo mese di utilizzo anziché in un lontano futuro.

Il fatto è che praticamente non c'era supporto per i browser Web sui dispositivi mobili. La situazione è cambiata radicalmente con l'avvento della tecnologia chiamata WebKit, che ha preso con sicurezza il suo posto nel campo dei dispositivi mobili grazie all'iPhone.

In pochi anni la piattaforma iPhone è diventata il client Web numero uno al mondo. Perché? Perché WebKit, abbinato a una connessione Internet affidabile, ha reso possibile l'utilizzo dei servizi Web sui dispositivi mobili in modo molto più efficiente rispetto a qualsiasi altro browser moderno. Anche altri attori nel mercato dei dispositivi mobili hanno notato la nuova tecnologia e l'intero mercato può ora essere suddiviso in aziende che utilizzano WebKit, aziende che utilizzeranno WebKit e aziende che inventano scuse per non utilizzare WebKit. .

Allora, cos'è WebKit?

WebKit e HTML5

WebKit è un motore browser utilizzato per supportare sia il browser Mobile Safari sulla piattaforma iPhone che il browser sulla piattaforma Android. Naturalmente WebKit viene utilizzato su altri dispositivi mobili, ma ai fini di questo articolo ci limiteremo a considerare le piattaforme iPhone e Android.

WebKit è un progetto open source che nasce dallo sviluppo del K Desktop Environment (KDE). Le moderne applicazioni Web per dispositivi mobili devono la loro nascita al progetto WebKit. Le caratteristiche tecnologiche e di design di un dispositivo mobile giocano sicuramente un ruolo importante, ma gli utenti mobili sono interessati soprattutto ai contenuti. Se un dispositivo mobile fornisce l'accesso solo a una piccola parte dei contenuti Internet, difficilmente riuscirà ad arrivare in cima alla lista dei dispositivi più popolari.

La maggior parte di noi preferisce vivere una vita appagante: se apriamo un sito Web su un laptop mentre siamo seduti a casa, ci aspettiamo di vedere lo stesso contenuto quando apriamo quel sito mentre siamo seduti in treno. Il contenuto è il problema principale delle applicazioni mobili. Non importa dove siamo o cosa facciamo, abbiamo bisogno di accedere ai dati che ci interessano. La tecnologia WebKit fornisce contenuti avanzati sulle piattaforme iPhone e Android.

Vale la pena notare che WebKit viene utilizzato anche su computer desktop, come il browser Safari, che è il browser principale della piattaforma Mac OS X. Indipendentemente dal fatto che si tratti della versione desktop o del motore browser per iPhone o Android, WebKit rimane la tecnologia più avanzata disponibile, che supporta HTML e CSS. Infatti, WebKit supporta stili CSS che non sono ancora renderizzati dai browser su altri motori, ad esempio una serie di proprietà definite dalle specifiche HTML5.

HTML5 è un insieme di specifiche tecniche preliminari che definiscono le tecnologie basate su browser come l'archiviazione dei dati lato client con supporto SQL, spostamenti, trasformazioni e così via. La specifica HTML5 è ancora in fase di sviluppo, ma una volta che i principi di base saranno chiaramente definiti e implementati nei browser della maggior parte delle piattaforme, gli umili inizi delle applicazioni Web diventeranno un ricordo del passato. Lo sviluppo di applicazioni Web occuperà un segmento significativo del settore dello sviluppo software e non stiamo parlando solo di applicazioni per browser desktop, ma anche per browser mobili. Le applicazioni mobili si trasformeranno da un sottoprodotto nel prodotto principale nel mercato delle applicazioni Web.

Caratteristiche di progettazione dello sviluppo di applicazioni web mobili

Se decidi di padroneggiare le tecnologie di sviluppo Web, hai a disposizione una scelta molto limitata di strumenti. Innanzitutto l'applicazione può essere creata direttamente sul server come file contenente codice HTML, CSS e JavaScript. In questo caso, il contenuto HTML può essere fornito sotto forma di file HTML statici, oppure può essere generato dinamicamente attraverso l'uso di diverse tecnologie che lavorano lato server, come ad esempio PHP, ASP.NET, Java Servlet, ecc. In ogni caso, ai fini di questo articolo, tutto si riduce al codice HTML e il punto più importante per noi qui è che la tecnologia WebKit consente ai browser di eseguire il rendering dell'HTML sui dispositivi mobili.

Per eseguire un'applicazione Web su un dispositivo mobile (iPhone o Android), l'utente deve avviare un browser e inserire l'URL del servizio corrispondente, ad esempio: http://yourcompanyname.com/applicationurl.

Allo stesso tempo, la gamma di applicazioni Web mobili proposte è piuttosto ampia: da un sito Web standard a un'applicazione Web mobile sviluppata appositamente per una specifica piattaforma mobile.

Visualizzazione di siti standard

Il motore WebKit, combinato con l'interfaccia utente intuitiva e facile da usare delle piattaforme iPhone e Android, ti consente di visualizzare quasi tutti i siti Web sul tuo dispositivo mobile. Le pagine Web vengono visualizzate in modo abbastanza corretto, a differenza della generazione precedente di browser mobili, che trasferivano frammenti di contenuto in modo casuale o non li visualizzavano affatto. Quando le pagine vengono caricate in un browser abilitato per WebKit, il contenuto della pagina tende a ridimensionarsi. In questo caso, la scala viene selezionata in modo tale che l'intera pagina si adatti allo schermo, anche se in una forma notevolmente ridotta, spesso illeggibile, come mostrato nella Figura 1. Tuttavia, la pagina può essere fatta scorrere, ingrandita, spostata, fornendo un comodo accesso a tutti gli elementi di contenuto. Per impostazione predefinita, il browser utilizza una finestra larga 980 pixel.

Sebbene la visualizzazione completa di una pagina Web in una finestra del browser rappresenti un miglioramento significativo rispetto all'esperienza dei browser della generazione precedente, le funzionalità delle moderne tecnologie mobili non si limitano a questo.

Pagine Web progettate pensando ai dispositivi mobili

Se desideri che la tua pagina Web sia accessibile non solo agli utenti Web normali, ma anche agli utenti mobili, ci sono alcune altre opzioni da considerare per ottimizzare le applicazioni Web mobili.

Sebbene WebKit consenta la corretta visualizzazione di una pagina Web sullo schermo di un dispositivo mobile, esistono alcune differenze tra i dispositivi basati su mouse, come laptop o computer desktop, e i dispositivi touch, come iPhone o smartphone Android. I dispositivi touch si differenziano per le dimensioni fisiche dell'area “click”, per la mancanza di una funzione per posizionare il cursore su qualsiasi elemento e per una diversa sequenza di eventi. Pertanto, se desideri creare un sito web che sia conveniente sia per gli utenti abituali che per quelli mobili, devi considerare le seguenti funzionalità dei dispositivi mobili:

I browser iPhone e Android sono in grado di eseguire il rendering di un'intera pagina Web in una forma abbastanza leggibile: la qualità di rendering di questi browser è molto superiore a quella dei browser mobili standard, quindi non avere fretta di semplificare la progettazione del tuo sito.
La dimensione della punta delle dita è significativamente maggiore della dimensione del puntatore del mouse. Prendi in considerazione questo fattore quando sviluppi gli elementi di navigazione del sito. Non posizionare i collegamenti troppo vicini tra loro, altrimenti l'utente non sarà in grado di fare clic su un collegamento senza passare a quello successivo.
Gli elementi al passaggio del mouse non funzioneranno sui dispositivi mobili. L'utente semplicemente non può “puntare” il dito su qualsiasi elemento allo stesso modo del cursore del mouse.
Gli eventi definiti tenendo premuto il pulsante del mouse, trascinando il mouse, ecc. vengono implementati in modo diverso sui touch screen. Alcuni di questi eventi potrebbero funzionare anche sui dispositivi mobili, ma in generale non dovresti aspettarti che il browser mobile e il browser desktop eseguano la stessa sequenza di azioni.

Una discussione dettagliata di questi aspetti può essere trovata nell'articolo " iPhone in azione"(vedi sezione). Nel nostro articolo ci limiteremo a considerare i vantaggi di WebKit e non i suoi svantaggi.

Diamo un'occhiata al problema più ovvio che gli utenti iPhone o Android devono affrontare quando accedono ai siti Web: dimensioni limitate dello schermo. Infatti, la dimensione dello schermo di un moderno dispositivo mobile è 320x480 o 480x320, a condizione che l'utente preferisca visualizzare i contenuti Web in una configurazione orizzontale. Come puoi vedere dalla Figura 1, WebKit è in grado di visualizzare correttamente una pagina Web progettata per computer desktop standard. Tuttavia, quando si ridimensiona una pagina Web, il testo potrebbe diventare troppo piccolo per essere letto, quindi l'utente deve scorrere, eseguire la panoramica e lo zoom prima di poter leggere il testo. Come affrontare questa limitazione?

Il modo più semplice per creare una pagina che venga visualizzata ugualmente bene nella finestra di un browser mobile e in una finestra di browser desktop è utilizzare un meta tag speciale vista.

Un meta tag è un tag HTML inserito nella testa di un documento HTML. L'esempio più semplice di utilizzo del tag viewport è simile al seguente: . Aggiungendo questo meta tag a una pagina HTML, la sua visualizzazione nella finestra del browser mobile viene ridimensionata nel modo più ottimale (vedere Figura 2). I browser che non supportano il viewport ignorano semplicemente questo tag.

In alcuni casi, è utile definire in anticipo i parametri di ridimensionamento della finestra, come mostrato nella Figura 3.

Per definire opzioni di zoom specifiche, specificare il valore esatto dell'attributo content del tag viewport: meta. Modificando il valore del parametro scala iniziale è possibile ridurre o ingrandire l'immagine. Per le piattaforme iPhone e Android è preferibile utilizzare valori compresi tra 1.0 e 1.3. Il meta tag viewport supporta anche lo zoom minimo e massimo, che consente di limitare la capacità dell'utente di modificare lo zoom della pagina durante il caricamento.

Mentre le caratteristiche del design dell'iPhone, in particolare la dimensione dello schermo 320x480, sono rimaste praticamente invariate dalla sua introduzione, i parametri dei dispositivi sulla piattaforma Android hanno una gamma piuttosto ampia, poiché i dispositivi mobili su questa piattaforma sono prodotti da diversi produttori e sono destinato ad un'ampia varietà di gruppi di utenti. Pertanto, se desideri che la tua applicazione Web sia apprezzata dagli utenti mobili, dovresti tenere in considerazione le possibili differenze nelle dimensioni dello schermo, nella risoluzione e nelle caratteristiche di progettazione dei dispositivi Android.

L'esperienza ha dimostrato che oltre alle differenze di progettazione esistenti tra i diversi dispositivi mobili Android, il software Android stesso tenta di adattare le impostazioni della pagina Web caricata in base alle proprietà del browser del dispositivo mobile. Oltre alla stabilità, la piattaforma Android ha una serie di caratteristiche e capacità in continua evoluzione. Le impostazioni specifiche del tuo dispositivo Android saranno probabilmente diverse da quelle dell'ambiente di sviluppo, a seconda della versione dell'SDK e del produttore del dispositivo. La Figura 4 mostra la schermata di configurazione del browser nell'emulatore Android V1.6. Le impostazioni dello schermo offrono all'utente la possibilità di determinare il livello di ridimensionamento dell'immagine sullo schermo (lontano, vicino, medio) o selezionare la modalità di ridimensionamento automatico della pagina.

Nel mondo dei dispositivi mobili, la cosa più costante è il cambiamento, quindi bisogna tenere conto dello sviluppo e del rinnovamento del mercato del software mobile. Ad esempio, le impostazioni del browser Sprint Hero includono una serie di opzioni completamente diverse dalle impostazioni standard utilizzate durante il caricamento di una pagina Web. Il browser Hero è costruito sulla piattaforma Android V1.5 utilizzando una serie di modifiche apportate da HTC. Fortunatamente, l'utilizzo del meta tag viewport ignorerà le impostazioni specifiche di Hero.

Finora abbiamo visto che WebKit fa un buon lavoro nel caricare una pagina Web, anche se in una forma notevolmente ridotta e di difficile lettura. Abbiamo quindi esteso il controllo su come la pagina viene visualizzata sullo schermo di un dispositivo mobile attraverso l'uso del meta tag viewport. La pagina visualizzata è ora molto più facile da leggere e navigare. Ma questo non è ancora sufficiente affinché la nostra pagina appaia e funzioni come un’applicazione Web.

Realizzato per dispositivi mobili

Passiamo a considerare le caratteristiche di design di una pagina Web destinata ad un pubblico mobile. Come esempio specifico, consideriamo la pagina di registrazione per il servizio di posta elettronica di Google GMail.

Ecco come appare la pagina in una finestra del browser desktop:

Nella finestra del browser desktop, il contenuto informativo viene visualizzato sul lato sinistro e la finestra di registrazione stessa si trova nel pannello destro. Nella finestra del browser mobile, la stessa pagina ha un aspetto completamente diverso.

La pagina mostrata nella Figura 6 è sicuramente progettata per gli utenti mobili. Lo schermo visualizza solo gli elementi della pagina di cui l'utente ha bisogno per il lavoro successivo: non sono necessari ulteriori operazioni di scorrimento, panoramica o zoom.

Ora diamo un'occhiata alla finestra di visualizzazione della posta elettronica della versione mobile di Gmail. Poiché lo spazio sullo schermo disponibile per l'applicazione è molto limitato, il visualizzatore di messaggi dispone di pulsanti ed elementi di navigazione aggiuntivi. In questo caso gli elementi di navigazione visualizzati si sovrappongono alla finestra di visualizzazione dei messaggi. Inoltre, non utilizzare troppi frame o div scorrevoli se puoi evitarlo. La versione mobile di Gmail risolve questo problema utilizzando un menu a comparsa che appare non appena l'utente finisce di scorrere la pagina. Il menu a comparsa contiene 3 pulsanti: Archivia, Elimina e Altro. Quando si fa clic sul pulsante Altro, vengono visualizzate voci di menu aggiuntive (vedere Figura 7).

Questa è davvero un'applicazione progettata per i dispositivi mobili.

Va tenuto presente che non vogliamo impoverire deliberatamente il design e ridurre l'esperienza degli utenti mobili che hanno sviluppato browser multifunzionali per le piattaforme iPhone e Android. Da questo punto di vista è utile prestare attenzione all'elemento visualizzato in fondo alla pagina Gmail (vedi Figura 8):

Se l'utente preferisce le funzionalità avanzate della versione desktop, offrigli la possibilità di scaricare la versione appropriata della pagina.

Consideriamo ora il caso in cui desideri creare un'applicazione che utilizzi le tecnologie Web, ma assomigli ad un'applicazione mobile nativa.

Contenuti specifici della piattaforma

Il passo successivo è sviluppare contenuti specifici per una particolare piattaforma mobile. Ciò definisce il formato e l'interfaccia della pagina in modo che la pagina risultante assomigli a un'applicazione nativa per una piattaforma specifica, piuttosto che a un sito Web pubblico standard. Cosa intendiamo per applicazione "nativa"?

Prima di addentrarci nella discussione su come rendere un'applicazione Web il più simile possibile a un'applicazione nativa per una piattaforma specifica, mettiamo da parte le caratteristiche comuni dei browser iPhone e Android e tocchiamo brevemente le differenze visive che esistono tra queste piattaforme .

Le applicazioni iPhone hanno un aspetto e un'interfaccia specifici. Mostra a qualcuno uno screenshot di un iPhone e, a meno che non sia appena caduto dalla luna l'altro giorno, quasi sicuramente dirà immediatamente che è un iPhone. Mostra alla stessa persona uno screenshot di un dispositivo mobile Android e la risposta non sarà più così chiara. Qual è il motivo? Ci sono diverse possibili spiegazioni. In primo luogo, l'iPhone è apparso sul mercato molto prima dei dispositivi basati su Android ed è riuscito a conquistare un numero enorme di fan. Pensa alle persone in fila per pagare un sacco di soldi per le funzionalità limitate dell'iPhone V1. Che ti piaccia o meno l'iPhone, questo prodotto Apple è attualmente il leader del mercato. E che dire di Android?

La piattaforma Android è un prodotto relativamente nuovo e per molti aspetti funge da antipode dell'iPhone, poiché è progettata principalmente per la comunità aperta. La piattaforma Android è utilizzata in un'ampia varietà di dispositivi (telefoni e altri elettrodomestici). Per semplicità di trattazione, in questo articolo ci limiteremo all'utilizzo di Android nei telefoni cellulari.

Nel corso del tempo, il numero di dispositivi Android nel mondo supererà il numero di iPhone. Questo perché i dispositivi Android sono realizzati da diverse aziende e saranno supportati da un'ampia varietà di reti dati. Con un numero così significativo di attori nel mercato dei dispositivi mobili Android, dovremmo sicuramente aspettarci una certa frammentazione del mercato in base all'aspetto e ai parametri dei dispositivi. Questa tendenza può essere vista nell'interfaccia SenseUI di HTC. Questo aspetto accattivante non è supportato dall'SDK Android sottostante e non è compatibile con altri dispositivi Android. Motorola, Google e Verizon hanno unito le forze per sviluppare un nuovo dispositivo DROID basato su Android. Questo è il primo prodotto commerciale sulla piattaforma Android 2.0.

Confronta la varietà di sistemi Android con l'aspetto coerente dell'iPhone. L'iPhone è una proprietà particolarmente preziosa di Apple. L'aspetto delle app per iPhone può cambiare leggermente nel tempo, ma è improbabile che questi piccoli cambiamenti siano paragonabili alle varie versioni dei sistemi Android, che sono numerose anche adesso che la piattaforma è agli albori.

Quindi, cosa è necessario fare per avvicinare il più possibile l'aspetto e l'interfaccia dell'applicazione ai programmi "nativi"?

Se avessimo affrontato questa sfida prima dell’avvento del Web 2.0, sarebbe stato davvero un problema serio. I primi tentativi di supportare più browser client (mobili e desktop) si basavano su diversi approcci, ad esempio:

Sviluppo di siti completamente paralleli
Generazione di contenuto dinamico in base al parametro userAgent
Utilizzando server proxy che potrebbero trasformare i contenuti a seconda di ciascun dispositivo specifico. Una tecnologia simile è stata utilizzata con successo da RIM per fornire l’accesso alla posta elettronica dal dispositivo mobile di un cliente.

Tali approcci possono essere abbastanza accettabili nei casi in cui lo sviluppo viene portato avanti da team numerosi e ben finanziati. Cosa dovrebbe fare il resto del mondo? Non tutti dispongono di risorse finanziarie significative, specialisti altamente qualificati e tempo illimitato per attuare tali strategie. Inoltre, come abbiamo già notato, l'Internet mobile della precedente generazione di browser non può essere definita comoda o popolare da usare, quindi in ogni caso non vale la pena soffermarsi su metodi e approcci obsoleti.

Fortunatamente, non dovremo farlo. Nell'era del WebKit e dei CSS, le differenze nell'aspetto e nell'interfaccia dei diversi dispositivi mobili possono essere superate utilizzando fogli di stile e media query, che consentono di utilizzare stili diversi a seconda del tipo specifico di dispositivo. La tecnologia delle query multimediali consente di ottenere informazioni sul cliente. Tradizionalmente, il browser invia al server un valore userAgent, che consente al server di identificare il browser specifico e determinare il contenuto che deve essere inviato al client. Utilizzando una media query, il browser sceglie lo stile della pagina in base alle sue capacità. L'esempio seguente mostra la selezione di un foglio di stile progettato per gli smartphone: . E questa query definisce un foglio di stile desktop: .

Internet Explorer V6

Al momento della stesura di questo articolo, Internet Explorer V6 occupava circa il 20-30% del mercato totale dei browser, tuttavia, discutere le funzionalità di IE V6 va oltre lo scopo di questo articolo.

Maggiori informazioni sulle media query possono essere trovate nella bozza delle specifiche (vedi sezione).

Diamo un'occhiata a un esempio di utilizzo delle query multimediali per sviluppare un'applicazione che visualizzi lo stato dei server di rete.

Programma di monitoraggio della rete

Lo scopo di questa applicazione è monitorare il funzionamento di diversi server. Gli sviluppatori di software indipendenti spesso devono supportare più applicazioni su più server. Se sei stato coinvolto nello sviluppo di software per un periodo significativo, probabilmente hai già incontrato diversi tipi di server e diversi tipi di applicazioni. Tutto ciò significa che è del tutto possibile che non sarai in grado di utilizzare un unico strumento per monitorare le prestazioni di tutte le applicazioni necessarie. In questo caso ha senso utilizzare un'applicazione per il monitoraggio della rete mobile (netmon). L'applicazione fornisce tutte le funzionalità richieste, pur rimanendo flessibile e di facile accesso da un dispositivo mobile.

L'applicazione netmon include un elenco di server che devono essere monitorati. Per ciascun server vengono raccolti indicatori chiave di prestazione (KPI). Gli indicatori chiave di prestazione sono uno strumento primario che gli studenti MBA utilizzano da anni per valutare lo stato attuale di un'impresa. Dal punto di vista dell'hosting di applicazioni Web, i seguenti indicatori possono essere utilizzati come KPI:

Numero di transazioni nell'ultimo periodo di tempo
- Ordini
- Richieste di cataloghi
- E-mail
- Numero di visualizzazioni di pagina
Tempo trascorso dall'ultima transazione
- Ordine
- Scambio elettronico di dati
- Messaggi da un partner commerciale
- Caricamento di un file dal fornitore tramite FTP
La banca dati è disponibile?
Data dell'ultimo backup
Importo medio dell'ordine (in dollari)
Quantità di spazio libero su disco
Larghezza di banda per l'ultima ora, giorno, mese

Le metriche di cui sopra e altri parametri operativi simili consentono di valutare lo stato di salute di un sistema o di un'applicazione specifica. Ad esempio, durante le festività natalizie esaminiamo il numero di ordini effettuati su alcuni dei nostri siti. Se i dati non mostrano un aumento stabile del numero di ordini ogni ora, effettuiamo un'analisi più dettagliata della situazione.

Poiché ogni applicazione ha i propri requisiti e risorse, netmon deve essere sufficientemente flessibile da soddisfare le esigenze di ciascuna applicazione. Per fornire questo livello di flessibilità, iniziamo definendo la struttura dati più generale per tenere conto dei parametri di stato di ciascun sistema. Nella Parte 2 esamineremo più da vicino la provenienza di questi dati e come vengono aggiornati. Per ora ci limiteremo alle seguenti informazioni:

Nome del sito
URL del sito (home page)
URL per ottenere aggiornamenti
Stato: OK o no
Riepilogo rapido: una descrizione dello stato del server che sarà OK o conterrà una stringa di testo che indica il problema più grave per quel server
Elementi: questo è un insieme di coppie nome/valore di cui avremo bisogno per passare i valori KPI correnti per il sito corrispondente.

La nostra applicazione visualizzerà gli indicatori di prestazione risultanti in un formato facile da navigare, sfruttando appieno CSS, jQuery e WebKit per attirare l'attenzione dell'utente sulle aree problematiche. Come abbiamo già accennato, l'obiettivo principale nello sviluppo di questa applicazione è la possibilità di eseguirla su iPhone, piattaforma Android e su un computer desktop nel browser Safari.

Sviluppo di applicazioni per il monitoraggio della rete

Le pagine Web moderne devono essere create in una forma dichiarativa che definisca la struttura organizzativa e il contenuto della pagina. Il posizionamento e la formattazione della pagina vengono eseguiti utilizzando i Cascading Style Sheets (CSS) e, nella maggior parte dei casi, JavaScript. In effetti, le librerie JavaScript sono diventate così popolari che il loro utilizzo oggi è la regola piuttosto che l'eccezione. Nell'applicazione discussa in questo articolo, utilizzeremo la popolare libreria JavaScript jQuery. La nostra applicazione funzionerà su iPhone, Android e piattaforme desktop. Verrà utilizzato lo stesso codice HTML e le eventuali differenze necessarie verranno implementate nei fogli di stile. Va notato qui che non abbiamo consapevolmente compiuto alcuno sforzo significativo nella progettazione di un aspetto attraente per l'applicazione. Inoltre, come sfondo sono stati scelti deliberatamente colori sorprendenti che non si armonizzano tra loro per attirare ulteriore attenzione del lettore sull'organizzazione dei fogli di stile. Nella Parte 2 miglioreremo leggermente l'aspetto dell'applicazione, ma per ora il codice HTML è simile a quello mostrato nel Listato 1.

Listato 1. Codice HTML dell'applicazione if (navigator.userAgent.indexOf("iPhone") != -1) ( document.write(""); ) else if (navigator.userAgent.indexOf("Android") != -1 ) ( document.write(""); ) else ( document.write(""); ) funzione setupTestData() ( try ( netmon.initialize(); if (netmon.resources.length > 0) ( jQuery.each( netmon .resources,funzione (indice, valore) ( $("#mainContent").append(netmon.render(indice,valore)); )); $(".serverentry").click (funzione() ( $(this ).find(".serveritems").toggle();)); $(".serveritems").hide(); ) ) catch (e) ( alert(e); ) ) Le mie risorse di rete Le mie Server Il mio agente utente

Un rapido sguardo al codice HTML proposto rivela le seguenti caratteristiche principali:

Il codice utilizza due file JavaScript esterni: un file di libreria jQuery e un file di supporto per la nostra applicazione.
Il codice utilizza il meta tag viewport per ridimensionare il contenuto visualizzato.
Il foglio di stile principale è definito dal file netmon.css.
Il parametro userAgent viene utilizzato per definire il foglio di stile ausiliario. A seconda del suo valore, il foglio di stile verrà caricato per iPhone, Android o browser desktop.
Il processo di caricamento della pagina utilizza jQuery e una funzione di supporto definita nel file netmon.js per visualizzare i dati.
Il codice della pagina principale utilizza diversi tag div.
Infine, il codice contiene un collegamento a una pagina che mostra la stringa userAgent. Questo collegamento non ha nulla a che fare con il funzionamento dell'applicazione e viene utilizzato solo a scopo dimostrativo.

Prima di entrare nei dettagli dei fogli di stile e del file netmon.js che definiscono effettivamente il funzionamento di base dell'applicazione, diamo un'occhiata alla nostra applicazione nel suo stato attuale. Tieni presente ancora una volta che stiamo utilizzando tre diversi fogli di stile: uno per ciascuna delle tre piattaforme supportate. Per rendere più visivo il processo di sviluppo dell'applicazione, ogni tabella definisce il proprio colore di sfondo. Nella Figura 9, la nostra pagina è aperta nel browser Desktop Safari e ha uno sfondo blu.

La Figura 11 mostra l'aspetto dell'applicazione nella finestra del browser dell'iPhone (il colore dello sfondo è verde).

Il foglio di stile principale memorizzato nel file netmon.js è mostrato nel Listato 2.

Listato 2. Corpo del foglio di stile principale ( colore: #888888; famiglia di caratteri: Helvetica; dimensione carattere: 14px; margine: 0px; riempimento: 0; ) .details ( margine: 0px; riempimento: 0px; colore sfondo: bianco ; bordo: solido; larghezza bordo: 1px; -webkit-border-raggio-alto-sinistro: 8px; -webkit-border-raggio-alto-destra: 8px; -webkit-border-raggio-basso-sinistra: 8px; - webkit-border-bottom-right-radius: 8px; ) .OK ( color: #000000; ) .BAD ( color: #ff0000; ) .odd ( background-image: -webkit-gradient(linear, left top, right bottom ,from(#ccc),to(#999)); ) .even (immagine-di-sfondo: -webkit-gradient(lineare, in alto a sinistra, in basso a destra,da(#999),a(#ccc)); ) . serverentry a ( float: destra; colore: #ffffff; ) .serveritems( colore: #000; ) #header h1 ( margine: 0; riempimento: 0; allineamento testo: centro; colore: #000; )

L'utilizzo di un foglio di stile diverso per ciascuna piattaforma consente di realizzare le seguenti attività:

Cambia lo schema dei colori della pagina. Ciò consente, in primo luogo, di dimostrare chiaramente il ruolo del foglio di stile e, in secondo luogo, di mostrare quanto sia semplice selezionare il foglio di stile desiderato a seconda del valore del parametro userAgent.

Imposta dimensioni dei caratteri diverse per piattaforme mobili e desktop.

Controlla le funzioni WebKit pertinenti. Ciò farebbe una differenza significativa se l'applicazione fosse eseguita in un browser senza supporto WebKit, come Firefox.

Il Listato 3 mostra il codice per il file iphone.css.

Listato 3. Corpo del file iphone.css ( background-color: #00ff00; ) .serverentry ( -webkit-border-top-left-radius: 8px; -webkit-border-top-right-radius: 8px; -webkit-border -raggio-inferiore-sinistra: 8px; -webkit-border-raggio-inferiore-destra: 8px; ) .name ( dimensione carattere: 2em; ) .summary( dimensione carattere: 1,5em; ) .serverentry a ( carattere- dimensione: 1,5 em; )

Come possiamo vedere, il colore di sfondo del corpo del tag è verde (#00ff00) e la dimensione del carattere è stata regolata per facilitarne la lettura sullo schermo di un dispositivo mobile. Infine, diamo un'occhiata al file netmon.js, che definisce un elenco di server e una funzione che stampa i dati di ciascun server (utilizzata nel Listato 4). Parte del codice del file è stata omessa per brevità; il suo testo completo è disponibile nella sezione ).

Listato 4. File Netmon.js var netmon = ( inizializza: funzione () ( ), risorse: [ ( nome: "msiservices.com", homeurl: "http://msiservices.com", pingurl: "http:// msiservices.com/netmon.php", stato: "OK", riepilogo: "OK", elementi: [ (nome: "DiskSpace", valore: "22.13 GB"), (nome: "Database Up?", valore: "Sì") ] ), (nome: "server 2", homeurl: "http://someurl", pingurl: "http://someurl/netmon.jsp", stato: "OK", riepilogo: "OK" , elementi: [ (nome: "DiskSpace", valore: "100,8 GB"), (nome: "Database Up?", valore: "Yes") ] ), // voci aggiuntive ritagliate per brevità ], render: function( indice,itm) ( try ( var ret = "; ret += ""; ret += "" + itm.nome + " Mostra
"; if (itm.status != "OK") ( ret += "-" + itm.summary + "
"; ) ret += ""; jQuery.each(itm.items,funzione (j,itemdetail) ( ret += ">" + itemdetail.name + "=" + itemdetail.value + "
"; )); ret += ""; ret += ""; return ret; ) catch (e) ( return "Errore nel rendering dell'elemento [" + itm.name + "] " + e + ""; ) ) ) ;

Se la barra di stato di un server non è OK, la voce del server corrispondente viene visualizzata in rosso, come si può vedere dalla definizione della classe nel file CSS. Inoltre, se il controllo dello stato del server rivela eventuali problemi (lo stato non è OK), viene inoltre visualizzata una breve descrizione del problema. Le Figure 9-11 mostrano che il Server 4 sta esaurendo lo spazio libero su disco. Quando si fa clic sulla riga di questo server, sullo schermo verrà visualizzato un messaggio dettagliato sul problema (vedere Figura 12).

Facendo clic sul collegamento mostra a destra del nome di un server si apre la home page di quel server. Avere un collegamento del genere è molto comodo per due motivi: in primo luogo, ti eviterà la spiacevole necessità di memorizzare l'URL di ciascun server e, in secondo luogo, ti eviterà la necessità ancora più spiacevole di inserire questo URL dalla tastiera del il tuo dispositivo mobile (anche quello più comodo).

Quindi, se riusciamo a eseguire correttamente netmon su un dispositivo mobile, l'attività di manutenzione dei server non dovrebbe causare alcun problema.

Conclusione

Questo articolo introduce i principi dello sviluppo di applicazioni Web per iPhone e Android utilizzando la tecnologia WebKit. Nella Parte 2 espanderemo le capacità della nostra applicazione aggiungendo funzionalità di aggiornamento dei dati utilizzando le chiamate Ajax.

Traduzione

Un web kit non è una scatola nera. Questa è una scatola bianca. E non solo bianco, ma anche una scatola aperta.
Allora proviamo a capire alcune cose:

Cos'è WebKit?
Cosa non è WebKit?
Come viene utilizzato WebKit dai browser WebKit?
Perché molti WebKit non sono uguali?

Analisi (analisi HTML, XML, CSS, Javascript)
Disposizione
Rendering di testo e grafica
Decodifica delle immagini
Interazioni con GPU
Accesso alla rete
Accelerazione hardware

Quali sono comuni a tutti i browser WebKit? Praticamente solo i primi due.

Ciascuna "porta" WebKit implementa i componenti rimanenti in modo diverso. Scopriamo cosa significa.

Porte WebKit

Ci sono molti "port" di WebKit e io fornisco Ariya Hidayat, hacker e tecnologia WebKit. Il direttore di Sencha ha il diritto di parlare di questo:

Come accennato in precedenza, la CoreGraphics utilizzata è unica per ciascuna porta WebKit. Chrome per Mac, ad esempio, utilizza Skia.

Safari
- Safari per OS X e Safari per Windows sono due porte diverse
- La build notturna di WebKit è una build del "port" del codice sorgente del Mac utilizzato per Safari, solo più recente
Safari sul cellulare
- Sviluppato in una filiale privata, ma è stato successivamente aperto.
- Chrome per iOS (utilizza WebView di Apple; maggiori informazioni sulla differenza più avanti)
Cromo (Cromo)
- Chrome per Android (utilizza direttamente il "port" di Chromium)
- Chromium è anche la base dei browser: Yandex, Sogou e presto Opera.
browser Android
- Utilizza l'ultimo codice sorgente WebKit disponibile al momento del rilascio.
Ancora più porte: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, la porta EFL (Tizen), wxWebKit, WebKitWinCE, ecc.

Innanzitutto, diamo un'occhiata alle funzionalità comuni utilizzate in tutti i browser WebKit:

Sai che è divertente, ho fatto diversi tentativi per scrivere questo paragrafo. E ogni volta i membri del team di Chrome mi correggevano, come vedrai...

Quindi, prima di tutto, WebKit analizza l'HTML allo stesso modo. Bene, tranne che Chromium è l'unico port al momento che include il supporto per i thread per l'analisi HTML.

…Ok, WebKit crea oggetti finestra e documento allo stesso modo per tutti. Vero, sebbene le proprietà e i costrutti forniti possano dipendere dall'uso dei flag di funzionalità.

Super.

Quindi è difficile.

Ora proviamo a riassumere cosa ha in comune il mondo WebKit...

Ciò che è comune a ciascuna porta WebKit.

DOM, finestra, documento
Più o meno
CSSOM
Analisi CSS, Proprietà/Valore
differenze nei prefissi del produttore
Analisi dell'HTML e costruzione del DOM
È lo stesso se dimentichiamo i componenti Web.
Disposizione e posizionamento
Flexbox, Float, contesto di formattazione a blocchi... tutto è comune
Strumenti dell'interfaccia utente e strumenti per sviluppatori, come Chrome DevTools, ovvero l'ispettore WebKit.
Anche se dallo scorso aprile Safari utilizza il proprio Safari Inspector, un software closed source non WebKit.
Funzionalità come contenteditable, pushState, File API, la maggior parte di SVG, matematica di trasformazione CSS, API Web Audio, localStorage
Sebbene l'implementazione possa variare. Ciascuna porta può utilizzare il proprio sistema di archiviazione per localStorage e può utilizzare un'API audio diversa per l'API Web Audio.

La situazione sta diventando un po' confusa, quindi proviamo a osservare alcune differenze. Ora, cosa non è comune ai port WebKit:

Tutto ciò che riguarda la GPU
- Trasformazione 3D
-WebGL
- Decodifica video
Rendering 2D sullo schermo
- Tecnologie anti-aliasing
- Rendering dei gradienti SVG e CSS
Rendering e sillabazione del testo
Tecnologie di rete (SPDY, pre-rendering, trasporto WebSocket)
Motore JavaScript
- Il motore JavaScriptCore si trova nel repository WebKit. Ma ci sono collegamenti in WebKit sia per questo che per V8.
Elementi del modulo di rendering
Comportamento dei tag video e audio e supporto dei codec
Decodifica delle immagini
Navigazione avanti/indietro
- Parte pushState()
Funzionalità SSL come Strict Transport Security e Public Key Pin

Diamo un'occhiata ad uno di questi: la grafica 2D dipende dalla porta, utilizziamo librerie completamente diverse per il rendering sullo schermo:

Il diagramma dovrebbe aiutare:

Molti dei componenti di WebKit sono commutabili (mostrati in grigio).

Chrome (OS X) Safari (OS X) QtWebKit Browser Android Chrome per iOSRendering Rete Caratteri JavaScript


Scià	CoreGraphics	QtGui	Stack Android/Skia	CoreGraphics
Stack di rete Chromium	CFNetwork	QtNetwork	Fork dello stack di rete di Chromium	Pila di cromo
CoreText tramite Skia	CoreText	Interni Qt	Pila Android	CoreText
V8	JavaScriptCore	JSC (V8 è usato altrove in Qt)	V8	JavaScriptCore (senza JIT) *

Ok, allora da dove veniamo? E così, tutti i WebKit ora sono completamente diversi. Ho paura.

Basandosi su questo motore sono stati creati browser come Midori, Maxthon, Konqueror, Arora e altri. Ma non sono solo i browser poco conosciuti a scegliere Webkit. Presentiamo alla vostra attenzione due "giganti" nel mondo dei browser: Safari di Apple e Chrome di Google (questi browser). È improbabile che qualcuno possa sostenere che questi browser abbiano poche funzionalità e una bassa velocità operativa. Oltre ai browser desktop, Webkit è penetrato anche nelle piattaforme mobili, il che conferma ancora una volta i vantaggi del software libero. Lo stesso Safari Mobile, sviluppato per iOS, utilizza con successo questo motore. Anche i browser standard per le piattaforme Android, HP WebOS e Samsung Bada sono basati su Webkit.

È un motore sulla base del quale sono stati sviluppati molti browser. È abbastanza veloce e leggero e gestisce perfettamente tutti gli standard accettati nell'ambiente web.

Con tutto ciò, questo motore è un software distribuito gratuitamente. Questi sono i componenti che gli hanno permesso di diventare molto popolare tra gli sviluppatori di browser.

Storia di Webkit

Forse ti sarai chiesto: “Perché il software libero?” Diamo un'occhiata alla storia della sua creazione. Anche il genitore di Webkit è un motore distribuito gratuitamente, sviluppato per l'ambiente grafico dei sistemi della famiglia Unix. Questo motore si chiama KDE. Nel 1998, un team di programmatori che lavoravano su KDE decisero di rilasciare il proprio browser per questo ambiente grafico.

Un browser di questo tipo è stato rilasciato e nominato dai creatori di Konqueror. Il motore alla base di questo browser si chiamava KHTML. 3 anni dopo, nel 2001, Apple ha deciso di creare il proprio browser, per il quale ha utilizzato i sorgenti KHTML e il motore JavaScript KJS. Come risultato di questa sintesi, il progetto Webkit è stato creato sotto “l’ala” di Apple. Sulla base, all'inizio del 2003, è stata rilasciata la prima versione del browser Apple: .

Anche un altro “mostro” nel mondo dell'informatica, Google, ha preso come base Webkit per creare il proprio browser. E questo è un altro punto a favore del motore. Dato che Google ha deciso che era giusto per loro, questo la dice lunga. Gli stessi sviluppatori hanno affermato che si è deciso di non reinventare la ruota, perché Webkit soddisfa pienamente gli elevati requisiti dell'azienda per il supporto degli standard dell'ambiente web, nonché una velocità di funzionamento piuttosto elevata.

Oggi il motore continua a svilupparsi attivamente e ha grandi prospettive. Ciò non sorprende, perché sia Apple che Google stanno lavorando per migliorarlo. E questo in aggiunta agli sviluppatori ufficiali del motore. A loro volta, hanno dichiarato che stanno lavorando, il cui risultato sarà il rilascio della seconda generazione del loro prodotto, la cui caratteristica distintiva sarà l'architettura integrata di processi separati (oggi questo è implementato solo in).