Mobiele ontwikkelaars willen webapps maken

De meeste ontwikkelaars willen webapps maken voor smartphones. Dat blijkt uit een enquête onder meer dan 2500 ontwikkelaars. De interesse in ontwikkeling voor de iPhone en iPad blijft het grootst, Android volgt op korte afstand.

Ongeveer 42 procent van de ondervraagden wil zowel native applicaties als webapps maken, blijkt uit de enquête van Appcelerator. Daarnaast wil 10 procent alleen werken aan mobiele websites, blijkt uit de vragenlijst. De redenen daarvoor zijn divers: webapps zijn doorzoekbaar voor zoekmachines (32 procent), je hebt geen 'app store lock-in' (45 procent), ontwikkeling gaat snel (52 procent) en ontwikkelen voor webapps maakt gebruik van technieken die ik al ken (60 procent).

De belangrijkste reden is echter dat webapps cross-platform zijn (69 procent). Ontwikkelaars maken zich namelijk zorgen om versnippering van de smartphonemarkt. Dat maakt niet alleen de ontwikkeling lastiger, maar vereist ook dat ontwikkelaars met verschillende programmeertechnieken werken. Voor iOS is bijvoorbeeld Objective C vereist, terwijl Android werkt met Java en Windows Phone 7 gebruikmaakt van Silverlight en XNA.

Ontwikkelaars hebben nog altijd een voorkeur voor Apple-producten. Ze programmeren volgens de enquête het liefst voor iPhone (91 procent) en iPad (86 procent). Android-telefoons (85 procent) volgen op korte afstand, terwijl Android-tablets de interesse hebben van 71 procent van de ontwikkelaars. De interesse in Windows Phone 7 en BlackBerry OS nam af tot respectievelijk 29 en 27 procent van de ondervraagde ontwikkelaars. De BlackBerry-tablet PlayBook heeft de interesse van 20 procent van de ondervraagden. Symbian en MeeGo wekken de minste interesse: 7 en 5 procent.

Reacties (59)

[serhat]

Ah een onderzoek van Appcelerator. Zij hebben het product Titanium. Daarmee kan je in HTML5/CSS/Javascript proggen om native Android/iOS applicaties te 'genereren'. Of het ook zover gaat komen met het gebruik van de Cross-Platform Frameworks weet ik niet. De meeste OS functionaliteit kun je dan via de Titanium API bereiken (via Javascript vaak). Daar blijft het niet bij. Mocht er bepaald functionaliteit niet bestaan kan je het zelf schrijven als een soort van plugin. Echter betekent dit natuurlijk wel dat je dit per OS wilt doen waar je het op wilt kunnen draaien.

Zo zijn er ook alternatieven hierop. Zoals PhoneGap en als ik me niet vergis nog een paar. Nadeel van PhoneGap is in dit geval dat het echt ook uitziet als een webapp. Ik heb er onlangs mee geprogrammeerd.

Persoonlijk zit ik tussen native en cross-platform in, in dit geval. Ik zie de voordelen van beide en de nadelen. Ik zou persoonlijk wel voor Titanium gaan mits ik echt cross-platform zou moeten developen omdat deze toch de native widgets van de OS gebruikt.

Vergeet niet dat als er nieuwe API's zijn voor bijvoorbeeld Android en iOS en je wilt hier gebruik van maken in een van de Cross-Platform Frameworks je het of zelf moet maken of moet wachten totdat het geüpdate wordt. Ik heb zo geen flauw idee of dit vrij snel gaat op het moment.

[EDIT]
Ik lees dat mensen het hebben over bepaalde functionaliteit waar ze niet bij kunnen in een browser. Je schrijft het in HTML/.Javascript/CSS, maar dat hoeft niet direct te betekenen dat het echt is beperkt tot de functionaliteit van een browser. Zo kan je d.m.v. Javascript listeners activeren voor de sensoren en kan je ook d.m.v. Javascript calls ook notifications creeeren etc. Het zal dan wel zo zijn dat hij bijv. in Android een notification in je bar zet en bij iOS dat je een melding krijgt zoals dat gebeurt als je een SMS krijgt.
Het is dus echt niet beperkt tot functionaliteit van een browser. Zo zou je zelfs je camera kunnen gebruiken.

