'Google brengt Chrome-apps naar Android en iOS'

Google werkt mogelijk aan een manier om Chrome-apps te porten naar Android en iOS. Daarbij kan het eindresultaat mogelijk als zelfstandige applicatie in de Play Store of App Store worden gepubliceerd. Het is niet geheel duidelijk of het om een officieel Google-project gaat.

The Next Web ontdekte een Github-repository waarin het project uit de doeken wordt gedaan. Het project, dat al te gebruiken zou zijn voor enthousiastelingen, laat ontwikkelaars zogenoemde packaged apps voor Chrome poorten naar Android en iOS. In het geval van Android wordt 4.0 en nieuwer ondersteund; welke iOS-versies moeten worden ondersteund, is nog niet besloten. Volgend jaar moet een beta uitkomen.

Packaged apps in Chrome maken gebruik van de render-engine en api's van Chrome, maar hun resources zijn lokaal opgeslagen, zodat ze ook offline kunnen werken. Bovendien zijn er api's beschikbaar die voor normale Chrome-apps niet te gebruiken zijn, en hoewel ze gebruikmaken van Chrome, draaien ze niet zichtbaar in de browser. Packaged apps kunnen bijvoorbeeld ssh- of vnc-clients zijn, of zelfs apps om video's en muziek mee te bewerken.

Het nu ontdekte project zou het mogelijk maken om die apps geschikt te maken voor mobiele telefoons en te publiceren in de Play Store of de App Store. Daarvoor wordt gebruikgemaakt van Apache Cordova, een platform voor het bouwen van native-apps met webtechnologieën als html, css en JavaScript.

Het is echter onduidelijk of het daadwerkelijk om een Google-project gaat, zoals The Next Web beweert. Het project wordt gehost door Github, in plaats van Google Code, wat ongebruikelijk is voor Google-projecten. Het project wordt echter geleid door Michal Mocny, een software-ontwikkelaar bij Google.

Reacties (31)

[ronaldmathies]

Heerlijk, we gaan applicaties maken in niet native talen, we hebben gezien bij Facebook hoe dat werkte, niet vooruit te branden. Dit is leuk voor Google maar of ik hier blij om ben, ik heb veel liever native apps, die kunnen veel beter ge-optimaliseerd worden dan een soort van HTML pagina wrapped applicatie.

Daarvoor wordt gebruikgemaakt van Apache Cordova, een platform voor het bouwen van native-apps met webtechnologieën als html, css en JavaScript.

Lees 'native' als HTML pagina die in een native app weergegeven word, hier is maar een klein deel native en de rest is een browser.

Sowiezo is het maar de vraag of je dit soort applicaties in de App Store krijgt want Apple heeft in zijn regelement staan dat HTML wrapped Apps niet toegelaten worden, dan moet je het gewoon aanbieden op een website.

[Reactie gewijzigd door ronaldmathies op 24 juli 2024 07:04]

[aaahaaap]

Facebook wordt (helaas) vaak aangehaald als (slecht) voorbeeld van hoe een webapp presteert. Dat deze echter zo slecht presteerde lag niet zozeer aan dat het een webapp was maar meer aan hun implementatie. Zie http://www.sencha.com/blo...tbook-an-html5-love-story voor meer info.

Verder wordt het tijd dat HTML5/CSS/javascript deel gaan uitmaken van het native framework zodat je bijvoorbeeld in HTML standaard elementen kunt maken die GPU versneld gerenderd worden.
Dat je logica dan nog in javascript is zal vaak niet zo'n enorme performance botteleneck zijn, zeker niet met V8 als javascript engine (t.o.v. Dalvik zou dat nog wel eens sneller kunnen zijn soms )

[XiniX88]

Ik snap een deel van je verhaal goed, op dit moment is de browser (ook al gebruik je eenzelfde weergave) trager dan native apps.

Toch is Android ook maar een mix van Java en een Dalvik om het Just in Time te compilen:
http://nl.wikipedia.org/wiki/Dalvik_(software)

Leuker is de nieuwe ART van Android:
http://en.wikipedia.org/w...d.27s_ART_virtual_machine

