• Tõlge

Paljude meist arendajate jaoks on WebKit must kast. Me viskame sinna HTML-i, CSS-i, JS-i ja hunniku pilte ning WebKit annab kuidagi... võluväel meile veebilehe, mis näeb välja ja töötab hästi.
Aga tegelikult, kuidas ütleb kolleeg Ilja Grigorik :

Veebikomplekt ei ole must kast. See on valge kast. Ja mitte ainult valge, vaid ka avatud kast.
Niisiis, proovime välja mõelda mõned asjad:

• Mis on WebKit?
• Mis ei ole WebKit?
• Kuidas WebKiti kasutavad WebKiti brauserid?
• Miks paljud WebKitid ei ole samad?

Nüüd, eriti pärast uudist, et Opera läks üle WebKitile, ümbritseb meid palju WebKiti brausereid ning on üsna raske öelda, mis neid ühendab ja kuhu nad oma teed lähevad. Allpool loodan, et püüame sellele probleemile veidi valgust heita. Selle tulemusel saate paremini tuvastada brauseri erinevusi, esitada vead õigele jälgijale ja teha tõhusamalt brauseritevahelist arendust. Standardsed veebibrauseri komponendid Loetleme mõned kaasaegsete brauserite komponendid:

• Parsimine (HTML-i, XML-i, CSS-i, Javascripti sõelumine)
• Paigutus
• Teksti ja graafika renderdamine
• Pildi dekodeerimine
• Koostoimed GPU-ga
• Juurdepääs võrgule
• Riistvaraline kiirendus

Millised neist on kõigi WebKiti brauserite jaoks ühised? Peaaegu ainult kaks esimest.

Iga WebKiti port rakendab ülejäänud komponendid erinevalt. Mõelgem välja, mida see tähendab.

WebKiti pordid

WebKiti porte on palju ja ma pakun Ariya Hidayati, WebKiti häkkerit ja tehnikat. Sencha direktoril on õigus sellest rääkida:

Kõige populaarsem seos WebKiti kontseptsiooniga on tavaliselt Apple'i WebKiti versioon, mis töötab operatsioonisüsteemis Mac OS X (esimene ja algne WebKiti teek). Nagu võite arvata, on erinevad liidesed juurutatud mitmesuguste Mac OS X-i natiivsete teekide abil, peamiselt fokuseeritud komponendis CoreFoundation. Näiteks kui määrate kindla kontuuriraadiusega värvilise lame nupu, teab WebKit, kuhu ja kuidas see nupp joonistada. Samal ajal nupu lõplik renderdus (pikslitena kasutaja monitoril ) langeb CoreGraphicsile.

Nagu ma eespool mainisin, on kasutatav CoreGraphics iga WebKiti pordi jaoks unikaalne. Näiteks Chrome for Mac kasutab Skiat.

Mingil hetkel "portiti" WebKit erinevatele platvormidele, nii lauaarvutitele kui ka mobiilidele. Seda variatsiooni nimetatakse tavaliselt "WebKiti pordiks". Safari Windowsi jaoks "portis Apple WebKiti" iseseisvalt, et Windowsis töötaks, kasutades selle (piiratud juurutusega) CoreFoundationi teeki.

...vaatamata asjaolule, et Windowsi Safari on nüüd surnud. Lisaks sellele oli seal ka palju muid "porte" (vt täielikku loendit). Google on loonud oma Chromiumi pordi ja toetab seda jätkuvalt. Samuti on olemas WebKitGtk, mis põhineb Gtk+-l. Nokia (ja nüüd selle ostnud Trolltech) toetab WebKit Qt porti, mis on muutunud populaarseks QtWebKiti moodulina.
Mõned WebKiti pordid

• Safari
  - Safari for OS X ja Safari for Windows on kaks erinevat porti
  - WebKiti öine ehitamine on Maci lähtekoodi "pordi" järg, mida kasutatakse Safari jaoks, ainult uuem.
• Mobiilne Safari
  - Arendati erafiliaalis, kuid avati hiljem.
  - Chrome iOS-ile (kasutab Apple'i WebView'd; erinevuste kohta lisateavet hiljem)
• Chrome (Chromium)
  - Chrome Androidile (kasutab otse Chromiumi porti)
  - Chromium on ka brauserite alus: Yandex, Sogou ja peagi ka Opera.
• Androidi brauser
  - Kasutab uusimat WebKiti lähtekoodi, mis on avaldamise ajal saadaval.
• Veelgi rohkem porte: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE jne

Erinevad pordid võivad keskenduda erinevatele ülesannetele. Maci pordi fookuses on brauseri ja operatsioonisüsteemi eraldamine ning Obj-C ja C++ sidemete pakkumine renderdusmootori omarakendustesse manustamiseks. Chromiumi pordi fookus on täielikult brauseril. QtWebKit pakub oma porti kasutamiseks koos platvormideülese rakenduste arhitektuuriga renderdusmootorina. Mis on ühine kõigis WebKiti brauserites

Kõigepealt vaatame üldisi funktsioone, mida kasutatakse kõigis WebKiti brauserites:

Teate, et see on naljakas, ma proovisin seda lõiku mitu korda kirjutada. Ja nagu näete, parandasid Chrome'i meeskonna liikmed mind iga kord...

Ja nii, esiteks parsib WebKit HTML-i samal viisil. Noh, välja arvatud see, et Chromium on hetkel ainus port, mis toetab HTML-i sõelumise lõime.

... Olgu, aga pärast HTML-i sõelumist konstrueeritakse DOM-puu samamoodi. Noh, tegelikult on Shadow DOM lubatud ainult Chromiumi pordi jaoks, mis tähendab, et DOM-i konstruktsioon on erinev. Ka kohandatud elementide jaoks.

…Olgu, WebKit loob akna- ja dokumendiobjektid kõigile ühtemoodi. Tõsi, kuigi nende pakutavad omadused ja konstruktsioonid võivad sõltuda funktsioonilippude kasutamisest.

... CSS-i sõelumine on sama. CSS-i söömine ja selle CSSOM-iks muutmine on üsna tavaline. Jah, kuigi Chrome toetab ainult -webkit- eesliiteid, kui Apple ja teised brauserid toetavad pärandprefikseid -khtml- ja -apple-.

...Paigutus...positsioneerimine? See on nagu leib ja või. See on igal pool sama, eks? No juba! Subpikslite paigutus ja rikkaliku paigutuse aritmeetika on WebKiti osa, kuid erinevad porditi.

Super.

Niisiis, see on raske.

Proovime nüüd kokku võtta, mis on WebKiti maailmal ühist...

Mis on ühine iga WebKiti pordi jaoks.

• DOM, aken, dokument
  Rohkem või vähem
• CSSOM
• CSS-i sõelumine, atribuut/väärtus
  erinevused tootja eesliidetes
• HTML-i sõelumine ja DOM-i loomine
  See on sama, kui unustame veebikomponendid.
• Paigutus ja positsioneerimine
  Flexbox, Floats, plokkide vormindamise kontekst... kõik on tavaline
• Kasutajaliidese tööriistad ja arendaja tööriistad, nt Chrome DevTools ehk WebKiti inspektor.
  Kuigi alates eelmise aasta aprillist on Safari kasutanud oma suletud lähtekoodiga mitte-WebKiti Safari Inspectorit.
• Sellised funktsioonid nagu sisu redigeeritav, pushState, faili API, enamik SVG-d, CSS-i teisendusmatemaatika, veebiheli API, kohalik salvestus
  Kuigi rakendamine võib erineda. Iga port saab kohaliku salvestuse jaoks kasutada oma salvestussüsteemi ja Web Audio API jaoks erinevat heli API-d.