Als je zover zou gaan zou ik je wel aanraden om de API te bekijken van de Cross-Platform Framework. Hier kan redelijk wat verschil inzitten. Ook de OS'en die ze ondersteunen verschillen. PhoneGap ondersteunt bijv. naast Android en iOS bepaalde BlackBerry's en zelfs Symbian als ik me zo niet vergis.

[Reactie gewijzigd door serhat op 24 juli 2024 07:09]

[Verwijderd]

Ik ben op dit moment voor mijn afstuderen bezig met een web applicatie voor smartphones/tablets. Na wat onderzoek en rondspeuren ben ik uiteindelijk op het JQuery Mobile framework gestuit (http://jquerymobile.com/). Dit framework is gebaseerd op JQuery en JQueryUI en hiermee is het mogelijk om de web applicatie er uit te laten zien en te laten werken als een echte native applicatie .
JQuery Mobile zit op dit moment nog wel steeds in de ontwikkelfase dus er zitten hier en daar nog een paar bugs in.

[Melodic Metal]

Wat ook heel mooi werkt is Extjs / Sencha Touch.

Iets meer javascript, maar perfect voor bijv. de Ipad.

[jvvj]

inholland?

[418O2]

Als frontenddeveloper kan ik het hier alleen maar mee eens zijn. Waarom op 1 platform focussen als je iets kan opzetten dat op een android telefoon of tablet, iOs device, Blackberry telefoon of tablet etc etc werkt?

Naast alle 'hustle' om alles in elke appstore te krijgen, bespaart het je ook een hoop tijd omdat je je niet hoeft te verdiepen in alle beschikbare SDK's.

[Reactie gewijzigd door 418O2 op 24 juli 2024 07:09]

[_Thanatos_]

Maar iets "simpels" als een woordenboek zou ik toch echt niet als webapp willen zien. Het is flauwekul om zoiets puur online te doen, want een woordenboek gebruik je op vakantie en op vakantie is mobiel internet schreeuwend duur. Dus heb je een lokaal databaseje. Dat kan allemaal wel met een offline webapp, maar daar wel weer allerlei mitsen en maren aan (zoals maximum grootte).

Ook "social" apps gaan hier de mist in, omdat je ze niet meer kunt registreren (middels de installer van het toestel) als "share" service. Bijvoorbeeld een url sharen naar delicious als je een delicious-app hebt.

Veel dingen gaan echter uitstekend als webapp. En ik als mede-fronteer juich het dan ook toe om het te doen. Maar alléén als het zinnig is. "webapp" moet niet de default worden.

[cmegens]

Ehm, want webapps kunnen niet lokaal draaien? Ik geloof dat WebOS volledig gebaseerd is op HTML, dus dat kan blijkbaar toch prima..

[_Thanatos_]

WebOS heeft dan wel een heel framework eromheen waar je op moet bouwen. Met allerlei extensies om bij systeemvoorzieningen te komen. Een mobiel OS waarbij webapps niet de primaire manier van apps maken is, zijn systeemvoorzieningen op dezelfde manier verborgen en/of geabstraheerd als op je desktop.

WebOS is dus de uitzondering, niet de standaard

[perentaart]

Dat is zo, maar het is wel lastig gebruik te maken van bepaalde functionaliteiten. Zo kan ik bijvoorbeeld geen media uploaden via de browser op een iDevice.

[TERW_DAN]

Maar daar kun je APIs voor gebruiken als het apparaat die functionaliteit wel gebruikt. Als het spul maar goed gedocumenteerd is dan kun je door zelf een API te schrijven heel generiek te werk gaan. Ik ben er laatst mee bezig geweest voor bepaalde embedded apparaten en als je het maar generiek genoeg opzet is het een eitje om het dan uit te breiden over meerdere platforms, mits die natuurlijk overweg kunnen met de functionaliteit die je aan wil roepen.
Als je dat slim doet dan kun je 1 applicatie bouwen die zowel op je PC, je telefoon, een tablet en andere embedded apparaten werkt. Je loopt wel tegen beperkingen aan natuurlijk, maar als je die van tevoren goed in kaart brengt dan kun je er alsnog bijna alles mee doen.

[paulus83]

Die theorie klinkt heel leuk, maar voor mobiele platformen is hij niet toepasbaar. Zoals in het artikel al is aangegeven, vereisen de verschillende platforms ook allemaal een andere programmeertaal. Tenzij jouw 'api' stiekem een emulator is, wat bijvoorbeeld door Apple al niet is toegestaan, moet je nog steeds je code voor elk platform apart schrijven. Bovendien, het maken van een multiplatform api vereist hoe dan ook een erg grote hoeveelheid werk en platform kennis, zodat het voor één enkele app niet rendabel is. En mocht je toch eindelijk je eigen mooie api hebben met eigen runtime, moeten der programmeurs die hem willen gebruiken toch nog weer een nieuwe taal/omgeving leren. Dan is gewoon html gebruiken toch een stuk makkelijker!

[TERW_DAN]

Die theorie klinkt heel leuk, maar voor mobiele platformen is hij niet toepasbaar. Zoals in het artikel al is aangegeven, vereisen de verschillende platforms ook allemaal een andere programmeertaal.

Daarom bouw je zoiets als webapplicatie, dan boeit het platform waar je op draait al niet zo heel veel meer, zolang je maar een browser hebt. En als je een browser hebt, dan kun je alles netjes in HTML + script maken, zolang je browser dat maar ondersteunt zit je goed. Je hebt totaal niets te maken met architecturen.
Ik werk hier met de nodige Broadcomchips, ik heb werkelijk geen idee wat voor architecturele verschillen daar precies inzitten als ik het vergelijk met m'n X86 CPU's, maar dat maakt me niet uit. Ik kan er gewoon standaard HTML + Javascript op draaien, die browser op het betreffende apparaat zorgt er wel voor dat het werkt zoals het moet werken op die architectuur.

Tenzij jouw 'api' stiekem een emulator is, wat bijvoorbeeld door Apple al niet is toegestaan, moet je nog steeds je code voor elk platform apart schrijven

Nee, het is juist geen emulator. Je gebruikt de API alleen om bepaalde functies op de juiste manier aan te roepen.

Om een voorbeeld te geven. Stel ik wil een filmpje afspelen. Wil ik dat doen met applicatie X dan kan ik gewoon zeggen x.play(url), en dan speelt het ding af. applicatie Y zal iets anders willen, die wil bijvoorbeeld iets hebben als y.player.addPlayListItem(url) en dan y.player.playPlayList(); en applicatie Z wil weer wat anders.
Als je die API niet zou gebruiken, dan bouw je dus je code voor ieder platform apart. Bouw je hier een generieke API voor (of liever, raap je die bij elkaar, door alle beschikbare API's samen te voegen), dan kun je gewoon zeggen 'API.play(url)'. En de API kijkt dan wel op welk device je op dat moment zit en hoe de playfunctie daadwerkelijk aangeroepen moet worden.

Bovendien, het maken van een multiplatform api vereist hoe dan ook een erg grote hoeveelheid werk en platform kennis, zodat het voor één enkele app niet rendabel is.

Niet helemaal waar. Als je in eerste instantie uitgaat van een applicatie die je op een aantal platformen wil draaien dan ben je toch bezig om al die functies te bouwen, dan kun je het beter generiek doen, dat kost je amper meer tijd, zelfs maar voor 1 applicatie. Maar wil je het ding daarna uitbreiden, of verandert er ergens iets, dan hoef je alleen je API aan te passen, niet de applicatie zelf. Komt er een nieuw apparaat bij, zet zorg ervoor dat je daar de juiste API van hebt en het werkt, zonder dat je een letter aan code in je applicatie hoeft te veranderen. En bij het bouwen van meerdere applicaties neemt dit voordeel alleen maar toe.

En mocht je toch eindelijk je eigen mooie api hebben met eigen runtime, moeten der programmeurs die hem willen gebruiken toch nog weer een nieuwe taal/omgeving leren.

Nee, dat hoeven ze dus niet. Sterker nog, de programmeurs van de applicatie (dus niet van de API) hoeven nog minder te doen, die hoeven alleen maar de API aan te roepen, en verder zich 0,0 zorgen te maken over de onderliggende afhandeling ervoor, dat fixed de API.

Dan is gewoon html gebruiken toch een stuk makkelijker!

gewoon HTML doet bijzonder weinig, je zult altijd nog een scripttaal moeten hebben wil je er echt een applicatie van maken. Maar dat is niet makkelijker, het is exact hetzelfde. Programmeurs hoeven geen nieuwe taal te leren, ze hoeven geen nieuwe omgeving te gebruiken, ze hoeven alleen maar te weten hoe de functie heet die ze aan moeten roepen en welke argumenten ze daaraan mee moeten geven. Dat is echt stukken makkelijker als voor ieder apparaat het zelf uit gaan zoeken iedere keer.

[humbug]

Vanuit alle platformen is het mogelijk een webservice te benaderen. Dus de server is generiek. Als je voor webbased mobiele apps kiest, is het ook nog generiek aan de client kant. De vraag was hoe upload ik vanuit een webbased applicatie. Het antwoord is simpelweg je eigen upload webservice bouwen. Appeltje eitje

[poepkop]

In dat geval kan je weer gebruik maken van de dropbox Api of een dergelijke 'file pool'. Dat heeft in ieder geval mijn voorkeur.

[perentaart]

Behalve wanneer je de bestanden op je iDevice hebt staan en je hebt geen toegang tot de cloud.

[PPie]

Hoe ga je 'media uploaden via de browser op een iDevice', als je geen toegang hebt tot die cloud waarnaar je wil uploaden?
Zal niet echt gaan?

[Verwijderd]

'waarvan' je wil uploaden bedoel je...

Neem bijvoorbeeld vacature sites. Als je mobiel met je iPhone / iPad zou willen solliciteren dan wordt meestal gevraagd je CV te uploaden. En dat gaat dus niet omdat je geen local storage hebt (want, elke app draait in een chroot jail waardoor er geen common filesystem is waar je bijvoorbeeld een CV in hebt staan). En dat is toch wel een irritante beperking...

Wat hierboven wordt gesuggereerd is dat je je bestanden bijvoorbeeld op dropbox (of algemener, een cloud storage service) zou kunnen zetten om zo het 'local storage' probleem te omzeilen, en dan via een API zou kunnen benaderen. Om voort te bouwen op het eerder genoemde voorbeeld:

1. je zet je CV in pdf formaat op je dropbox storage
2. je surft naar een vacature site en reageert op een vacature
3. in de CV upload veldje zou je hypotetisch je dropbox folder kunnen opgeven

Maar, dat kan dus niet met iOS aangezien in mobile safari file upload compleet disabled is...

Binnenkort 'zou' Apple een cloud service aan gaan bieden via hun nieuwe North Carolina Datacenter; hopelijk ook met een oplossing voor dit specifieke probleem?

[Reactie gewijzigd door Verwijderd op 24 juli 2024 07:09]

[Verwijderd]

Android heeft overigens hetzelfde probleem; ook daar kun je geen bestanden uploaden via de geintegreerde webbrowser.

Edit: my bad, zie dat het op een Android 2.2 device wel werkt. Maar wel in beperkte mate zo te zien.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 07:09]

[perentaart]

Hmm. Het klonk logischer in mijn hoofd. Fail. Maar grote collectie foto's bewaren, bijvoorbeeld op vakantie, doe ik dan liever op het apparaat in plaats van online. Dan toch wel handig om direct vanuit je browser bij je bestanden te kunnen komen. Raar eigenlijk dat dit nog niet kan.

[bogy]

dat probleem is dan specifiek voor de idevices ..

de droid eheft geen problemen om in de webbrowser bestanden te uploaden...

misschien moet je in een idevice dan eens met een andere browser proberen???

of bij apple aankloppen en vragen dat ze stoppen met alles dicht te gooien en te beslissen wat kan en mag in plaats van de gebruiker???

al begrijp ik ze natuurlijk wel; ze hebben liever dat je een appje verkoopt waarvan ze 30% in hun broekzak kunnen steken zonder iets te doen ...
bij android is dat niet; daar kan je een appje ook online zetten zonder langs google te passeren...

[Mellow Jack]

Sjah of je wilt het makkelijkste voor je bedrijf of je wilt iets makkelijk maken voor je gebruikers

Het ligt er maar net aan wat je doelstelling is... Al is het web je core business (zoals bij Facebook) lijkt het me dom om alleen een web omgeving te maken omdat het toch wat minder werkt dan de native app (die momenteel bij mij crashed maar ik denk dat het door me rom komt ) Is het web een bijzaak voor jou bedrijf dan kan ik mij best voorstellen dat het oprichten van een webomgeving de beste keus is aangezien je niet enorm veel geld aan ontwikkeling wilt gaan besteden

Edit: Als ik de post van Serhat lees dan komt hier wel een klein promotie smaakje naar boven... Dat is toch wel jammer (ongeachte of de cijfers kloppen of niet)

[Reactie gewijzigd door Mellow Jack op 24 juli 2024 07:09]

[humbug]

In veel gevallen werkt een webbased app net zo goed als een native app. Enkel in de gevallen dat je ofwel wilt aansluiten bij de UI (en theme) op een device of specifieke functionaliteit wil gebruiken die enkel native beschikbaar is (zoals het telefoonboek) heeft een native app IMHO echt meerwaarde. Als ik veel van de succesvolle apps van dit moment bekijk zie ik in veel gevallen niet waarom dat perse een app moet zijn.

[Wolfos]

Nouja, CSS is ook niet helemaal hetzelfde cross-platform, maar het is wel beter dan het huidige systeem voor smartphones. Zeker omdat zowel de Android als iOS standaard browsers gebruik maken van WebKit.

[bogy]

en het probleem met webkit browsers is ????

[indigo79]

Ik denk dat Wolfos het juist apprecieerde dat de Android en iOS browsers Webkit gebruiken (versus de totaal verschillende programmeertalen en APIs voor native apps).

[cmegens]

Maar het is een stuk lastiger om iets te verkopen....

[Dark Angel 58]

welke van de 2 verbruikt het meest dataverkeer? mobile apps of web apps?

[RobertMe]

Valt waarschijnlijk niet veel over te zeggen.
Met AppCache is het perfect mogelijk om de volledige WebApp op het device te bewaren. De browser controleert dan ook automatisch of er een update is. Initiële download/installatie gebeurd zowel voor de native app als voor de WebApp maar een keer.

Voor de rest zal het voor een groot gedeelte afhankelijk zijn van de app. Zoals hierboven een voorbeeld staat voor een woordenboek. Met een native app kun je de database op het device plaatsen, terwijl bij een WebApp het waarschijnlijk beter is om een request naar de server te doen. Op het moment dat beide applicaties op dezelfde manier werken (wel of geen requests doen om data op te halen/op te slaan) zal het een beetje afhangen van de gebruikte protocollen. In het geval van een WebApp zal er dan neem ik aan snel gegrepen worden naar AJAX, waardoor je wat overhead hebt van HTTP. Echter zou je ook websockets kunnen gebruiken, waarmee je wel weer een protocol/stream zonder overhead hebt buiten het initieel opzetten van de connectie.

[Sorcerer8472]

Mobile apps zijn vaak sneller, mits ze goed gebouwd zijn: er hoeft geen hele layout te worden opgehaald, want die had je eerder al gedownload. Een nieuws-app hoeft zo alleen xml-teksten en kopjes in te laden omdat de layout door de app zelf afgehandeld wordt.

Zo is de IMDB-app nog best bruikbaar via het trage GPRS, maar moet je dat met de website niet proberen...

[mobstaa]

ik vind het logisch dat iedereen dat wel wil doen, want het is leuk en je kan iets maken wat veel mensen kunnen gaan gebruiken, je zet het in een store en verkoopt het vaak je maakt steeds winst zonder dat je er verder nog werk aan hebt en het ziet er vet uit als je je eigen gadgets hebt

[bobaas]

Waar heb je het over ? Een verschuiving naar webapps zou juist betekenen dat het niet in een store komt te staan maar je er gewoon heen surft. Maar met als groot nadeel dat je geen API's van de telefoon kan gebruiken zoals geolocatie (zie post serhat).
Eigenlijk zou er een open API (bv JS) moeten komen die webapps (dus die via een website geladen worden en niet gecompiled naar een native app) toegang geeft tot hardware api's. Je zou dan wel eerst een domein/url expliciet toegang moeten geven tot die API. Op de iPhone zou dit natuurlijk nooit toegelaten worden..

[RobertMe]

aar met als groot nadeel dat je geen API's van de telefoon kan gebruiken zoals geolocatie (zie post serhat).

Geolocation (opvragen coördinaten) word vaak genoemd in combinatie met HTML5 en word al ondersteund door verschillende (desktop) browsers (geen idee hoe dit bij mobiele apparaten zit, maar lijkt mij daar nog verder geïmplementeerd te zijn dan op de desktop). Er word ook gewerkt aan een "deviceorientation" event, waarmee je dus kompas achtige dingen kunt doen.

Eigenlijk zou er een open API (bv JS) moeten komen die webapps (dus die via een website geladen worden en niet gecompiled naar een native app) toegang geeft tot hardware api's.

Het W3C werkt al een tijdje aan een Devices API. Hiermee moet het o.a. mogelijk worden om toegang te krijgen tot bv. de camera. Maar, zoals op de gelinkt pagina omschreven staat, moet het ook meer interactie met het OS mogelijk maken, om bv. de contacten, of afspraken uit de kalender, op te vragen.

Opera heeft ook al een speciale Android built die ondersteuning heeft voor deviceorientation en het gebruik van de camera. Meer informatie over deze build en de download zijn hier te vinden.

[Reactie gewijzigd door RobertMe op 24 juli 2024 07:09]

[bobaas]

Interessante ontwikkeling. Ik vrees alleen dat het een directe concurrentie aangaat met appstore-apps. En dus niet toegestaan wordt.

[klakkie.57th]

en gelukkig maar ...
Domein/url toegang verlenen tot een api en dat laten we aan de gebruiker over .. het moet niet gekker worden

[bobaas]

Dit kunnen we niet aan de gebruiker overlaten ? Als jij een app installeert bepaal je ook zelf of je wel/niet akkoord gaat met de opgegeven api-toegang(gps/sdcard/contacts). In ieder geval bij Android apps. Dit zou voor webapps op dezelfde manier kunnen gaan.

[humbug]

Webapps kunnen met kleine aanpassingen ook in de AppStore geplaatst worden. Het klaarmaken voor de store kan in principe in een ochtend, mits de Applicatie op zich aan de eisen voldoet

[anchises]

Webapps goed en wel, maar hoe zit het bv met betalingen?

De meeste gebruikers willen niet buiten de app store om aankopen doen.

Werken met een app die betaald is en vervolgens een website oproept (bv met een header value 'paid') lijkt me vragen om copy van een app die diezelfde site oproept maar dan gratis is bv. Daar is niks illegaal aan en kan je wel mooi fluiten naar je centen.

Tenzij iemand een beter idee heeft?

[Verwijderd]

Wanneer je een native webapp maakt (dus een "echte" app die linkt naar een url), dan kun je naast een definitie die aangeeft of je de betaalde of gratis app hebt, ook een sleutel toevoegen waarmee je direct verkeer naar de website kunt onderscheiden.

Op deze manier kun je zien of iemand met een app binnenkomt (betaald of gratis) of dat iemand met een normale browser op de website komt, die je dan blokkeert.


Persoonlijk, als webdeveloper, ben ik natuurlijk ook voorstander van native webapps. Maar hoop dan wel dat het gemakkelijker gaat worden om de hardware aan te roepen en om de specificaties van het toestel te verkrijgen.

Het grootste probleem is dat het moet werken op verschillende OS-en, browsers en resoluties. Los van het feit dat het zowel on- als offline moet (kunnen) werken.

Een voorbeeld wat cross-device programmeren erg lastig maakt is het feit dat bijvoorbeeld Android bepaalde events niet doorgeeft aan de browser (geen onTouch ipv onClick), en de API's van Android, iOS, Blackberry en Symbian zijn allemaal weer anders (zelfs icm scripts als PhoneGap).

[anchises]

Yeah, maar daar zeg je het em net.

Iemand met een 'normale browser'. Dat is puur bepaald door de user agent en eventuele extra http headers.

Die kun je ook gemakkelijk spoofen en dus een paid app spoofen..

Dat is net m'n hele punt.

[badflower]

wat ik me kan voorstellen is om een webapp te maken, en dan in de App-store een soort door-link app aan te bieden (evt. betaald).
Als je op deze doorlink app klikt, kom je in de webapp.
Voordeel is dat je dan wel een icoon hebt voor de app, en toegang tot de webapp betaald kunt aanbieden.
In-app aankopen zijn natuurlijk wat lastiger...

[humbug]

Partijen als paypal bieden betalingsapi's die in een webapp en android app zijn te integreren. Ook gaat het over het algemeen iets slimmer dan paid terugsturen. De app stuurt iets naar een externe betalings partij, de externe partij stuurt iets naar de server behorend bij de app waardoor de app kan zien of er betaald is. Niet echt high tech maar wel effectief

[AlbertTCB]

Webapps? Niet bepaald handig als je er gebruik van wilt maken buiten je WiFi en een data-abonnement hebt met een gelimiteerd maandelijks verbruik.

[sys64738]

HTML5 heeft een prima off-line modus waarmee je webapps gewoon offline kunt gebruiken. Zodra je weer verbinding hebt, wordt er gesynchroniseerd. Dus dat hoeft geen beperking te zijn.

Het grote probleem is volgens mij ondersteuning van de devices. Het is erg vervelend als je een webapp maakt die het maar op 3 van de 5 telefoons doet omdat een bepaalde feature niet wordt ondersteund. Beetje hetzelfde als we met browsers hebben gehad.

[Verwijderd]

Kijkende naar de grafiek neemt de interesse bij alle platformen af met uitzondering van WebOS. Waarom een gekleurde berichtgeving?

Cross platform, met geen eco systeem lock in, is natuurlijk het mooiste voor ons gebruikers.
En met wat met HTML5 onlangs is laten zien, lijkt er geen technische belemmering te zijn.

[mashell]

Cross platform, met geen eco systeem lock in, is natuurlijk het mooiste voor ons gebruikers.

Is dat wel zo? Wat kan het een Android gebruiker schelen als er ook een iOS versie van de app is? Ik vindt juist die Webapps vaak beperkt, vaak gemaakt om een website op een kleiner scherm weer te kunnen geven. Geen wezenlijke mobiele functionaliteit.

[PPie]

Apart?
Toen Apple uitkwam met de iPhone in 2007, met het idee dat je Webapps kon maken maar geen Native SDK beschikbaar stelde, werd er om het hardst geroepen dat een Native SDK nodig was en Webapps geen optie.
En nu opeens is Webapps de oplossing?

[Mellow Jack]

Ach ja het is altijd makkelijker om te verzinnen waarom iets niet werkt of verkoopt dan om te verzinnen hoe iets wel gaat werken/verkopen

[humbug]

4 jaar is lang in de IT. Browsers zijn ondertussen iets verder ontwikkeld dan toen de iPhone op de markt kwam.

[Verwijderd]

Erg jammer dat de interesse voor WP7 achterblijft... ik ben nu zelf Silverlight aan het leren en ik vind het een erg interessante manier van apps maken. En ik vind WP7 gewoon een lekker OS om mee te werken.