Nutitelefoni kasutuskogemuse valimiseks on kolm võimalust: operaatori, seadme ja rakenduste kaupa. Operaatori valimisel on kõigepealt teie mobiilsideteenuse kvaliteet, samas kui seadme põhjal otsuse langetamine tähendab, et olete kindel platvormi kasutamise ja riistvara funktsioonide järele. Kuid rakenduste järgi valimine võib olla keerulisem.
Praegune mobiilsete ökosüsteemide massiiv on killustatud ja ühtne kogu platvormil. Mõned suuremad rakendused on saadaval paljudel platvormidel, nagu ka väiksemate arendajate rakendused. Teised rakendused on platvormile eksklusiivsed nii operatsioonisüsteemile ainuomaste funktsioonide kui ka arendaja ressursside piirangute tõttu. Kuid kui teil on seda ühte rakendust tõesti vaja, siis pole operaatoril või seadmel nii palju tähtsust.
Aga mis siis, kui kõik rakendused võivad olla saadaval kõigil platvormidel? Kas platvormidevaheline arendus peaks arendajatele muret tundma ja kas selle tegemisel tuleb silmitsi seista? Kas on parem ehitada rakendus spetsiaalselt igale platvormile või tuleks rakendus ehitada platvormiülese veebipõhise raamistikuga?
Nii kasutajad kui ka arendajad võivad nõustuda, et rakenduse kättesaadavus platvormist olenemata on suurepärane ideaal. Aga mis hinnaga?
Alustame vestlust!
Tegelikkuses on küsimus keerulisem. Enamasti on "järgmise suure asja" loonud üks tõeliselt andekas arendaja või väike meeskond, kellel pole lihtsalt ressursse, oskusi ega võimeid platvormidevahelise programmeerimiseks. Nägime seda varakult Instagrami ja Androidiga - rakenduse taga olnud ettevõttel oli kuulsalt ainult 13 töötajat. Sellised piirangud lükkasid Android Instagrami rakenduse mõnda aega edasi ja isegi nüüd pärast selle ostmist Miljardi dollari eest pole Facebook endiselt välja andnud rakendust, mis ühilduks BlackBerry 10 või Windowsiga Telefon.
Platvorm peab sageli tabama mõnda nähtamatut ja mitmetähenduslikku mõõdikut, mille järgi mass peab seda "aktsepteerituks".
Väikesed ettevõtted pole siin üksi, kuna näeme sageli, et massimeediaettevõtted kõhklevad platvormidevaheliste rakenduste loomisel. Kõnealune platvorm peab sageli tabama mõnda nähtamatut ja mitmetähenduslikku mõõdikut, mille järgi mass peab seda "aktsepteerituks", ja alles siis kaaluvad ettevõtted sellele rakenduse tegemist. Mõnikord ehitavad arendajad, kes on konkreetse operatsioonisüsteemi fännid, kõigepealt selle platvormi jaoks rakenduse, isegi kui hiiglaslikku turuosa seal pole. See juhtus Windows Phone'i ametliku rakendusega Disqus, mis oli esimene (ja seni ainus) mobiiliplatvorm, mis sai kommenteerimisteenuse kaudu ametliku rakenduse.
Nii et jah, ettevõtted peaksid alati püüdma platvormiüleselt minna, kui nad saavad, ja kui ei suuda, peaksid nad selle kogukonna arendajate poole pöörduma, et nad saaksid partnerlust töötada. Foursquare tegi seda siis, kui arendaja Zhephree tegi 2009. aastal iseseisvalt veebi jaoks Foursquare'i rakenduse ja rakendusest sai platvormi jaoks tegelikult Foursquare'i rakendus. Kahjuks on see haruldane juhtum ja liiga sageli satuvad tarbijad rakenduste valikutesse, mis ei sisalda uusimat ega parimat lihtsalt nende mobiiliplatvormi valiku tõttu.
Kas platvormidevaheline programmeerimiskeel nagu HTML5 või Unity mängimiseks aitaks? Standardid on kindlasti paremad kui kaos, ehkki nagu HTML5-ga siiani nägime, on see olnud pigem hüpe kui edu.
WIgast reeglist on erandeid, ma tahan tõesti elada maailmas, kus enamik mobiilirakendusi on platvormidevahelised ja töötavad lihtsalt siis, kui ja kuhu ma neid tahan. Võtame näiteks veebi. Ma pääsen peaaegu igale veebisaidile peaaegu igast turul olevast seadmest. Facebooki veebisaidil pole vahet, kas ma kasutan Maci või Windowsi arvutit, nutitelefoni või tahvelarvutit, Androidi või BlackBerry 10.
Niikaua kui platvormil on kaasaegne veebibrauser, pääsen peaaegu igale soovitud saidile. Ma saan veebisaidi ehitada ja juurutada kõikidesse seadmetesse ja kõik näevad seda. Enamasti, kui sait järgib standardeid, siis see tõesti "lihtsalt töötab".
Platvormidevaheliste mobiilirakenduste olek on üsna erinev.
Võtke Android Central, CrackBerry, iMore ja Windows Phone Central. Saidid kasutavad väga sarnast koodi ja töötavad enamikus laua- või mobiilibrauserites. Neli veebisaiti, kõik brauserid. Hea tehing.
Kuid rakendustega rakendamine tähendaks Androidi, BlackBerry 10, iOS ja Windows Phone jaoks eraldi, oluliselt teistsuguste raamistike kasutamist kõigi saitide rakenduste jaoks. Neli rakendust korda neli platvormi kokku kuusteist rakendust. Pole nii hea tehing.
Sama võib öelda ka lisaseadmete kohta, mis toetuvad ühendatud rakendustele. Nike + FuelBand lansseeriti ainult iOS-iga, kuid Nike riistvarasse paigutatud investeeringute jaoks toetaksid nad ideaalis kõiki platvorme. Paljud mitte-iOS-i kasutajad oleksid võinud selle osta 2012. aasta pühadeks, kuid see, et FuelBand ei toetanud ega toeta teisi platvorme, piirab tema potentsiaalset turgu. Kasutajaid ei huvitaks platvormidevaheline - oluline oleks ainult see, et see töötaks nende seadmega.
Loodan, et HTML5 on piisavalt võimas ja paindlik, et saaksite selles luua peaaegu kohalikke rakendusi. Ja kui see nii on, siis eelistaksin HTML5-d.
- Leo LaporteTWiT juht, TWiT.TV
Keegi ei taha BlackBerry 10-s rakendust, mis näeb välja täpselt nagu iOS-is, ja mis ei sisalda BlackBerry 10 žestide tuge.
Mängud on selles platvormidevahelisel mootoril nagu Unity ja Titanium sageli kõige kaugemal ees. Mängudel on aga tavaliselt oma platvormile mittevastavad liidesed. Mänguvälised rakendused on erinevad. Kuigi rakendused saavad platvormide vahel jagada ühiseid funktsioone, teenuseid ja isegi koodi, vajavad nad platvormi ilmet ja tunnet ning saavad platvormispetsiifilistest funktsioonidest kasu. Keegi ei taha BlackBerry 10-s rakendust, mis näeb välja täpselt nagu iOS-is, ja mis ei sisalda BlackBerry 10 žestide tuge.
Lõppkokkuvõttes, kui võtate platvormi omanikud, tootjad ja isegi arendajad võrrandist välja, tahavad inimesed lihtsalt armastatud rakendusi armastatud seadmetes. See tähendab, et iga suurem rakendus peab toetama kõiki suuremaid platvorme. Nüüd.
Tteoreetiliselt peaks kõigil platvormidel samade äppide olemasolu olema mõttetu, eks? Rohkem rakendusi rohkemates kohtades. Kuid pettumust valmistav tõde on see, et isegi täna pole kõik rakendused võrdsed.
Erinevad platvormid teevad asju erinevalt. Mõnikord on asi riistvaras. BlackBerry 10 ja Windows Phone ei oma Androidi puhast töötlusvõimsust. Apple'i iOS-i on vaieldamatult lihtsam välja töötada ja sellega saab vähemaga rohkem hakkama. Nii et iPhone'i ja iPadi jaoks saadaval oleval rakendusel võib olla erinev funktsioon kui Androidil, BlackBerry 10 või Windows Phone'il. Tegelikult oleme näinud populaarseid rakendusi, mis ühelt platvormilt teisele teisaldades kaotavad olulise osa oma funktsionaalsusest.
Pettumust valmistav tõde on see, et isegi täna pole kõik rakendused võrdsed.
See pole aga alati nii sügav. Mõnikord on küsimus ainult välimuses. Võib-olla ei näe rakendus lihtsalt ühel platvormil nii hea välja kui teisel. Pindmine? Võib-olla. Rakendustel peaks olema platvormidel ühtlane kogemus. Või vähemalt proovida saada sama kogemust. Kuid neil peab olema ka platvormikogemus. See on karm juukselõhe.
Hea uudis on see, et rakendused on voolavad loomad. Nad muutuvad ja paranevad pidevalt. Tõenäoliselt mitte nii kiiresti, kui meile kõigile meeldiks, kuid harva on populaarne rakendus, mida kunagi ei värskendata, ei paranda ega kujundata ennast kunagi ümber.
HTML5 rakendused on loodud veebistandardite abil, näiteks HTML, CSS ja JavaScript. Neid rakendusi käitatakse brauserites, nagu Google Maps või iCloud.com, või kohalikes seadmetes, nagu Chrome OS või hiline, hädaldav veebOS. Kuna nii paljud arendajad juba teavad, kuidas luua rikkalikke veebikogemusi, eeldatakse üldjuhul, et HTML5-rakendused on lihtsaim tee nende arendajate mobiilile viimiseks. Siit alates Apple'i algsest "magusast" rakenduste lahendusest iPhone'i brauseris kuni Palm's Mojo ja hiljem Enyo raamistikeni kuni BlackBerry WebWorksini.
Sellest tuleneb üldiselt mitte arendajate eeldus, et HTML5 on viimane, parim lootus utoopilisse tulevikku, kus rakendused on üks kord kirjutatud ja kasutusel kõikjal, platvormidevaheliselt, töölaualt tahvelarvutile telefonini ning kõigele ja kõigele, mis seal sees on vahel.
Ja see on hunnik BS-i.
Apple'i originaalne "magus" lahendus töötas nii halvasti, et nad leidsid aasta hiljem välja emakeelse App Store'i, veebirakenduse kalendrirakenduse 1.0 kulus käivitamiseks kakskümmend sekundit ja Google pakub Androidis ja iOS-is algupäraselt kodeeritud rakendustega palju paremaid kogemusi kui need on võrk. Isegi parimad mobiilsed veebirakendused, nagu Gmail.com jaecast.io, on nende rikkamate, paremini toimivate sugulastega võrreldes kahvatud.
Kohalikud rakendused saavad kasu uuest riistvarast ja uutest raamistikest. Nende edumaa jääb, kui mitte kasvama.
Mõned ütlevad, et kui riistvara muutub võimsamaks ja JavaScripti täiustatakse, suureneb veebirakenduste jõudlus ja funktsionaalsus. See on täiesti tõsi. Kuid kohalikud rakendused saavad kasu ka uuest riistvarast ja uutest raamistikest. Nende edumaa jääb, kui mitte kasvama.
Seetõttu nimetatakse HTML5-rakendusi tulevikuks - need tulevad alati, kuid ei jõua kunagi päris kohale.
Kogu rakenduse proovimine HTML5-s teha on nagu kogu rakenduse loomine, mis eksisteerib lennukirežiimis täiesti võrguühenduseta. See pole võimatu, kuid pole ka ideaalne ning piirab oluliselt pakutavat ulatust ja kogemusi.
Kui HTML5 muutub kunagi levinumaks kui kohalikud rakendused, on see maailm, milles ma ei taha elada.
- Matt Bischoff ja Brian Capps,iOS-i insenerid, Lickability
See taandub sellele: internet on parim dünaamiliste andmete pakkumisel ja kohalikud rakendused kõige paremini liidese ja interaktiivsuse jaoks. Suurepärased rakendused kasutavad mõlemast parimat. Nagu iTunes. Nagu Google Maps Androidile ja iOS-ile. Nagu uus mobiilse Facebooki omakeelne versioon (isegi Facebook õppis selle õppetunni raskelt).
HTML5 ei ole mingil juhul rakenduste kõikehõlmav tulevik. Kuid see on selle tuleviku uskumatult oluline osa.
Cross-platvormi rakendused on keeruline ettevõtmine. Arendajad peavad navigeerima SDK-des ja API-des ning UI- ja UX-juhistes, püüdes säilitada oma rakenduse ainulaadset välimust, funktsioone ja kasutuskogemust. See on nõuete ja soovide, ootuste ja piirangute tasakaalustamine.
Ideaalis oleksid rakendused, millel on mõttekas olla platvormiülene, ja seda oleks lihtne teha. Kuid see on tippturg ja suuremate platvormiomanike huvi rakenduste loomise lihtsustamise vastu on väike mis töötab konkurentide seadmetes, samas kui väiksemad mängijad soovivad muuta nende võimalikult lihtsaks teisaldamise rakendused.
Platvormidevahelised raamistikud ja tööriistad on olemas, kuid nende ulatus ja võimsus on piiratud. Need hõlbustavad kõigi platvormide jaoks ühtse kogemuse loomist, kuid ohverdavad selle, mis muudab iga platvormi ainulaadseks ning kompromissiks kvaliteedi ja jõudluse osas. Kuid platvormile kohandatud rakenduste loomine võtab aega ja raha, mida kõigil arendajatel pole.
Head vastust pole - aga mis on parim?