See muutub veidi segaseks, nii et proovime vaadata mõningaid erinevusi. Nüüd, mis ei ole WebKiti portide puhul tavaline:

• Kõik, mis on seotud GPU-ga
  - 3D teisendus
  - WebGL
  - Video dekodeerimine
• 2D renderdamine ekraanile
  - Antialiase tehnoloogiad
  - SVG ja CSS-i gradientide renderdamine
• Teksti renderdamine ja sidekriipsutus
• Võrgutehnoloogiad (SPDY, eelrenderdamine, WebSocket transport)
• JavaScripti mootor
  - JavaScriptCore mootor asub WebKiti hoidlas. Kuid WebKitis on köited nii selle kui ka V8 jaoks.
• Vormi elementide renderdamine
• Video- ja helisiltide käitumine ning kodeki tugi
• Pildi dekodeerimine
• Navigeerimine tagasi/edasi
  - osa pushState()
• SSL-i funktsioonid, nagu range transpordi turvalisus ja avaliku võtme PIN-koodid

Vaatame ühte neist: 2D-graafika on pordist sõltuv, me kasutame ekraanile renderdamiseks täiesti erinevaid teeke:

Või kui minna üksikasjalikumalt, siis hiljuti lisatud funktsioon: CSS.supports() on lubatud kõigi portide jaoks, välja arvatud win ja wincairo, millel pole css3 tingimuslikke funktsioone lubatud.

Nüüd on meil tehniline... aeg pedantseks muutuda. Isegi see, mis eespool öeldi, pole täiesti õige. See on tegelikult WebCore, üldine komponent. WebCore on HTML-i ja SVG paigutuse, renderduse ja DOM-i teek ning see on põhimõtteliselt see, millele inimesed mõtlevad, kui nad ütlevad WebKit. Tõepoolest, "WebKit" on tehniliselt WebCore'i ja "portide" vaheline sidemete kiht, kuigi tavavestluses on see eristamine suures osas ebaoluline.

Diagramm peaks aitama:

Paljud WebKiti komponendid on lülitatavad (näidatud halliga).

Näiteks WebKiti JavaScripti mootor JavaScriptCore on WebKiti vaikemootor. See põhineb algselt KJS-il (KDE-st) aegadest, mil WebKit sai alguse KHTML-i hargina. Samal ajal lülitub Chromiumi port V8 mootorile ja kasutab ainulaadseid DOM-i sidemeid.

Fondid ja teksti renderdamine on platvormi väga suur osa. WebKiti teksti jaoks on kaks erinevat teed: Quick ja Hard. Mõlemad nõuavad platvormipõhist tuge (rakendatud pordi poolel), kuid Fast peab teadma, kuidas kustutada glüüfe (mida WebKit platvormi jaoks vahemällu salvestab), samas kui Complex liigutab stringi renderdamise täielikult platvormi tasemele ja ütleb lihtsalt „joonista see, palun."

„WebKit on nagu võileib. Muidu on see Chromiumi puhul pigem taco. Maitsev taco veebitehnoloogiatest.
Dmitri Glazkov, Chrome WebKiti häkker. Veebikomponentide meister ja varidom.

Nüüd laiendame ulatust ja vaatame mitut porti ja mitut alamsüsteemi. Allpool on viis WebKiti porti, pange tähele, kuidas igaühe tööriistakomplekt on ühistest komponentidest hoolimata erinev:

Chrome (OS X) Safari (OS X) QtWebKit Androidi brauser Chrome iOS-ileRenderdamine Võrgustiku loomine Fondid JavaScript

Skia	CoreGraphics	QtGui	Android stack/Skia	CoreGraphics
Chromiumi võrgupinn	CFNetwork	QtNetwork	Fork of Chromiumi võrgupinn	Kroomi virn
CoreText Skia kaudu	CoreText	Qt sisemised osad	Androidi virn	CoreText
V8	JavaScriptCore	JSC (V8 kasutatakse mujal Qt-s)	V8	JavaScriptCore (ilma JIT-ita) *

* Joonealune märkus iOS-ile mõeldud Chrome'i kohta. See kasutab UIWebView-d, nagu te ilmselt teate. Vastavalt UIWebView võimalustele tähendab see, et see saab kasutada ainult sama renderdusmootorit nagu Mobile Safari, JavaScriptCore (mitte V8) ja ühe lõimega mudelit. Mõni kood on siiski Chromiumilt laenatud, näiteks võrgu alamsüsteem, järjehoidjate sünkroonimise infrastruktuur, omnikastike, mõõdikud ja krahhiaruanded. (Samuti on JavaScript mobiilseadmetes nii harva kitsaskohaks, et JITtingi kompilaatori puudumisel on minimaalne mõju.)

Olgu, kust me tulnud oleme? Ja nii, kõik WebKitid on nüüd täiesti erinevad. Ma kardan.

Ei ole seda väärt! WebKiti "layoutTesti" testide katvus on tohutu. (28 000 testi lõpuks) ja mitte ainult olemasolevate funktsioonide, vaid ka kõigi leitud regressioonide jaoks. Tegelikult, kui õpite uusi või "salajaste" DOM/CSS/HTML-5 funktsioone, on "layoutTesti" testikomplektidel tavaliselt suurepärane minimaalne demo.

Lisaks teeb W3C jõupingutusi testikomplekti standardimiseks. See tähendab, et võime eeldada, et nii WebKiti porte kui ka kõiki teisi brausereid testitakse samade testkomplektidega, mis toob kaasa vähem veidrusi ja koostalitlusvõimelisema veebi. Kõigile, kes pingutavad, osaledes üritusel Test The Web Forward...aitäh!

Opera kolis just WebKiti. Mis sellest saab? Robert Nyman ja Rob Hawkes on seda teemat juba puudutanud, kuid lisan, et teate üheks oluliseks osaks oli Opera kolimine Chromiumi. See tähendab, et WebGL, Canvas, HTML5 vormid, 2D-graafika rakendamine, kõik need asjad on nüüd Chrome'is ja Operas samad. Sama API ja madala taseme juurutus. Kuna Opera põhineb Chromiumil, võite tunda, et vähendate oma töökoormust, et kontrollida Opera ja Chrome'i ühilduvust.
Pean ka märkima, et kõik Opera brauserid viiakse üle Chromiumi. See tähendab, Opera for Windows, Mac, Linux ja Opera Mobile (täisväärtuslik mobiilibrauser). Isegi Opera Mini, õhuke klient, vahetatakse oma praeguselt Presto-põhiselt renderdusfarmilt Chromiumil... ja igaõhtusel WebKiti koostamisel põhinevale renderdusfarmile. Mis see on? See on WebKit, mis töötab sama koodiga kui Safari (kuigi mõnda sisemist teeki on muudetud). Seda haldab suures osas Apple, nii et käitumine ja funktsioonide komplekt on kooskõlas sellega, mida leiate Safarist. Paljudel juhtudel on Apple konservatiivne, kui on vaja lisada funktsioone, mida teised pordid rakendavad või millega katsetavad. Igatahes, kui kasutada analoogiat, mõelge sellele kui... igaõhtune WebKiti koostamine Safari jaoks on nagu Chromium Chrome'ile. Lisa märksõnu

Android ja iPhone – brauserisõjad

1. osa. WebKit appi

Võrgu oleku jälgimise eest vastutava brauserirakenduse arendamine

Sisu seeria:

