Innhold
- 1. En innebygd nettvisning er ikke en nettleser
- 2. Den resulterende navigasjonen vil være et kompromiss
- 3. Tverrplattform er ikke engang et "edelt mål"
- 4. Du må kjempe med plattformen
- 5. For godt til å være sant
En kortere versjon av denne artikkelen dukket først opp i nummer 238 av .net magazine - verdens mest solgte magasin for webdesignere og utviklere.
XVT, wxWindows, Gtk, AWT, SWT. Disse ringer noen bjeller? De er bare noen av verktøysettene som loves, bruker muligheten til å skrive kode på en plattform, og produserer applikasjoner som kjører sømløst på Windows, Mac og X Windows.
Noen var bedre enn andre; men de hadde alle en ting til felles:
Søknader skrevet i dem sugde.
Til deres ære er det det eneste stedet der kryssplattformløftet faktisk virket - applikasjoner skrevet i dem suges konsekvent over plattformer.
Før du påpeker noe uklart program som var halvt anstendig, snakker jeg om gode applikasjoner. Det har aldri vært en eneste, kommersielt vellykket, flott applikasjon skrevet med en verktøysett på tvers av plattformer.
Og nå blir vi tilbudt disse løftene om å utvikle "skriv en gang kjør hvor som helst" -apper for iOS, Android og Windows Mobile. Visst, det er en kostnadseffektiv måte å være til stede overalt, men her vil det svikte deg.
1. En innebygd nettvisning er ikke en nettleser
De fleste mobile verktøysett på tvers av plattformer er avhengige av HTML5 for å gi beinene til appen din, og appen blir gjengitt i en innebygd nettbeholder. Dette ignorerer et viktig poeng: ja, nettet er en agnostisk plattform for plattform, men når vi bruker nettapper, pleier vi å bruke nettleserens krom for navigering. Det er derfor det er kjent for oss.
Men når en mobilapp på tvers av plattformer er innebygd i en nettbeholder, er appens HTML ansvarlig for navigering. Våre kjente kontroller er borte, og i stedet får vi et navigasjonssystem som typisk er modellert etter den dominerende plattformens utseende.
2. Den resulterende navigasjonen vil være et kompromiss
Så du bruker HTML, og du har bestemt deg for å kode koden for navigering. Slik går det vanligvis. Flertallet av brukerne er (la oss si) iOS-brukere; så vi utvikler den med en svart fanelinje nederst og etterligner iOS-fanestilstilen.
IOS-brukeren hater det; du har ikke klart den subtile fargeforandringen når du tapper på fanen, eller hoppet til den øverste skjermen når du dobbeltklikker.
Android-brukeren hater det fordi han enten aldri har sett det, så det er ukjent, eller verre, han vet at det er et "iPhone-lignende" grensesnitt og er ikke glad for at det blir betjent av Android-brukere.
3. Tverrplattform er ikke engang et "edelt mål"
I dagers tid hadde vi kanskje en PC på jobben og en Mac hjemme. Vi har kanskje hatt behov for å bruke visse verktøy i begge; dette var lokket til å ha en applikasjon kjørt på begge; men med smarttelefonene våre er livet annerledes. De aller fleste brukere har en enkelt telefon. Brukere vil ha konsistens med andre apper på enheten sin, ikke konsistens med en annen versjon av appen din på en annen plattform de ikke har tenkt å bruke.
4. Du må kjempe med plattformen
Når en verktøysett frigjøres for å fungere på flere plattformer, gjør verktøysettleverandøren tungt for å sørge for at noe fungerer på alle plattformer. Dette betyr faktisk at de i beste fall kan implementere ’laveste fellesnevner’ funksjonalitet. Hvis funksjon X fungerer bra på Android, men ikke kan gjøres elegant på iOS, vil den ikke gjøre det.
Dette er greit hvis appfunksjonaliteten din er grunnleggende; men hva skjer hvis du trenger noe som ikke lett gjøres innenfor disse rammene? Vel, dette er når verktøysettet begynner å hindre fremgangen din, ikke hjelpe det.
Du kan finne noen fine 'utvidelser' for verktøysettet som gjør funksjonen Y enkel å gjøre på iOS; men nå har du nettopp begynt å skrive plattformspesifikk kode, og alle de lovede fordelene har gått.
5. For godt til å være sant
Apple, Microsoft, Google: de største programvareselskapene i verden, som har de beste hjernene, som har lagt ned mye arbeid på å gjøre plattformopplevelsen fantastisk for sine sluttbrukere. Og du tror at et verktøysett og noe fancy JavaScript kan gjøre en bedre jobb?
Lokket med å være på hver plattform med ett museklikk vil være musikk i ørene til administrerende direktører og økonomidirektører; enkelheten i det utsagnet skjuler virkeligheten. Den innrømmer ikke den understandardiserte appen; dårlige anmeldelser vil få konsernsjefens blod til å koke, og økonomidirektøren vil ikke være glad for at han skal betale for en grunnleggende omskriving. Gjør deg selv en tjeneste og bevæpne dem med fakta.
Utvikling naturlig på hver plattform gir deg den raskeste mulige appen, full tilgang til enhetens evner og rammer for å lette utviklingen; native SDK er den eneste måten å garantere den beste brukeropplevelsen.
Gå over til Creative Bloq for 25 profesjonelle tips om mobilnettdesign!