Dat scheelt niet zo heel veel van de V8 (javascript), welke de javascript ook omzet in machine taal:
http://en.wikipedia.org/wiki/V8_(JavaScript_engine)

Qua performance voor de script/programmeer taal zou er niet zo heel veel verschil moeten zijn, het weergeven kan echter inderdaad nog vele malen beter. Als dit laatste is weggenomen zou het voor een developer alleen maar makkelijker worden, je hoeft maar 1 taal te kennen om iets op het internet, mobiel en tablet te implementeren (uiteraard niet helemaal zo, maar een GUI ontwikkelen in android is anders dan iets schrijven in HTML).

Ik zie er wel toekomst in. 1 render engine (die HTML snel parsed) voor al je apps, eigenlijk Firefox OS. Het idee vind ik goed, waarom zou je 2 weergave engines maken als je het er met 1 af kan die behoorlijk veel opties heeft (CSS 1 2 3).

[Reactie gewijzigd door XiniX88 op 24 juli 2024 07:04]

[aval0ne]

Ik snap een deel van je verhaal goed, op dit moment is de browser (ook al gebruik je eenzelfde weergave) trager dan native apps.

Is dat zo? Kan je mij een linkje geven naar een test waarin dit aangetoond is? De FB app is veel trager dan de mobiele website bijvoorbeeld.

[zuzel]

Cordova (aka Phonegap) apps worden veelvuldig toegelaten tot de App store. Sinds versie 0.8 van Phonegap voldoen de apps aan de TOC van Apple's App Store.

[Rekcor]

Sowiezo is het maar de vraag of je dit soort applicaties in de App Store krijgt want Apple heeft in zijn regelement staan dat HTML wrapped Apps niet toegelaten worden, dan moet je het gewoon aanbieden op een website.