Kokku on iPhone'i ja Androidi platvormidel erinevatest allikatest allalaadimiseks saadaval üle 100 000 rakenduse. See viitab “natiivsetele” rakendustele, st. rakendused, mis on välja töötatud ja kokku pandud vastava SDK abil ning seejärel installitud mobiilseadmesse. Sellised "natiivsed" rakendused võimaldavad teil tõhusalt rakendada mobiilseadme tehnilisi võimalusi, sealhulgas traadita võrkude, Bluetoothi ​​ja andmesalvestuse, kiirendusmõõturi või kompassi funktsioonide ja muude tehnoloogiliste imede ja uuenduste toetamist, mis muudavad mobiilseadmed kasutajatele nii atraktiivseks. IPhone'i ja Androidi platvormidele mõeldud “natiivsete” rakenduste populaarsus on ülikõrge, kuid lisaks pakuvad mobiiliseadmed rohkelt võimalusi veebirakenduste arendamiseks.Mobiilitehnoloogiad on lapsepõlvest ammu lahkunud ja koos nendega on saavutanud teatud küpsuse ka mobiilne internet.

See artikkel on esimene kaheosalisest seeriast, mis käsitleb iPhone'i ja Androidi brauserirakenduste arendamist. Selle sarja eesmärk on tutvustada lugejale oma mobiilsete veebirakenduste loomise põhiprintsiipe. Mobiilirakenduste võimalused ei piirdu vaid veebilehe käitamisega mobiilseadmes. Vaatleme mobiilirakenduste arendamisel kasutatavaid põhitehnoloogiaid ja lähenemisviise, mis võimaldavad eristada seda tarkvaraarenduse osa eraldi iseseisvaks distsipliiniks.

Veebiplatvormi populaarsust seletatakse sellega, et selle kasutamine võimaldab lahendada paljusid probleeme, mis on traditsiooniliselt olnud arendajate ja süsteemiadministraatorite hädaks. Nende hulgas:

• Installimisprobleemid: veebirakenduste installimine on probleemideta – installige või kopeerige need serverisse ja öelge oma klientidele, millisele URL-ile brauseris osutada.
• Skaleerimise probleemid: veebirakendusi saab hõlpsasti skaleerida suure jõudlusega andmekeskuse serverite kogumiks ja rakenduste teenindamiseks kasutatakse valmis veebisaitide haldustööriistu.
• Andmete arhiveerimise ja taastamise probleemid: veebirakendused kasutavad tsentraliseeritud andmesalvestust, lihtsustades seeläbi tõrgete korral taastamist.
• Kasutajaliidese kaalutlused: HTML-i, CSS-i, JavaScripti ja graafika kombinatsioon võimaldab teil luua rikkaliku kasutajaliidese, mis on funktsionaalsuse ja välimuse poolest oluliselt parem kui natiivsete SDK-de abil arendatud liidesed. Viimased ei suuda reeglina pakkuda mängurakendustele täieõiguslikku kohalolekuefekti ega garanteeri interaktiivsete infoterminalide vajalikku funktsionaalsust.
• Kasutuslihtsus: enamik rakendusi nõuavad kasutajaliidese elemente, mis on lihtsad ja hõlpsasti kasutatavad, võimaldades teil hõlpsasti teha igapäevaseid toiminguid.

Interneti-rakenduste levitamismudeli kõige atraktiivsem aspekt on see, et see võimaldab tarkvaral muutuda omamoodi tellimusteenuseks, mis on vastastikku kasulik viis tarkvara tarnimiseks. "Kuidas?" - te küsite. Vaatame seda probleemi üksikasjalikumalt.

Veebipõhine tarkvara levitamise mudel võimaldab klientidel proovida toodet enne ostmist minimaalse riskiga ja minimaalse hinnaga. Kui kliendile prooviversioon meeldis, siis tarkvaratoote edasiseks kasutamiseks on tal vaja ainult ostu eest tasuda krediitkaardiga (või PayPali abil). Lisaks pakub tarkvara kui teenuse (SaaS) mudel kasutajatele mugavat ja kulutõhusat viisi tarkvara ostmiseks ilma märkimisväärsete eelkuludeta, tagades investeeringutasuvuse pigem esimese kasutuskuu jooksul kui kaugemas tulevikus.

Fakt on see, et mobiilseadmetes veebibrauserite tugi praktiliselt puudus. Olukord muutus dramaatiliselt WebKiti-nimelise tehnoloogia tulekuga, mis tänu iPhone'ile võttis enesekindlalt oma koha mobiilseadmete valdkonnas.

Vaid mõne aastaga on iPhone'i platvormist saanud maailmas esimene veebiklient. Miks? Kuna WebKit koos usaldusväärse Interneti-ühendusega võimaldas kasutada veebiteenuseid mobiilseadmetes palju tõhusamalt kui üheski teises kaasaegses brauseris. Ka teised mobiilseadmete turu tegijad on uut tehnoloogiat märganud ning kogu turu saab nüüd jagada ettevõteteks, kes kasutavad WebKiti, ettevõteteks, kes hakkavad kasutama WebKiti, ja ettevõteteks, kes otsivad ettekäändeid WebKiti mitte kasutada. .

Mis on WebKit?

WebKit ja HTML5

WebKit on brauseri mootor, mida kasutatakse nii Mobile Safari brauseri toetamiseks iPhone'i platvormil kui ka Androidi platvormil oleva brauseri toetamiseks. Loomulikult kasutatakse WebKiti ka teistes mobiilseadmetes, kuid selle artikli jaoks piirdume iPhone'i ja Androidi platvormidega.

WebKit on avatud lähtekoodiga projekt, mis pärineb K Desktop Environment (KDE) arendamisest. Mobiilseadmete kaasaegsed veebirakendused võlgnevad oma sünni WebKiti projektile. Kindlasti mängivad olulist rolli mobiilseadme tehnoloogilised ja disainiomadused, kuid mobiilikasutajaid huvitab eelkõige sisu. Kui mobiilseade pakub juurdepääsu vaid väikesele osale Interneti-sisust, siis tõenäoliselt ei pääse see kõige populaarsemate seadmete edetabelisse.

Enamik meist eelistab elada täisväärtuslikku elu: kui avame sülearvutis veebisaidi kodus istudes, eeldame, et näeme sama sisu ka siis, kui avame saidi rongis istudes. Sisu on mobiilirakenduste peamine probleem. Pole tähtis, kus me oleme või mida me teeme, vajame juurdepääsu meile huvitavatele andmetele. WebKiti tehnoloogia pakub rikkalikku sisu iPhone'i ja Androidi platvormidel.

Väärib märkimist, et WebKiti kasutatakse ka lauaarvutites, näiteks Safari brauseris, mis on platvormi Mac OS X peamine brauser. Olenemata sellest, kas tegemist on lauaarvuti versiooniga või iPhone'i või Androidi brauseri mootoriga, jääb WebKit alles kõige arenenum saadaolev tehnoloogia, mis toetab HTML-i ja CSS-i. Tegelikult toetab WebKit CSS-i stiile, mida teiste mootorite brauserid veel ei renderda – näiteks mitmeid HTML5 spetsifikatsioonis määratletud atribuute.

HTML5 on esialgsete tehniliste spetsifikatsioonide kogum, mis määratleb brauseripõhised tehnoloogiad, nagu kliendipoolne andmesalvestus koos SQL-i toega, käigud, teisendused ja nii edasi. HTML5 spetsifikatsioon on veel pooleli, kuid kui põhiprintsiibid on enamiku platvormide brauserites selgelt määratletud ja rakendatud, jääb veebirakenduste tagasihoidlik algus minevikku. Veebirakenduste arendamine hõivab olulise osa tarkvaraarenduse tööstusest ja me ei räägi mitte ainult lauaarvuti brauserite, vaid ka mobiilibrauserite rakendustest. Mobiilirakendused muutuvad kõrvaltootest veebirakenduste turu põhitooteks.

