Inhoud
- 1. Een ingebedde webweergave is geen webbrowser
- 2. De resulterende navigatie zal een compromis zijn
- 3. Platformoverschrijdend is niet eens een 'nobel doel'
- 4. Je zult moeten vechten met het platform
- 5. Te mooi om waar te zijn
Een kortere versie van dit artikel verscheen voor het eerst in nummer 238 van .net magazine - 's werelds best verkochte tijdschrift voor webdesigners en -ontwikkelaars.
XVT, wxWindows, Gtk, AWT, SWT. Ringen deze klokken? Het zijn slechts enkele van de toolkits die beloofden de mogelijkheid te gebruiken om code op één platform te schrijven en applicaties te produceren die naadloos werken op Windows, Mac en X Windows.
Sommige waren beter dan andere; maar ze hadden allemaal één ding gemeen:
Toepassingen die erin waren geschreven, waren slecht.
Het is hun verdienste dat het de enige plek is waar de platformonafhankelijke belofte echt werkte - applicaties die erin waren geschreven, werden consequent over platforms gezogen.
Voordat je een of andere obscure applicatie aanwijst die half fatsoenlijk was, heb ik het over geweldige applicaties. Er is nog nooit één commercieel succesvolle, geweldige applicatie geschreven met behulp van een platformonafhankelijke toolkit.
En nu krijgen we deze beloften aangeboden om ‘write once run anywhere’ -apps voor iOS, Android en Windows Mobile te ontwikkelen. Het is natuurlijk een kosteneffectieve manier om overal aanwezig te zijn, maar hier is waarom het u in de steek zal laten.
1. Een ingebedde webweergave is geen webbrowser
De meeste mobiele platformonafhankelijke toolkits vertrouwen op HTML5 om de botten van uw app te leveren, waarbij de app in wezen wordt weergegeven in een ingesloten webcontainer. Dit negeert een belangrijk punt: ja, het web is een platformonafhankelijk platform, maar bij het gebruik van webapps gebruiken we meestal het Chrome van de browser voor navigatie. Daarom is het ons bekend.
Wanneer een platformonafhankelijke mobiele app echter is ingesloten in een webcontainer, is de HTML van de app verantwoordelijk voor de navigatie. Onze vertrouwde bedieningselementen zijn verdwenen en in plaats daarvan krijgen we een navigatiesysteem dat typisch is gemodelleerd naar de look en feel van het dominante platform.
2. De resulterende navigatie zal een compromis zijn
U gebruikt dus HTML en u heeft besloten de navigatie met de hand te coderen. Hier is hoe dat doorgaans gaat. De meerderheid van de gebruikers zijn (laten we zeggen) iOS-gebruikers; dus we ontwikkelen het met een zwarte tabbalk onderaan en bootsen de iOS-tabbalkstijl na.
De iOS-gebruiker haat het; je bent er niet in geslaagd de subtiele kleurverandering wanneer op het tabblad wordt getikt, of de sprong naar het bovenste scherm als er dubbel wordt getikt.
De Android-gebruiker haat het omdat hij het nooit heeft gezien, dus het is onbekend, of erger nog, hij weet dat het een "iPhone-achtige" interface is en is er niet blij mee dat het wordt opgedrongen aan Android-gebruikers.
3. Platformoverschrijdend is niet eens een 'nobel doel'
Vroeger hadden we misschien een pc op het werk en een Mac thuis. Het kan zijn dat we bepaalde tools in beide moeten gebruiken; dit was de verleiding om een applicatie op beide te laten draaien; maar met onze smartphones is het leven anders. De overgrote meerderheid van de gebruikers heeft één telefoon. Gebruikers willen consistentie met andere apps op hun apparaat, niet consistentie met een andere versie van uw app op een ander platform dat ze niet van plan zijn te gebruiken.
4. Je zult moeten vechten met het platform
Wanneer een toolkit wordt vrijgegeven om op meerdere platforms te werken, doet de toolkitverkoper het zware werk om ervoor te zorgen dat iets op alle platforms werkt. Dit betekent eigenlijk dat ze in het beste geval de ‘kleinste gemene deler’ -functionaliteit kunnen implementeren. Als functie X goed werkt op Android, maar niet elegant kan worden gedaan op iOS, haalt het het niet.
Dit is prima als de functionaliteit van uw app eenvoudig is; maar wat gebeurt er als je iets nodig hebt dat niet gemakkelijk binnen deze grenzen kan worden gedaan? Welnu, dit is wanneer de toolkit uw voortgang begint te belemmeren, niet helpt.
Wellicht vindt u een aantal leuke ‘uitbreidingen’ voor de toolkit waardoor functie Y gemakkelijk te doen is op iOS; maar nu ben je net begonnen met het schrijven van platformspecifieke code en zijn alle beloofde voordelen verdwenen.
5. Te mooi om waar te zijn
Apple, Microsoft, Google: de grootste softwarebedrijven ter wereld, met de beste hersens, die veel moeite hebben gedaan om hun platformervaring geweldig te maken voor hun eindgebruikers. En denk je dat een toolkit en een beetje chique JavaScript het beter kunnen doen?
De aantrekkingskracht om met één muisklik op elk platform te zijn, zal CEO's en CFO's als muziek in de oren klinken; de eenvoud van die verklaring verbergt de realiteit. Het geeft niet toe aan de ondermaatse resulterende app; Slechte recensies zullen het bloed van de CEO doen koken, en de CFO zal niet blij zijn dat hij betaalt voor een oorspronkelijke herschrijving. Doe jezelf een plezier en wapende ze met de feiten.
Door native te ontwikkelen op elk platform, krijgt u de snelst mogelijke app, volledige toegang tot de mogelijkheden van het apparaat en frameworks om de ontwikkeling te vergemakkelijken; native SDK's zijn de enige manier om de beste gebruikerservaring te garanderen.
Ga naar Creative Bloq voor 25 ontwerptips voor professionele mobiele websites!