Heb je een bron? Op de site van Phonegap (wrapper voor HTML-apps) staan gewoon voorbeelden van apps in de App Store (http://phonegap.com/app/ios/)

Heerlijk, we gaan applicaties maken in niet native talen, we hebben gezien bij Facebook hoe dat werkte, niet vooruit te branden.

Zie ook http://vimeo.com/55486684

[Rafe]

Sowiezo is het maar de vraag of je dit soort applicaties in de App Store krijgt want Apple heeft in zijn regelement staan dat HTML wrapped Apps niet toegelaten worden

Bedoel je 2.12 "Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected"? Dat is iets anders: een app die alleen als wrappertje om de browser heen naar je eigen website gaat, zonder enige meerwaarde.

Apps gebouwd met Apache Cordova (voorheen Phonegap) kunnen namelijk prima gereleased worden in de App Store, en dat is qua techniek best vergelijkbaar met hoe Chrome Apps voor iOS zouden werken. Als HTML/JS je ding niet is kan je ook nog je iOS apps in C# of Ruby schrijven in plaats van Objective-C, dat mag prima.

[Reactie gewijzigd door Rafe op 24 juli 2024 07:04]

[skatebiker]

Sowiezo is het maar de vraag of je dit soort applicaties in de App Store krijgt want Apple heeft in zijn regelement staan dat HTML wrapped Apps niet toegelaten worden, dan moet je het gewoon aanbieden op een website.

Hoe zitten al die 'websitevervangende' apps (nu.nl, telegraaf, etc.) dan in elkaar ? Dat zijn toch ook verkapte websites ?

[Whatson]

Dat lijkt misschien zo, maar er komt geen HTML of browserelement aan te pas bij het tonen van deze applicaties op je scherm.

[rvanzon]

De apps gebruiken wel degelijk WebViews voor het weergeven van artikelen. Dit omdat het formatteren van HTML eenvoudiger en vaak beter is dan zelf een render-engine ontwikkelen.

Wat Apple niet wil is dat je je website wrapped in een app. Iets dat je helaas wel vaak op Android ziet. Dit betekent niet dat je app niet mag bestaan uit alleen WebView waarin je HTML 5 App draait. Zolang de app voelt als native en een fatsoenlijke userinterface heeft is het prima.

Over native versus HTML. Het probleem is niet zozeer performance. Facebook wordt vaak aangegeven als HET voorbeeld dat HTML 5 niet presteert en geen alternatief is. Ik snap niet dat er niet gekeken wordt naar webapp van Linkedin, waar een near-native experience gerealiseerd wordt.

Het probleem is look-and-feel, WebApps werkt voor veel soorten apps, alleen als je echt alles uit het OS wil halen waar de app op draait, dan zul je gauw terugvallen naar native of beter, een hybride oplossing, waar je HTML 5 mixed met native.

We moeten weer terug naar de 90's en daarvoor, MSX, 386, 486 etc. Waar we (als ontwikkelaars) ons best moesten doen om performance uit onze app te halen, zonder te veel geheugen te gebruiken. Het zelfde geldt voor Webapps op mobile.

EDIT: typos

[Reactie gewijzigd door rvanzon op 24 juli 2024 07:04]

[CaptJackSparrow]

Zo is dat. Er is veel veranderd sinds programmeurs op het 'bare metal' programmeerden in assembler. Wie kan er nu nog een schaakprogramma schrijven voor een computer met 1KB RAM in slechts 672 bytes?

Eerst nog gecompileerde talen maar naarmate computers krachtiger werden is men steeds verkwistender met die kracht omgegaan en meer in geïnterpreteerde talen gaan programmeren. Ik ben bang dat het voorlopig niet zal veranderen maar jammer is het wel dat het volle potentieel van onze computers zo vaak zwaar onderbenut wordt.

[Verwijderd]

Klopt, maar vaak wordt deze verkwisting gekoppeld aan een soort van onkunde van ontwikkelaars. Dat is niet (altijd) het geval. Het heeft allemaal met arbeidsproduktiviteit te maken. Programmeren wordt steeds abstracter om zo steeds meer te bereiken in steeds minder tijd. Al die abstractie lagen zorgen inefficientie.

Dat model is lang goed gegaan, omdat de target devices toch ieder jaar krachtiger werden. Ook wordt ontwikkelaarstijd duurder ingeschat dan bijvoorbeeld capaciteit ophogen.

Dat model is gereset nu we moeten programmeren voor low power devices. Hoe dan ook zal low level programmeren voor de meute geen stand houden, het is gewoon onbetaalbaar.

[MrFax]

Wat is er zo langzaam aan HTML dan?

[curumir]

Wat een kolder. Ja, laten we terug gaan naar archaïsche code die onmogelijk is te debuggen en al helemaal niet fatsoenlijk is te lezen door een derde persoon. En laten we allemaal slimme trucjes bedenken om iets in 1K te proppen terwijl we 8Gb intern geheugen (gaan) hebben en flashdrives van 500GB.
Want vroeger was alles beter...

Als er iets is wat een zegen is voor het programmeren zijn het high-level talen. Geen of in ieder geval veel minder last van de space-memory trade-off. Goede API's en high level talen zorgen ervoor dat meer mogelijk is, betrouwbaarder is en ja, uiteindelijk in 90% van de gevallen sneller is.

[TMC]

De Facebook-app is al heel lang geen HTML5 meer maar native code.

[iAR]

Ik mag hopen dat we dit inderdaad niet op onze iPhones krijgen. Zit daar niet op te wachten. Ik ben ook blij dat Apple dit soort zaken actief uit de store houdt. Is dat gesloten systeem toch nog ergens goed voor!

[pibara]

Man Android heeft helemaal niet eens native applicaties. Alles is Java met op z'n best een NDK moduultje er in ofzo. JavaScript doet de laatste jaren niet echt meer onder voor Java wat betreft performance. Beiden op een ruime achterstand t.o.v. echte native talen natuurlijk.

JavaScript is minimaal trager dan Java is behoorlijk trager dan Objective-C is minimaal trager dan C is minimaal trager dan C++. Daarnaast is de koppeling Chrome<-> NaCL naar wat ik er van gezien heb ook nog eens een beetje sneller dan de koppeling Java<->NDK, plus een stuk C++ ontwikkelaar vriendelijker, waardoor JavaScript+NaCl versus Java+NDK in de praktijk wel eens heel erg weinig zou kunnen gaan schelen.

Dus nee, ik ben bang dat je je baseert op verkeerde uitgangspunten. Ik hoop juist dat dit het begin kan zijn van de langzame dood van Java voor Android, en het begin van een verstandige convergance van Android richting ChromeOS.

[Rafe]

Programmeertalen zijn niet snel of langzaam. Het zijn talen (is Engels sneller dan Duits?) Programma's geschreven in die talen kunnen - afhankelijk van wat ze doen, welke VM (Dalvik =/= HotSpot!) of compiler er wordt gebruikt, hoe goed het programma is geschreven is, etc etc wel verschillen. En dan kan hetzelfde programma in Java sneller is dan in C++, of andersom. Het is verre van zo zwart-wit als je stelt... maar je steekt je afkeer tegenover Java gelukkig verder ook niet onder stoelen of banken bij de rest van de comments.

[Reactie gewijzigd door Rafe op 24 juli 2024 07:04]

[pibara]

Talen zijn niet snel of langzaam, maar die delen van de taal die noodzakelijkerwijs run-time zijn kunnen een taal practisch een stuk trager of sneller maken.

Ik heb geen afkeer van Java of bijvoorbeeld Perl, of zelfs TCL. heb die talen jaren lang met veel plezier gebruikt, ze zijn taaltechnisch echter niet echt meer meegegaan met de ontwikkelingen die we wel bij andere talen hebben gezien. Heb het TCL boek een aantal jaren geleden kunnen sluiten, ben net begonnen aan de laatste bladzijde van Perl, en ik heb de hoop dat het Java hoofdstuk dat ik recent heb geopend voor mij het laatste zal zijn in het Java boek.

Maar het belangrijkste punt is: Java is NIET native! Java is geinterpreteerd of in het beste geval JIT-compiled, maar omdat JIT compilatie nog steeds run-time is, is Java daarmee nog steeds niet Native. Java heeft net als JavaScript een enorme run-time en die is gegeven. Ergens net dat beetje meer performance nodig? Jammer, runtime licht vast, kun je niet aan sleutelen.

In native talen kun je tunen en bijstellen tot je de optimale performance en/of het optimale resource gebruik hebt. In sommige native talen kun je zelfs dingen verplaatsen naar compile-time (bijvoorbeeld via TMP in C++). Een applicatie geschreven in een native taal is niet magisch sneller dan een programma in Java, Python, Javascript etc, soms is het zelfs in eerste instantie trager, zeker als er naief ergens een verkeerd algoritme wordt gekozen door een programeur, terwijl het juiste algoritme in de VM of interpreter al lang zat ingebakken. Een applicatie gescheven in een native taal kan echter wel geschreven worden op performance terwijl je bij een geinterpreteerde taal al snel tegen een run-time enforced plafond aan zit. Heel veel keuzes zijn voor je gemaakt, en die zijn heel erg vaak sub-optimaal voor specifieke probleemstellingen.

Basis punt:

1) De verschillen tussen moderne VM-based en/of script talen worden steeds kleiner. Java is niet meer per definitie veel sneller dan JavaScript.
2) De verschillen in run-time snelheid tussen natively compiled talen zijn verwaarloosbaar. Talen met support voor meta-programming kunnen je de productiviteit van een moderne VM-based en/of script taal geven met de performance van metiquleus getunede en geoptimaliseerde native code.
3) Het verschil tussen moderne VM-based en/of script talen aan de ene kant en natively compiled talen is en blijft aanzienlijk, zeler als de native-compiled talen meta programing ondersteunen.