Mobiilse veebirakenduse arendamise disainifunktsioonid

Kui otsustate veebiarendustehnoloogiaid omandada, on teie käsutuses väga piiratud valik tööriistu. Esiteks saab rakenduse luua otse serverisse HTML-i, CSS-i ja JavaScripti koodi sisaldava failina. Sel juhul saab HTML-i sisu pakkuda staatiliste HTML-failidena või genereerida dünaamiliselt, kasutades erinevaid serveri poolel töötavaid tehnoloogiaid, näiteks PHP, ASP.NET, Java Servletid jne. Igal juhul punktist. Selle artikli jaoks taandub see kõik HTML-koodile ja meie jaoks on siinkohal kõige olulisem see, et WebKiti tehnoloogia võimaldab brauseritel renderdada HTML-i mobiilseadmetes.

Veebirakenduse käivitamiseks mobiilseadmes (iPhone või Android) peab kasutaja käivitama brauseri ja sisestama vastava teenuse URL-i, näiteks: http://teieettevõttenimi.com/rakenduse URL.

Samal ajal on pakutavate mobiilsete veebirakenduste valik üsna lai: alates tavalisest veebisaidist kuni spetsiaalselt konkreetse mobiiliplatvormi jaoks välja töötatud mobiilse veebirakenduseni.

Standardsete saitide kuvamine

WebKiti mootor koos iPhone'i ja Androidi platvormide intuitiivse ja kasutajasõbraliku kasutajaliidesega võimaldab teil oma mobiilseadmes vaadata peaaegu kõiki veebisaite. Veebilehti kuvatakse üsna õigesti, erinevalt eelmise põlvkonna mobiilibrauseritest, mis edastasid juhuslikult sisu fragmente või ei kuvanud neid üldse. Kui lehed laaditakse WebKiti toega brauseris, kipub lehe sisu skaleerima. Sel juhul valitakse skaala nii, et kogu leht mahuks ekraanile, kuigi oluliselt vähendatud, sageli loetamatul kujul, nagu on näidatud joonisel 1. Lehekülge saab aga kerida, suurendada, liigutada, tagades mugava juurdepääsu kõik sisuelemendid. Vaikimisi kasutab brauser akent, mille laius on 980 pikslit.

Kui veebilehe täielik kuvamine brauseriaknas on märkimisväärne edasiminek võrreldes eelmise põlvkonna brauseritega, siis tänapäevaste mobiilitehnoloogiate võimalused sellega ei piirdu.

Veebilehed, mis on loodud mobiilseadmeid silmas pidades

Kui soovite, et teie veebileht oleks juurdepääsetav mitte ainult tavalistele veebikasutajatele, vaid ka mobiilikasutajatele, on mobiilsete veebirakenduste optimeerimiseks veel mõned võimalused.

Kuigi WebKit võimaldab veebilehte mobiilseadme ekraanil õigesti kuvada, on hiirepõhiste seadmete (nt sülearvutid või lauaarvutid) ja puutetundlike seadmete (nt iPhone või Androidi nutitelefonid) vahel teatud erinevused. Puuteseadmed erinevad klõpsuala füüsiliste mõõtmete, kursori mis tahes elemendi kohal hõljutamise funktsiooni puudumise ja sündmuste erineva järjestuse poolest. Seega, kui soovite luua veebisaiti, mis on mugav nii tava- kui ka mobiilikasutajatele, peate arvestama järgmiste mobiilseadmete funktsioonidega:

• iPhone'i ja Androidi brauserid suudavad renderdada tervet veebilehte üsna loetaval kujul – nende brauserite renderduskvaliteet on palju kõrgem kui tavalistel mobiilibrauseritel –, seega ärge kiirustage oma saidi kujunduse lihtsustamisega.
• Sõrmeotste suurus on oluliselt suurem kui hiirekursori suurus. Võtke seda tegurit saidi navigeerimiselementide väljatöötamisel arvesse. Ärge asetage linke üksteisele liiga lähedale, vastasel juhul ei saa kasutaja klõpsata ühel lingil ilma järgmist tabamata.
• Mobiilseadmetes hõljutuselemendid ei tööta. Kasutaja lihtsalt ei saa hiirekursoriga sarnaselt ühelegi elemendile sõrmega „näidata”.
• Sündmused, mis on määratletud hiirenupu vajutamisel ja all hoidmisel, hiire lohistamisel jne, realiseeritakse puuteekraanidel erineval viisil. Mõned neist sündmustest võivad toimida ka mobiilseadmetes, kuid üldiselt ei tohiks te eeldada, et mobiilibrauser ja lauaarvuti brauser sooritavad sama toimingute jada.

Nende aspektide üksikasjaliku arutelu leiate artiklist " iPhone tegevuses"(vt jaotist). Oma artiklis piirdume WebKiti eeliste, mitte selle puuduste kaalumisega.

Vaatame kõige ilmsemat probleemi, millega iPhone'i või Androidi kasutajad veebisaitidele juurdepääsul kokku puutuvad: piiratud ekraani suurus. Tegelikult on tänapäevase mobiilseadme ekraani suurus 320 x 480 või 480 x 320, eeldusel, et kasutaja eelistab vaadata veebisisu horisontaalasendis. Nagu näete jooniselt 1, suudab WebKit õigesti kuvada standardsete lauaarvutite jaoks mõeldud veebilehe. Veebilehe skaleerimisel võib tekst aga lugemiseks liiga väikeseks muutuda, nii et kasutaja peab enne teksti lugemist kerima, panoraamima ja suumima. Kuidas selle piiranguga toime tulla?

Lihtsaim viis luua leht, mis kuvatakse võrdselt hästi nii mobiilibrauseri aknas kui ka töölaua brauseriaknas, on kasutada spetsiaalset metasilti vaateava.

Metabärgend on HTML-dokumendi päisesse paigutatud HTML-märgend. Vaateava märgendi kasutamise lihtsaim näide näeb välja järgmine: . Selle metasildi lisamisel HTML-lehele skaleeritakse selle kuvamine mobiilibrauseri aknas kõige optimaalsemal viisil (vt joonis 2). Brauserid, mis ei toeta vaateava, lihtsalt ignoreerivad seda silti.

Mõnel juhul on kasulik akna skaleerimise parameetrid eelnevalt määratleda, nagu on näidatud joonisel 3.

Konkreetsete suumisuvandite määratlemiseks määrake vaateava sisu atribuudi täpne väärtus: metasilt. Algskaala parameetri väärtust muutes saab pilti vähendada või suurendada. IPhone'i ja Androidi platvormide jaoks on parem kasutada väärtusi vahemikus 1,0 kuni 1,3. Vaateava metasilt toetab ka minimaalset ja maksimaalset suumi, mis võimaldab piirata kasutaja võimalust muuta lehe suumi selle laadimisel.

Kui iPhone'i disainiomadused, eelkõige 320x480 ekraani suurus, on selle kasutuselevõtust alates praktiliselt muutumatuks jäänud, on Androidi platvormi seadmete parameetrite valik üsna lai, kuna sellel platvormil olevaid mobiilseadmeid toodavad erinevad tootjad ja mõeldud väga erinevatele kasutajarühmadele. Seega, kui soovite, et teie veebirakendus oleks mobiilikasutajate seas populaarne, peaksite arvestama võimalike erinevustega Android-seadmete ekraani suuruses, eraldusvõimes ja disainifunktsioonides.

