I denne opplæringen lærer du hvordan du bruker SWFObject-skript for å sette opp automatisk omdirigering fra en Flash-nettside til et ikke-Flash-sikkerhetskopieringsnettsted når det vises på en iPad.
Her er en veldig enkel oppsummering av et Flash-nettsted som vi skal bruke i denne opplæringen. Hvis du prøver å få tilgang til den siden ved hjelp av iPad, kan du ikke se noe innhold.
Og her er det endelige resultatet vi skal jobbe med. Hvis du får tilgang til den med iPad, kan du se den animerte siden.
Når forandringsvinden blåser, bygger noen mennesker vegger, andre bygger vindmøller.
- Gamle kinesiske ordtak
Jeg tror iPad er en flott enhet, selv om jeg kan forstå hvorfor innføringen av Flashless-tavlen gjorde ganske mange mennesker sint. Jeg innrømmer at det gjorde meg sint i begynnelsen: like før iPad dukket opp i min lokale Apple-butikk, klarte jeg en Flash-nettside jeg vurderte min personlige mesterverk, og jeg ble overrasket da jeg prøvde å åpne den med iPad, i stedet for min ultrakule Flash animasjon Jeg ble omdirigert til backup-ikke-Flash-siden jeg opprettet "bare i tilfelle". Jeg bekjenner at det tok meg litt tid å tilpasse meg til iPad, men etter hvert har jeg lært å tro at det, som alle banebrytende arbeider, måtte bryte ut av komfortsonen, og jeg antar at jeg er kult med det.
Selvfølgelig, som hjalp meg med å komme fram til den filosofiske holdningen, var antall personer som hyret meg for å sette opp lignende omdirigeringer for deres eksisterende Flash-nettsteder. De kunne heller ikke ha råd til, eller ville ikke erstatte sine fancy, godt utformede Flash-nettsteder med enklere, men mer iPad-vennlige, så muligheten til å sette opp automatisk iPad-omdirigering til et enklere, rent HTML-nettsted appellerte til dem.
(Det kan hevdes at, selv om det ikke er mulig å spille Flash-animasjoner, er iPad åpen mot JavaScript, men det er dessverre ikke tilfelle. De fleste JavaScript-animerte nettsteder spiller ikke bra på iPad. Test noen av disse ti JavaScript animerte nettsteder på datamaskinen din og deretter på iPad for å se hva jeg mener.
Vi må vente til HTML5 er fullt implementert for å se det nye Internettet der tredjepartsplugins som Flash Player gradvis mister sin betydning. I mellomtiden har utgivelsen av iPad-nettbrettet opprettet en ny midlertidig nisje i webutvikling: iPad-proofing eksisterende Flash-nettsteder. Det er tusenvis av gode Flash-nettsteder der ute som kan ha nytte av slik tjeneste; Det er en flott jobbmulighet for gutter som deg og meg.
Det kan være mange forskjellige måter å iPad-proof et Flash-nettsted, noe bedre enn andre. Denne opplæringen tilbyr bare en mulig enkel løsning. Så la oss komme seg til virksomheten.
Det kan være et komplett ikke-Flash-nettsted som inneholder HTML-versjonen av alt innholdet som er kopiert fra Flash-siden, eller bare en enkelt nettside med bare grunnleggende informasjon og en melding til den besøkende, noe som følger med "du ser på vår nettside på en enhet som ikke tillater at Flash-innhold vises. For å få tilgang til alle funksjonene, vennligst åpne nettstedet vårt ved hjelp av en datamaskin med den nyeste versjonen av Flash-spilleren som er installert. "
For denne opplæringen forberedte jeg en enkel JavaScript-animert nettside for å tjene som backup. iPad er i stand til å spille animasjonen moderat bra. Opprettelse av iPad-vennlige JavaScript-animasjoner er utenfor omfanget av denne opplæringen, men du kan finne litt nyttig informasjon om det på hjemmesiden til $ FX () JavaScript animasjonsbiblioteket (og du er også velkommen til å utforske kildekoden til JavaScript -animert side vi skal bruke som backup).
Merk: For å tillate JavaScript-animert side å spille når den lastes opp på serveren din, må du også laste opp fx.js
fil som ligger i Skript-mappen blant de nedlastbare filene for denne opplæringen.
Vi må finne ut hvilken kode som ble brukt til å bygge inn SWF-filen til den opprinnelige Flash-nettsiden i HTML-siden. Vi kan gjøre dette ved å åpne siden i nettleseren og velge alternativet Vis kilde. Alternativt kan vi åpne siden i ethvert tekstredigeringsprogram eller spesialisert HTML-editor.
Kodenes kode som innebærer en SWF-fil på HTML-siden, er lett å gjenkjenne i kildekoden. Aktiver finnfunksjonen og søk på siden for "swf". Dette gjør at navnet på SWF-filen er innebygd på HTML-siden. Koden som omgir navnet på swf-filen, er koden som innebærer den på html-siden.
SWF-filer kan legges inn på en HTML-side på en rekke forskjellige måter. Beskrive dem alle ville gjøre denne opplæringen endeløs, så hvis du er nysgjerrig, kan du bare Google det. Jeg nevner bare noen av de mest populære.
Grunnleggende HTML-kodebasert kode for å legge inn en SWF-fil kan se slik ut:
Sjansen er at Flash-siden ble gjort en stund tilbake: Fra kodebaseattributtet til objektetiketten kan vi se at SWF skal spilles av den sjette versjonen av Flash-spilleren.
Koden er for det meste selvforklarende, det er veldig klart hvilken parameter gjør hva. En ting å nevne er at som du kan se, for noen tilsynelatende mystiske grunner er de fleste parametrene angitt i koden to ganger. Dette er lett å forklare: Koden retter seg mot to forskjellige nettlesere separat.
De tag med alle dens attributter og parametere rettet mot Internet Explorer. De
tag mål for den for tiden utdaterte Netscape Navigator (den nettleseren ignorerte objektetiketten). Derfor, gjentakelsen av den samme informasjonen.
Jeg bør også nevne den klassiske egenskapen til tag forteller Internet Explorer at den burde laste ActiveX-plugin-modulen hvis den ikke er installert; pluginpage attributt av
tag forteller at Netscape Navigator viser koblingen til plugin-siden.
AC_RunActiveContent.js er en JavaScript-fil som fortsatt var mye brukt bare for noen år siden. Noen programmerere som fortsatt jobber med Flash CS3 Professional, kan fortsatt bruke den selv nå.
Koden som innebærer swf-filen ved hjelp av AC_RunActiveContent.js kan se slik ut:
Det er også en linje med kode innenfor
tag på siden som kan se slik ut:Formålet med inkluderingen av filen AC_RunActiveContent.js var endringen fra Microsoft Corporation til Internet Explorer-nettleseren i 2006. Som et resultat av denne endringen (forårsaket av visse juridiske forhold som er kjent som "Eolas patentproblem" og ikke direkte relatert til tekniske aspekter ved webprogrammering), måtte de besøkende som åpnet Flash-nettsteder ved hjelp av Internet Explorer, klikke på det innebygde innholdet før de kunne se eller interagere med det.
AC_RunActiveContent.js-filen var en løsning som tillot brukere å hoppe over det plagsomme klikket og vise det aktive innholdet med en gang, ved å generere HTML-kodene i JavaScript-filen. Denne filen er vanligvis plassert i mappen Scripts i samme katalog som HTML-siden der swf-filen ble innebygd. For ikke å gå inn for mye, kalles AC_RunActiveContent.js filen via AC_FL_RunContent-funksjonen, og attributter og verdier sendes til filen i par: 'bredde', '800', 'høyde', '500' og så på. Du trenger ikke å inkludere filtillegg med navnene på swf-filer, JavaScript-filen gjør det automatisk.
UFO (et akronym som står for Unobtrusive Flash Objects) er en JavaScript-fil som er brukt siden 2006 for å oppdage versjoner av Flash Player og innebygge SWF-filer i HTMl-sider. Det ble skapt av Bobby van der Sluis.
Koden for å legge inn en SWF-fil i en HTML-side med ufo.js kan se slik ut:
Henvisningen til JavaScript-filen i tag kan se slik ut:
Argumentene til ufo.js er selvforklarende. Filen var veldig populær, men er for tiden avskrevet.
FlashReplace.js er en lett (2,1 kb) JavaScript-fil opprettet av Robert Nyman.
Koden for å legge inn en SWF-fil på en HTML-side ved hjelp av FlashReplace.js kan se slik ut:
Åpenbart, som det er tilfellet med AC_RunActiveContent.js og ufo.js-filer, finner du også referansen til JavaScript-filen i stikkord. Det kan se slik ut:
Som du kan se, er FlashReplace.js veldig enkelt. Det første argumentet er navnet på HTML-taggen hvis innholdet skal erstattes med swf-filen; Det andre argumentet er navnet på swf-filen, det tredje argumentet er det vilkårlig id du kan tilordne objektet du legger inn, og de to siste argumentene er bredden og høyden til SWF-filen.
swfbject.js ble skapt av Geoff Stearns, Toby Boudreaux og Bobby van der Sluis. Det er for øyeblikket (2010) det mest populære og mye brukt JavaScript-biblioteket for å oppdage versjoner av Flash Player og innebygge SWF-filer i HTML-sider.
Koden for å legge inn en SWF-fil på en HTML-side ved hjelp av SWFObject.js kan se slik ut:
Koden som du nettopp har lest, er et veldig grunnleggende eksempel på hvordan swfobject.js kan implementeres. Koden kan være mye mer kompleks. For mer informasjon, sjekk ut denne swfbject.js-opplæringen og konsulter utviklerens dokumentasjon.
Henvisningen til JavaScript-filen i tag kan se slik ut:
Hvis den eksisterende Flash-nettsiden bruker SWFObject.js til å bygge inn swf-fil, har du lykke: Vi skal bruke SWFObject.js-typen for å legge inn omdirigering til ikke-Flash-nettsiden. Hvis noen annen form for innlemmingsscenario brukes, må vi slette den gamle koden fra HTML-siden og erstatte den med SWFObject-embedding. Vi skal bruke SWFObject til å omdirigere iPad-besøkende til backup-ikke-Flash-nettstedet.
I denne veiledningen skal vi bruke en treningsside som har SWF-filen som er innebygd ved hjelp av filen AC_RunActiveContent.js. Hvis vi åpner FlashWebsite.html siden i en nettleser, ser vi den kjente SWF-filen som er innebygd på siden.
La oss åpne siden FlashWebsite.html i et tekstredigeringsprogram eller en spesialisert HTML-editor.
Vi bør huske eller skrive ned den viktige informasjonen om vår SWF-fil, for eksempel navnet sitt (FlashWebsite.swf i vårt eksempel), bredde (800), høyde (580) og bakgrunnsfarge (#FFFFFF).
La oss nå erstatte linjen som refererer til filen AC_RunActiveContent.js i
stikkord:med denne linjen:
Vi har nå opprettet referansen til SWFObject-biblioteket.
La oss finne en kode som ser slik ut:
Vi velger den delen av koden og sletter den. Det vi har nå er tomt Under denne taggen, la oss lime inn følgende: Vær oppmerksom på at argumentet i parentes for parameteren som er lagt til Merk: Det femte argumentet i parentesene i SWFObject-funksjonen, "9", refererer til hovedversjonen av Flash-spilleren. Når det ikke er særlig viktig, foretrekker jeg å gi weblesere litt slakk og ikke kreve den nyeste versjonen av Flash-spilleren, så jeg stiller den her til 9, selv om den nåværende versjonen i dag (2010) er 10. La oss lagre HTML-siden og åpne den i en nettleser. Det skal se slik ut. Så langt synes ingenting å ha endret seg. Flash-animasjonen spilles når den er innebygd med AC_RunActiveContent.js-filen, og den spiller på ganske samme måte nå, og er innebygd med swfobject.js-filen. Hvis vi prøvde å åpne siden med iPad, ville vi fortsatt ikke se noe innhold. La oss legge til to argumenter på slutten av serien av argumenter innenfor parentesene i hovedfunksjonen. Det første argumentet skal være tomt, bare anførselstegnene: "", og det andre argumentet bør være banen til backup-ikke-Flash-nettsiden vi vil omdirigere iPad-besøkende til: "./JavaScriptWebsite.html" Den komplette koden med de to nye argumentene som ble lagt til, skulle se slik ut: Det første, tomme argumentet vi nettopp har lagt til, heter Merk: "./JavaScriptWebsite.html" er den lokale banen til JavaScript-animert backup-siden vi bruker i denne opplæringen. Denne banen vil tillate oss å teste omadresseringen lokalt og på serveren. Når du arbeider med egne prosjekter, kan du angi den absolutte banen til din sikkerhetskopi HTML-side i stedet for den lokale banen eller en lokal bane til en hvilken som helst katalog eller underdomene der du kan velge å være vert for backup-siden. Før du laster opp filene til serveren, bør vi teste omadressering lokalt. For å kunne gjøre det, simulerer vi iPad ved å sette versjonen attributtet til SWFObject til en ikke-eksisterende versjon av Flash-spilleren. La oss gå vill og sette den til en 1000 (den versjonen av Flash-spilleren skal være tilgjengelig en gang rundt 3000 A.D. hvis det går bra med Adobe). Koden skal se slik ut: Ikke glem å lagre filen. La oss nå åpne FlashWebsite.html i en nettleser og se på tittellinjen på nettsiden. I stedet for å si "Flash Website", bør det si "JavaScript-animert nettsted", og den siste delen av nettadressen skal være JavaScriptWebsite.html i stedet for FlashWebsite.html. Gratulerer, vår omdirigering virker: Den ultraavanserte animasjonen du ser i visningsporten din, er ikke ferdig med Flash, men med JavaScript. Det bør se og oppføre seg slik. La oss tilbakestille versionsverdien tilbake til "9". Koden i FlashWebsite.html skal igjen se slik ut: Pass på å lagre filen igjen. Ved å bruke hvilken som helst FTP-klientprogramvare, la oss laste opp følgende filer til en valgt katalog på serveren din: Last opp Skript-mappen som inneholder swfobject.js og fx.js-filer til samme katalog på serveren (for å minne deg om, swfobject.js er filen som gjør det mulig å legge inn SWF og omdirigere, og fx.js-filen er den som tillater du lager og spiller JavaScript-animasjon som brukes i backup-nettsiden som er egnet til å spilles på iPad). Du trenger ikke å laste opp AC_RunActiveContent.js også i Skript-mappen til serveren din, selv om du ved et uhell har gjort det, vil den filen på ingen måte forstyrre ytelsen til alle de andre filene du har lastet opp. Her kommer det, sannhetens øyeblikk! Brann opp iPad-nettbrettet ditt og få tilgang til FlashWebsite.html-siden lastet opp til serveren din. Voilà! Du bør se JavaScript-Animated mockup-siden i stedet for Flash-siden. Vi har bare iPad-proofed et Flash-nettsted. Du har nettopp lært en av mulige måter å iPad-proof et eksisterende Flash-nettsted. Det er mange måter som det målet kan oppnås, og ikke alle involverer automatisk omdirigering. Jeg vil gjerne be deg alle om å dele dine ideer om temaet for iPad-proofing Flash-nettsiden i kommentarene til denne opplæringen. Takk for at du leser!
so.write ( "container")
) samsvarer med navnet på det tomme
xiRedirectUrl
, og den brukes av SWFObject-skript for å omdirigere brukere som fullfører ExpressInstall-oppgraderingen. Vi bruker ikke ExpressInstall her, så vi lar argumentet tomt. Det andre argumentet, kalt redirectUrl
, brukes av SWFObject til automatisk omdirigering av brukerne som ikke har den nødvendige versjonen av en Flash-spiller installert - noe som akkurat er den funksjonen vi trengte hele tiden. iPad-nettbrettet har ingen versjon av Flash-spilleren installert, slik at den kvalifiserer!
Trinn 4: Test omadresseringen lokalt
Trinn 5: Last opp filer til en server
Trinn 6: Test omdirigering med iPad
Konklusjon