In de basis, als het verschil in snelheid tussen JavaScript en Java je iets uit maakt, dan betekent dat impliciet dat je eigenlijk (ook) native code nodig hebt. Als je ook native code nodig hebt, dan gaat de snelheid van de koppeling tussen de native taal en de non-native taal een grote rol spelen in de performance.

De kosten van een operatie wordt dan:

Non-native-code-kosten + language-barrier-kosten + native-code-kosten.

Als wat snelheid geld dat:

Java > JavaScript

dan kan het in veel gevallen nog steeds best zo zijn dat

Java + C++(NDK) < JavaScript + C++(NaCl)

[Leo. P. Klepper]

Jongens, zien jullie het dan niet? Google is via de weg van "guerilla-marketing" langzaam aan alle internetdevices aan het "infiltreren". Recent verscheen de Google apps button als een soort sidekick van de Google Chrome browser voor desktops. Eigenlijk gewoon een extra startknop met Google Apps. Voor je het weet heb je bijna het hele Google Chrome OS op je device staan. De stap naar een volledig Chrome OS is dan nog maar klein. Ik weet niet of ik er blij mee moet zijn, deze weg van de geleidelijkheid, geniaal vind ik het wel.

[daantjuh68]

ik wilde bijna alleen maar "dus" onder de comment zetten, ik denk dat je gelijk hebt hoor maar ik vind het persoonlijk alleen maar mooi allemaal! ik heb zo iets maak het maar makkelijker voor mij!