Kogemused on näidanud, et lisaks disainierinevustele, mis eksisteerivad erinevate Android-mobiilseadmete vahel, proovib Androidi tarkvara ise määrata laaditud veebilehe sätteid sõltuvalt mobiilseadme brauseri omadustest. Lisaks stabiilsusele on Androidi platvormil pidevalt muutuv hulk funktsioone ja võimalusi. Teie konkreetse Android-seadme seaded erinevad tõenäoliselt teie arenduskeskkonnast, olenevalt SDK versioonist ja seadme tootjast. Joonisel 4 on näidatud brauseri seadistusekraan versioonis 1.6 Android Emulator. Ekraani seaded annavad kasutajale võimaluse määrata ekraanil pildi skaleerimise taset (kauge, lähedal, keskmine) või valida lehe automaatse skaleerimise režiimi.

Mobiilseadmete maailmas on kõige püsivam muutus, seega tuleb arvestada mobiilitarkvara turu arengu ja uuenemisega. Näiteks sisaldavad Sprint Hero brauseri sätted valikut, mis erinevad täielikult veebilehe laadimisel kasutatavatest standardsätetest. Hero brauser on ehitatud Android V1.5 platvormile, kasutades mitmeid HTC tehtud muudatusi. Õnneks ignoreerib vaateava metasilti kasutamine Hero spetsiifilisi sätteid.

Siiani oleme näinud, et WebKit saab veebilehe laadimisel päris hästi hakkama, kuigi oluliselt vähendatud ja raskesti loetaval kujul. Seejärel laiendasime kontrolli selle üle, kuidas leht mobiilseadme ekraanil kuvatakse, kasutades vaateava metasilti. Kuvatud lehte on nüüd palju lihtsam lugeda ja navigeerida. Kuid sellest ei piisa, et meie leht näeks välja ja toimiks nagu veebirakendus.

Loodud mobiilseadmete jaoks

Vaatleme edasi mobiilse vaatajaskonna jaoks mõeldud veebilehe kujundusfunktsioone. Konkreetse näitena vaadake Google'i meiliteenuse Gmaili registreerimislehte.

Selline näeb leht välja töölaua brauseriaknas:

Töölauabrauseriaknas kuvatakse teabesisu vasakul küljel ja registreerimisaken ise asub paremal paneelil. Mobiilibrauseriaknas on sama leht hoopis teistsuguse välimusega.

Joonisel 6 kujutatud leht on kindlasti mõeldud mobiilikasutajatele. Ekraanil kuvatakse ainult need leheelemendid, mida kasutaja edasiseks tööks vajab – täiendavat kerimist, panoraamimist ega suumimist pole vaja.

Vaatame nüüd Gmaili mobiiliversiooni meilivaate akent. Kuna rakendusele saadaolev ekraaniruum on väga piiratud, on sõnumivaaturil lisanupud ja navigeerimiselemendid. Sel juhul kuvatavad navigeerimiselemendid kattuvad sõnumite vaatamise aknaga. Kui saate seda vältida, ärge kasutage liiga palju kaadreid ega kerivaid elemente. Gmaili mobiiliversioon lahendab selle probleemi hüpikmenüü abil, mis kuvatakse kohe, kui kasutaja on lehe kerimise lõpetanud. Hüpikmenüüs on 3 nuppu: Arhiiv, Kustuta ja Veel. Kui klõpsate nuppu Veel, ilmuvad täiendavad menüüelemendid (vt joonis 7).

See on tõesti mobiilseadmete jaoks loodud rakendus.

Tuleb meeles pidada, et me ei taha sihilikult vaesestada disaini ja vähendada nende mobiilikasutajate kasutuskogemust, kes on välja töötanud iPhone'i ja Androidi platvormidele multifunktsionaalsed brauserid. Sellest vaatenurgast on kasulik pöörata tähelepanu Gmaili lehe allservas kuvatavale elemendile (vt joonis 8):

Kui kasutaja eelistab töölauaversiooni täiustatud funktsioone, andke talle võimalus lehe sobiv versioon alla laadida.

Mõelge nüüd juhtumile, kus soovite luua rakenduse, mis kasutab veebitehnoloogiaid, kuid näeb välja nagu natiivne mobiilirakendus.

Platvormispetsiifiline sisu

Järgmine samm on konkreetsele mobiiliplatvormile spetsiifilise sisu väljatöötamine. See määrab lehe vormingu ja liidese, nii et tulemuseks olev leht näeb välja nagu konkreetse platvormi jaoks mõeldud rakendus, mitte tavaline avalik veebisait. Mida me mõtleme "natiivse" rakenduse all?

Enne kui asume arutelusse selle üle, kuidas muuta veebirakendus konkreetse platvormi jaoks võimalikult sarnaseks omarakendusega, jätame kõrvale iPhone'i ja Androidi brauserite ühised omadused ning puudutame lühidalt visuaalseid erinevusi, mis nende platvormide vahel eksisteerivad. .

iPhone'i rakendustel on oma spetsiifiline välimus ja liides. Näidake kellelegi iPhone'i ekraanipilti ja kui ta just eelmisel päeval Kuu pealt alla ei kukkunud, ütleb ta peaaegu kindlasti kohe, et see on iPhone. Näidake samale inimesele Android-mobiilseadme ekraanipilti ja vastus pole enam nii selge. Mis on põhjus? Seletusi on mitu. Esiteks ilmus iPhone turule palju varem kui Android-põhised seadmed ja suutis võita tohutul hulgal fänne. Mõelge inimestele, kes soovivad V1 iPhone'i piiratud funktsioonide eest maksta parimat dollarit. Ükskõik, kas teile meeldib iPhone või mitte, on see Apple'i toode praegu turuliider. Aga Android?

Androidi platvorm on suhteliselt uus toode ja toimib paljudes aspektides iPhone'i antipoodina, kuna see on mõeldud peamiselt avatud kogukonna jaoks. Androidi platvormi kasutatakse väga erinevates seadmetes (telefonid ja muud kodumasinad). Arutelu lihtsustamiseks piirdume selles artiklis Androidi kasutamisega mobiiltelefonides.

Aja jooksul ületab Android-seadmete arv maailmas iPhone'ide arvu. Selle põhjuseks on asjaolu, et Android-seadmeid toodavad mitmed ettevõtted ja neid toetavad paljud andmevõrgud. Kuna Android-mobiilseadmete turul on nii märkimisväärne hulk tegijaid, peaksime kindlasti eeldama turu mõningast killustumist seadmete välimuse ja parameetrite põhjal. Seda trendi on näha HTC SenseUI liideses. Seda atraktiivset välimust ja tunnetust aluseks olev Androidi SDK ei toeta ning see ei ühildu teiste Android-seadmetega. Motorola, Google ja Verizon on ühendanud jõud, et töötada välja uus Android-põhine DROID-seade. See on esimene kommertstoode Android 2.0 platvormil.

Võrrelge erinevaid Androidi süsteeme iPhone'i ühtse välimuse ja tunnetusega. iPhone on Apple'i eriti väärtuslik vara. iPhone'i rakenduste välimus võib aja jooksul veidi muutuda, kuid tõenäoliselt ei saa neid väikeseid muudatusi võrrelda Androidi süsteemide erinevate versioonidega, mida on palju isegi praegu, kui platvorm on alles algusjärgus.

Niisiis, mida tuleb teha, et viia rakenduse välimus ja liides "natiivsetele" programmidele võimalikult lähedale?

Kui oleksime selle väljakutsega silmitsi seisnud enne Web 2.0 tulekut, oleks see tõesti olnud tõsine probleem. Varased katsed toetada mitut kliendibrauserit (mobiil- ja lauaarvuti) tuginesid mitmele lähenemisviisile, näiteks:

• Täiesti paralleelsete alade arendamine
• Dünaamiline sisu genereerimine sõltuvalt userAgenti parameetrist
• Puhverserverite kasutamine, mis võivad sisu muuta sõltuvalt igast konkreetsest seadmest. RIM kasutas edukalt sarnast tehnoloogiat, et võimaldada juurdepääsu e-postile kliendi mobiilseadmest.

Sellised lähenemisviisid võivad olla üsna vastuvõetavad juhtudel, kui arendusega tegelevad suured, hästi rahastatud meeskonnad. Mida peaks muu maailm tegema? Kõigil pole selliste strateegiate elluviimiseks märkimisväärseid rahalisi ressursse, kõrgelt kvalifitseeritud spetsialiste ja piiramatut aega. Lisaks, nagu me juba märkisime, ei saa eelmise põlvkonna brauserite mobiilset Internetti nimetada mugavaks ega populaarseks kasutamiseks, seega ei tohiks te mingil juhul peatuda aegunud meetodite ja lähenemisviiside üle.

Õnneks me ei pea seda tegema. WebKiti ja CSS-i ajastul saab erinevate mobiilseadmete välimuse ja liidese erinevustest üle saada stiililehtede ja meediapäringute abil, mis võimaldavad kasutada erinevaid stiile olenevalt konkreetsest seadmetüübist. Meediumipäringu tehnoloogia võimaldab teil saada teavet kliendi kohta. Traditsiooniliselt saadab brauser serverile userAgent väärtuse, mis võimaldab serveril tuvastada konkreetse brauseri ja määrata sisu, mis tuleks kliendile saata. Meediapäringu abil valib brauser lehe stiili vastavalt oma võimalustele. Järgmine näide demonstreerib nutitelefonidele mõeldud stiililehe valimist: . Ja see päring määratleb töölaua stiililehe: .

Internet Explorer V6

Selle kirjutamise ajal hõivas Internet Explorer V6 ligikaudu 20–30% kogu brauseri turust, kuid IE V6 võimaluste üle arutlemine ei kuulu selle artikli ulatusse.

Lisateavet meediapäringute kohta leiate spetsifikatsiooni mustandist (vt jaotist).

Vaatame näidet meediapäringute kasutamisest võrguserverite olekut kuvava rakenduse arendamiseks.

Võrgu jälgimise programm

Selle rakenduse eesmärk on jälgida mitme serveri tööd. Sõltumatud tarkvaraarendajad peavad sageli toetama mitut rakendust mitmes serveris. Kui olete tarkvaraarendusega tegelenud mõnda aega, siis olete tõenäoliselt juba kokku puutunud erinevat tüüpi serverite ja erinevat tüüpi rakendustega. Kõik see tähendab, et on täiesti võimalik, et te ei saa kõigi vajalike rakenduste toimivuse jälgimiseks kasutada ühte tööriista. Sel juhul on mõttekas kasutada mobiilsidevõrgu jälgimise rakendust (netmon). Rakendus pakub kõiki vajalikke funktsioone, jäädes samas paindlikuks ja mobiilseadmest hõlpsasti juurdepääsetavaks.

Netmoni rakendus sisaldab loendit serveritest, mida tuleb jälgida. Peamised jõudlusnäitajad (KPI-d) kogutakse iga serveri kohta. Peamised tulemusnäitajad on peamine tööriist, mida MBA üliõpilased on aastaid kasutanud ettevõtte hetkeseisu hindamiseks. Veebirakenduse hostimise vaatenurgast saab KPI-dena kasutada järgmisi näitajaid.

• Tehingute arv viimase aja jooksul
  • Tellimused
  • Kataloogide päringud
  • Meilid
  • Lehevaadete arv
• Viimasest tehingust möödunud aeg
  • Telli
  • Elektrooniline andmevahetus
  • Sõnumid äripartnerilt
  • Faili üleslaadimine müüjalt FTP kaudu
• Kas andmebaas on saadaval?
• Viimane varundamise kuupäev
• Keskmine tellimuse summa (dollarites)
• Vaba kettaruumi hulk
• Ribalaius viimase tunni, päeva, kuu kohta

Ülaltoodud mõõdikud ja muud sarnased tööparameetrid võimaldavad hinnata konkreetse süsteemi või rakenduse tervist. Näiteks pühadehooajal vaatame mõnel meie saidil tehtud tellimuste arvu. Kui andmed ei näita stabiilset tellimuste arvu kasvu igas tunnis, viime läbi täpsema olukorra analüüsi.

Kuna igal rakendusel on oma nõuded ja ressursid, peab netmon olema piisavalt paindlik, et rahuldada iga rakenduse vajadusi. Selle paindlikkuse taseme tagamiseks määratleme kõigepealt kõige üldisema andmestruktuuri, et võtta arvesse iga süsteemi olekuparameetreid. 2. osas vaatleme lähemalt, kust need andmed pärinevad ja kuidas neid värskendatakse. Praegu piirdume järgmise teabega:

• Saidi nimi
• Saidi URL (avaleht)
• URL värskenduste saamiseks
• Olek: OK või mitte
• Kiire kokkuvõte: serveri oleku kirjeldus, mis on kas korras või sisaldab tekstistringi, mis näitab selle serveri kõige tõsisemat probleemi
• Elemendid: see on nime/väärtuse paaride kogum, mida peame edastama vastava saidi praegused KPI väärtused.

Meie rakendus kuvab tulemusnäitajad hõlpsasti navigeeritavas vormingus, kasutades täielikult ära CSS-i, jQuery ja WebKiti, et juhtida kasutaja tähelepanu probleemsetele piirkondadele. Nagu juba mainisime, on selle rakenduse arendamise peamiseks eesmärgiks võimalus seda iPhone'is, Androidi platvormil ja lauaarvutis Safari brauseris käivitada.

Võrgu jälgimise rakenduste arendamine

Kaasaegsed veebilehed tuleb luua deklaratiivsel kujul, mis määratleb lehe organisatsioonilise struktuuri ja sisu. Lehekülje positsioneerimine ja vormindamine toimub CSS-i (Cascading Style Sheets) ja enamikul juhtudel JavaScripti abil. Tegelikult on JavaScripti teegid muutunud nii populaarseks, et nende kasutamine tänapäeval on pigem reegel kui erand. Selles artiklis käsitletud rakenduses kasutame populaarset JavaScripti teeki jQuery. Meie rakendus töötab iPhone'i, Androidi ja töölaua platvormidel. Kasutatakse sama HTML-koodi ja kõik vajalikud erinevused rakendatakse stiililehtedel. Siinkohal tuleb märkida, et me ei ole teadlikult teinud märkimisväärseid jõupingutusi rakendusele atraktiivse välimuse kujundamiseks. Pealegi valiti teadlikult taustaks silmatorkavad värvid, mis ei harmoneeru omavahel, et tõmmata lugeja lisatähelepanu stiililehtede korraldusele. 2. osas parandame veidi rakenduse välimust, kuid praegu näeb HTML-kood välja nagu loendis 1 näidatud.

Loetelu 1. Rakenduse HTML-kood if (navigator.userAgent.indexOf("iPhone") != -1) ( document.write(""); ) else if (navigator.userAgent.indexOf("Android") != -1 ) ( document.write(""); ) else ( document.write(""); ) funktsioon setupTestData() ( proovige ( netmon.initialize(); if (netmon.resources.length > 0) ( jQuery.each( netmon .resources,function (indeks, väärtus) ($("#mainContent").append(netmon.render(index,value)); )); $(".serverentry").click (function() ( $(this ).find(".serveritems").toggle();)); $(".serveritems").hide(); ) ) püüda (e) ( alert(e); ) ) Minu võrguressursid Minu Serverid Minu kasutajaagent

Kiire pilk pakutud HTML-koodile paljastab järgmised põhifunktsioonid.

• Kood kasutab kahte välist JavaScripti faili: ühte jQuery teegi faili ja ühte abifaili meie rakenduse jaoks.
• Kood kasutab kuvatava sisu skaleerimiseks vaateava metasilti.
• Peamise stiililehe määrab fail netmon.css.
• Parameetrit userAgent kasutatakse abilaadilehe määratlemiseks. Sõltuvalt selle väärtusest laaditakse stiilileht iPhone'i, Androidi või lauaarvuti brauseri jaoks.
• Lehe laadimisprotsess kasutab andmete kuvamiseks jQueryt ja failis netmon.js määratletud abifunktsiooni.
• Pealehe kood kasutab mitut div-märgendit.
• Lõpuks sisaldab kood linki lehele, mis näitab userAgent stringi. Sellel lingil pole rakenduse toimimisega mingit pistmist ja seda kasutatakse ainult tutvustamise eesmärgil.

Enne kui hakkame üksikasjalikult käsitlema laaditabeleid ja faili netmon.js, mis tegelikult määravad rakenduse põhitoimingud, vaatame oma rakendust selle praeguses olekus. Pange tähele, et me kasutame kolme erinevat stiililehte: ühte iga kolme toetatud platvormi jaoks. Rakenduste arendusprotsessi visuaalsemaks muutmiseks määrab iga tabel oma taustavärvi. Joonisel 9 on meie leht avatud Desktop Safari brauseris ja sellel on sinine taust.

Joonis 11 näitab rakenduse välimust iPhone'i brauseriaknas (taustavärv on roheline).

Failis netmon.js salvestatud põhilaadileht on näidatud loendis 2.