[MetalfanBlackness]

De meeste van de ontwikkelaars werken bij Google, dus het lijkt toch wel een project van google:

https://github.com/Mobile...obile-chrome-apps/network

Kamrik (Mark Koudritsky) http://ca.linkedin.com/in/kamrik
Dj2 (dan sinclair): http://ca.linkedin.com/in/dj2sincl

[Verwijderd]

Nu nog android apps naar chrome, dan wordt het een stuk interresanter.

[Whatson]

Ja, dat gaat ook zo'n goede gebruiks ervaring geven.... apps die geoptimaliseerd zijn voor een telefoonschermpje op de pc in de browser weergeven....

[rvanzon]

een goede Android app is responsive. Ze horen namelijk (ongewijzigd) ook op tablets te kunnen draaien.

[Verwijderd]

Vooral voor chromebooks zou dit een uitkomst zijn, dan heb je toegang tot alle apps die je ook oo je telefoon hebt, lijkt me handiger.

[pibara]

Ne joh, een chrome App + NaCl + jQTouch ofzo is als Google zich boos maakt straks onafscheidelijk van een Android App in Java. Van alle ontwikkel talen is Java de laatste jaren het minste doorontwikkeld, dik ingehaald door JavaScript 5, Python 3, C++11, etc hoe sneller we die archaische zooi af kunnen zinken hoe beter. Alsjeblieft niet het zelfde als we met Perl hebben gezien, en jaren lang doormodderen met een taal die nouwlijks nog met de tijd mee gaat onder de belofte van een mooie toekomst die maar niet komt.

[mailis]

Het lijkt mij niet logisch dat Apple dit ooit gaat goedkeuren. Dat is een directe bedreiging voor de Appstore en daar zal vast in de voorwaarden iets over staan genoemd

[Verwijderd]

Als ik het artikel goed begrijp dan is het nodig de render-engine van Chrome beschikbaar te hebben. Voorzover ik weet staat Apple op iOS niet toe om alternatieve render-engines te gebruiken, en is Chrome op iOS dan ook niet meer dan een schil om de standaard browser van het OS?
Of werkt dit wel omdat Chrome en Safari beiden op basis van Webkit zijn ontwikkeld?

[Duckness]

Ik ben vrij zeker dat deze git repo tijdens de Devoxx Sessie 'BUILD NATIVE APPS WITH HTML5? WITH CHROME APPS, YOU CAN' vermeld werd.

Meer info: http://www.devoxx.be/dv13-joe-marini.html?presId=3442

Binnekort kan de sessie herbekeken worden op http://www.parleys.com dus dan weten we het zeker! ;-)

[pibara]

'BUILD NATIVE APPS WITH HTML5' is zoiets als 'spreek native talen met Esperanto'

Een native-app is een app die gecompileerd is naar de native instructie set. HTML, JavaScript en zelfs Java zijn geinterpreteerd en dus NOOIT native. Nee zelfs niet als je JIT compilatie doet. Zels pNaCl is al bijna op het randje. Een native app is in de aller ruimste zin in ieder geval gewoon een app waar er na het starten geen interpretatie, compilatie, etc meer plaats vindt, en in de engste zin ook tijdens het starten al niet, ook niet de eerste keer na instalatie.

Ik zou zelf zeggen dat NaCl nog NET native is bijvoorbeeld. Java is het (ook op Android) gewoon NIET. HTML apps zijn daar nog een stapje vandaan en kunnen dus ook nooit native zijn.