Loetelu 2. Põhilaaditabeli sisu (värv: #888888; fondiperekond: Helvetica; fondi suurus: 14px; veeris: 0px; polster: 0; ) .details ( veeris: 0px; polsterdus: 0px; taustavärv: valge ; ääris: ühtlane; äärise laius: 1px; -veebikomplekti ääris-ülemine vasak-raadius: 8 pikslit; -veebikomplekti ääris-ülemine-parem-raadius: 8 pikslit; -veebikomplekti ääris-all-vasak raadius: 8 pikslit; - webkit-border-bottom-right-radius: 8px; ) .OK ( värv: #000000; ) .BAD ( color: #ff0000; ) .odd ( taustapilt: -webkit-gradient(lineaarne, vasak ülemine, parem alumine ,from(#ccc) ,to(#999)); ) .even ( taustpilt: -webkit-gradient(lineaarne, vasak ülemine, parem alumine,from(#999) ,to(#ccc)); ) . serverrentry a ( float: paremal; värv: #ffffff; ) .serveritems( color: #000; ) #header h1 ( veeris: 0; polsterdus: 0; teksti joondus: keskel; värv: #000; )

Erineva stiililehe kasutamine iga platvormi jaoks võimaldab teil saavutada järgmisi ülesandeid.

Muutke lehe värviskeemi. See võimaldab esiteks selgelt näidata stiililehe rolli ja teiseks näidata, kui lihtne on soovitud stiililehte valida sõltuvalt userAgent parameetri väärtusest.

Määrake mobiili- ja lauaarvutiplatvormide jaoks erinevad fondisuurused.

Kontrollige asjakohaseid WebKiti funktsioone. Sellel oleks oluline erinevus, kui rakendus töötaks ilma WebKiti toeta brauseris, näiteks Firefoxis.

3. loend näitab faili iphone.css koodi.

Kirje 3. Faili iphone.css body ( taustavärv: #00ff00; ) .serverentry ( -webkit-border-top-left-radius: 8px; -webkit-border-top-right-radius: 8px; -webkit-border -bottom-left-radius: 8px; -webkit-border-bottom-right-radius: 8px; ) .name ( fondi suurus: 2 em; ) .summary( fondi suurus: 1,5 em; ) .serverentry a ( font- suurus: 1,5 em;)

Nagu näeme, on kehasildi taustavärv roheline (#00ff00) ja fondi suurust on kohandatud nii, et seda mobiilseadme ekraanil oleks lihtsam lugeda. Lõpuks vaatame faili netmon.js, mis määratleb serverite loendi ja funktsiooni, mis prindib iga serveri andmed (kasutatakse loendis 4). Osa failikoodist on lühiduse huvides välja jäetud; selle täistekst on saadaval jaotises ).

Kirje 4. Netmon.js fail var netmon = ( lähtestage: funktsioon () ( ), ressursid: [ ( nimi: "msiservices.com", koduurl: "http://msiservices.com", pingurl: "http:// msiservices.com/netmon.php", olek: "OK", kokkuvõte: "OK", üksused: [ (nimi: "DiskSpace", väärtus: "22.13 GB"), (nimi: "Andmebaas üles?", väärtus: "Jah") ] ), ( nimi: "server 2", homeurl: "http://someurl", pingurl: "http://someurl/netmon.jsp", olek: "OK", kokkuvõte: "OK" , üksused: [ (nimi: "DiskSpace", väärtus: "100,8 GB"), (nimi: "Andmebaas üles?", väärtus: "Jah") ] ), // täiendavad kirjed kärbitud lühiduse huvides ], renderdamine: function( index,itm) ( proovige ( var ret = "; ret += ""; ret += "" + itm.name + " Näita
"; if (itm.status != "OK") ( ret += "-" + itm.summary + "
"; ) ret += ""; jQuery.each( itm.items,function (j, itemdetail) ( ret += ">" + üksuse detail.nimi + "=" + üksuse detail.väärtus + "
"; )); ret += ""; ret += ""; tagasta ret; ) püüda (e) ( tagastab "Viga üksuse renderdamisel [" + itm.name + "] " + e + ""; ) ) ) ;

Kui mõne serveri olekuriba ei ole korras, siis kuvatakse vastav serveri kirje punaselt, nagu on näha CSS-faili klassidefinitsioonist. Lisaks, kui serveri oleku kontrollimisel ilmnevad probleemid (olek pole korras), kuvatakse lisaks probleemi lühikirjeldus. Joonised 9-11 näitavad, et serveris 4 on vaba kettaruum otsa saamas. Kui klõpsate selle serveri real, kuvatakse ekraanile üksikasjalik teade probleemi kohta (vt joonis 12).

Klõpsates serveri nimest paremal oleval näitamise lingil, avaneb selle serveri avaleht. Sellise lingi omamine on väga mugav kahel põhjusel: esiteks säästab see teid ebameeldivast vajadusest iga serveri URL pähe õppida ja teiseks säästab teid veelgi ebameeldivamast vajadusest sisestada see URL klaviatuurilt. teie mobiilseade (isegi kõige mugavam).

Seega, kui meil õnnestub mobiilseadmes edukalt netmoni käivitada, ei tohiks serverite hooldamise ülesanne probleeme tekitada.

Järeldus

See artikkel tutvustab WebKiti tehnoloogia abil iPhone'i ja Androidi veebirakenduste arendamise põhimõtteid. 2. osas laiendame oma rakenduse võimalusi, lisades Ajaxi kõnede abil andmete värskendamise funktsiooni.

Just hiljuti puutusin kokku küsimustega, millel oli silt "veebikomplekt". Sellised küsimused on tavaliselt seotud veebiprobleemidega, mis on seotud CSS-i, jQueryga, paigutustega, brauseritevahelise ühilduvuse probleemidega jne.

Mis on "webkit" ja kuidas see on seotud CSS-iga? Samuti märkasin erinevate veebisaitide lähtekoodis palju atribuute -webkit-.... Kas need kaks on omavahel seotud?

Värskenda

Niisiis, seniste vastuste põhjal... WebKit on HTML/CSS-i veebibrauseri renderdusmootor Safari/Chrome'i jaoks. Kas sellised mehhanismid on IE/Opera/Firefoxi jaoks olemas ja millised on erinevused, plussid ja miinused nende kasutamisel? Kas ma saan kasutada WebKiti funktsioone näiteks Firefoxis?

Viimane küsimus... Kas IE toetab WebKiti?

Värskendus 2

Kõik suuremad brauserid kasutavad erinevaid renderdusmootoreid. Ma arvan, et see on suur põhjus, miks on nii palju brauseritevahelise ühilduvuse probleeme!

Niisiis, kas on olemas mingi projekt või liikumine standardse renderdusmootori jaoks, mida KÕIK brauserid kasutavad? Kas HTML5 lahendab brauseritevahelise ühilduvuse probleemid?

Selles artiklis vaatleme kolme populaarsel WebKiti mootoril põhinevat brauserit. Veebibrauseri valimisel kipuvad kasutajad vaatama kõige kuulsamaid programme: Google Chrome, Opera, Mozilla Firefox, Internet Explorer. Samas paljud unustavad või ei tea, et Firefox, Chrome ja viimasel ajal ka Opera on loodud avatud lähtekoodiga projektide alusel, mis tähendab, et neid programme saab muuta.

See võimalus toob kaasa asjaolu, et paljud programmeerijad on loonud mitmeid populaarsete brauserite analooge, mis pakuvad üsna huvitavaid funktsioone. Niisiis, vaatame mitut sellise tarkvara esindajat.

Seda levitatakse tasuta, sellel on vene liides, see töötab Windowsis, Androidis, Macis, iOS-is. See brauser oli kümme aastat tagasi tuntud kui MyIE2 ja see oli Internet Exploreri täiendus, kuid sellest ajast on palju muutunud ja nüüd kasutab programm vaikimisi Webkiti mootorit.

Viimases, 4. versioonis pakub brauser mitmeid kasulikke funktsioone, mille hulgas on kõige huvitavam võimalus salvestada teavet pilve. See võimaldab kasutada oma kontot programmis teabe edastamiseks erinevate seadmete vahel, olgu selleks siis Androidi vidin, Apple’i kampaaniatoode või lauaarvuti.

Kuigi Maxthon Cloud Browseri liides on tehtud Chrome'i stiilis, on sellel palju rohkem funktsioone. Külgribal kuvatakse laiendustele juurdepääsu ikoone. Mugav on, et ühe klõpsuga saate kõik installitud lisandmoodulid keelata või lubada ning uusi saate spetsiaalselt veebisaidilt alla laadida.

Seda levitatakse tasuta, sellel on vene liides ja see töötab Windowsis. Comodo toode, mis on rohkem tuntud turvatarkvara arendajana. Comodo Dragon pole enam arendus, vaid konstruktsioon, kuna selle funktsionaalsus ei erine Chrome'ist palju.

Algsest brauserist pole palju erinevusi ja need kõik on seotud turvaprobleemidega. Esimene oluline erinevus Google Chrome'ist on tõeliselt inkognito režiim, Comodo Dragon ei kasuta unikaalset kasutajatunnust ja HTTP-REFERRERit, mis ei võimalda kasutajat võrgus jälgida.

Teine erinevus seisneb Comodo põhitegevuses – kasutajate turvalisuses. Eeldab oma turvaliste DNS-serverite olemasolu liikluse edastamiseks. Pealegi võib kasutaja soovil neid läbida liiklus mitte ainult Dragonist, vaid ka kõigist teistest rakendustest. Turvalised DNS-serverid blokeerivad automaatselt juurdepääsu saitidele, mille Comodo patenteeritud veebiohtude tuvastamise võrk on märkinud ebausaldusväärseks.

Seda levitatakse tasuta, sellel on vene liides ja see töötab Windowsis. “Yandex.Browser” on hiljuti välja antud brauser, mis põhineb Chromiumil Vene ettevõttelt Yandex. Selles tootes lisasid arendajad lihtsalt kiirlinkide paneelile Yandexi teenused. Samuti lisati ja täiustati režiimi "Turbo", mis on saadaval Operas. Üldiselt pole see halb brauser, mis on suunatud Yandexi kasutajatele.

Mis on Webkit?

Mootori põhjal loodi brauserid nagu Midori, Maxthon, Konqueror, Arora jt. Kuid Webkiti ei vali ainult vähetuntud brauserid. Tutvustame teie tähelepanu kahte brauserite maailma "hiiglast" - Apple'i Safari ja Google'i Chrome'i (need brauserid). On ebatõenäoline, et keegi vaidleks, et nendel brauseritel on vähe funktsionaalsust ja madal töökiirus. Lisaks lauaarvuti brauseritele on Webkit tunginud ka mobiiliplatvormidele, mis kinnitab taaskord tasuta tarkvara eeliseid. Seda mootorit kasutab edukalt sama Safari Mobile, mis on välja töötatud iOS-i jaoks. Webkitile on ehitatud ka standardsed brauserid Androidi, HP WebOS-i ja Samsung Bada platvormidele.

See on mootor, mille põhjal on välja töötatud palju brausereid. See on üsna kiire ja kerge ning saab suurepäraselt hakkama kõigi veebikeskkonnas aktsepteeritud standarditega.

Kõige selle juures on see mootor vabalt levitatav tarkvara. Need on komponendid, mis võimaldasid sellel brauseri arendajate seas väga populaarseks saada.

Webkiti ajalugu

Võib-olla olete mõelnud: "Miks tasuta tarkvara?" Vaatame selle loomise ajalugu. Webkiti vanem on ka vabalt levitatav mootor, mida arendatakse Unixi perekonna süsteemide graafilise keskkonna jaoks. Seda mootorit nimetatakse KDE-ks. 1998. aastal otsustas KDE kallal töötav programmeerijate meeskond selle graafilise keskkonna jaoks oma brauseri välja anda.

Sellise brauseri lasid välja ja andsid sellele nime Konquerori loojad. Selle brauseri aluseks oleva mootori nimi oli KHTML. 3 aastat hiljem, 2001. aastal, otsustas Apple luua oma brauseri, mille jaoks kasutas KHTML-i allikaid, aga ka KJS JavaScripti mootorit. Selle sünteesi tulemusena loodi Webkiti projekt Apple'i "tiiva" all. Selle põhjal ilmus 2003. aasta alguses Apple'i brauseri esimene versioon - .

Ka teine ​​infotehnoloogiamaailma “koletis”, Google, võttis oma brauseri loomisel Webkiti aluseks. Ja see on veel üks pluss mootori eelistele. Kuna Google otsustas, et ta on nende jaoks õige, ütleb see palju. Arendajad ise väitsid, et jalgratast otsustati mitte uuesti leiutada, sest Webkit vastab täielikult ettevõtte kõrgetele veebikeskkonnastandardite toetamise nõuetele ja ka üsna suurele töökiirusele.

Tänapäeval jätkab mootor aktiivset arengut ja sellel on suured väljavaated. See pole ime, sest nii Apple kui ka Google töötavad selle täiustamise nimel. Ja see on lisaks ametlikele mootoriarendajatele. Nemad omakorda teatasid, et neil on käsil töö, mille tulemuseks on nende toote teise põlvkonna väljalaskmine, mille eripäraks on eraldi protsesside sisseehitatud arhitektuur (täna on see rakendatakse ainult aastal).