Google werkt aan applicatieframework voor Android op basis van Dart

Google werkt aan een alternatief voor zijn huidige op Java gebaseerde applicatieframework voor Android. Het gaat om Sky, een manier om applicaties te maken die is gebaseerd op Googles eigen ontwikkeltaal Dart. Er is al een demo vrijgegeven.

ArsTechnica merkte op dat Google aan het experimenteren is met zijn Java-alternatief Sky. Code en documentatie van een vroege versie van de sdk zijn al op GitHub te vinden. Met de op Dart gebaseerde programmeertaal wil de internetgigant vooral betere prestaties bieden op Android: applicaties moeten constant op 120 fps blijven draaien, iets dat met de huidige programmeertools niet mogelijk is. Wanneer Sky beschikbaar komt voor ontwikkelaars is nog niet duidelijk: Google stelt alleen dat het aan het testen is en heeft geen informatie vrijgegeven over het tijdsplan.

Applicatiecontent kan geserveerd worden over http waardoor het geheel min of meer functioneert als een web-applicatie. Dat zorgt er bijvoorbeeld ook voor dat er gemakkelijk updates uitgerold kunnen worden. Gebruikers zouden bijvoorbeeld niet eerst een nieuwe versie van een app hoeven downloaden, maar in plaats daarvan zouden ontwikkelaars alleen aan de serverkant nieuwe code hoeven te uploaden. Verder krijgen op Sky gebaseerde applicaties toegang tot de bestaande Android-api's.

Google introduceerde Dart al enkele jaren geleden en presenteerde het als een javascript-alternatief voor het web. Die web-achtergrond maakt het volgens ArsTechnica gemakkelijk om het compatibel te maken met Android, maar ook met andere mobiele besturingssystemen. Of Google plannen heeft om Sky ook voor concurrenten uit te brengen is niet duidelijk.

Reacties (28)

[Verwijderd]

Applicatiecontent kan geserveerd worden over http waardoor het geheel min of meer functioneert als een web-applicatie. Dat zorgt er bijvoorbeeld ook voor dat er gemakkelijk updates uitgerold kunnen worden. Gebruikers zouden bijvoorbeeld niet eerst een nieuwe versie van een app hoeven downloaden, maar in plaats daarvan zouden ontwikkelaars alleen aan de serverkant nieuwe code hoeven te uploaden.

Hm houdt dit dan in dat je je apps niet kunt draaien als je geen internet hebt? Als dat zo is, heb ik liever wat langzame apps waarmee ik zelf bepaal wanneer mijn data wordt opgebruikt voor updates.

[melgers]

Natuurlijk wel. Offline Web Cache. HTML5 Standaard. Je chrome applicaties werken net zo.

http://diveintohtml5.info/offline.html

[Verwijderd]

Echter word deze standaard vervangen door service workers. Het nadeel van web cache is namelijk dat je totaal niet weet als iets offline is opgeslagen, waar, hoe, etc.

Daarom is men bezig met service workers (Chrome support het) zodat je weet als iets word opgeslagen, je kunt zelf hoe en waar, etc. Service Workers plaatst de programmeur in control, niet de user agent.

[melgers]

Dat ziet er inderdaad veelbelovend uit.

[Jeroenneman]

Lijkt me sterk.

Je kunt ook offline gewoon webapps draaien, zoals volgens mij Firefox OS doet. Maar als je wel online bent, kan je apparaat gelijk geüpdatet worden (al is het maar de vraag of je dat altijd wil)

[Verwijderd]

Javascript, dus ook DART kent service workers. Hiermee kan als het ware een soort router gecreëerd worden. Het is met service workers mogelijk om aan te geven welke content offline opgeslagen moet worden. Je kunt dus de data van de server halen en deze daarna voor offline gebruik opslaan.

[sprikkel25]

of als een hacker de controlle krijgt over de server en er een andere code in verwerkt, word die dan realtime op je telefoon uitgevoerd.?

wow dat heeft consequenties met betrekking tot welke apps ik in de toekomst nog kan vertrouwen.

dit is een nsa achtige omgeving je geeft `1 x aan dat je het programma wilt en dan kan het programma daarna veranderen zonder verdere instructies uitleg?

brrr niets voor mij dus.

[Don Kedero]

Met HTML5, CSS3 en wat Javascript kan je de dag van vandaag al hele mooie dingen maken, sommige apps hebben soms zelfs geen reden tot bestaan. Een mobiele website zit soms beter in elkaar dan een app.

Infeite zou de gebruiker genoeg moeten hebben met een icoontje (snelkoppeling) naar een website (zonder adresbalk etc) zodat het eruit ziet als een app. + dit kan logischerwijze perfect ge-update worden (server-side) zonder dat de gebruiker hier last van heeft.

Je hebt wel constant internet nodig, tenzij je eens soort offline webapps maakt.

Uiteraard heb je wel een veilig systeem nodig om de API's te kunnen gebruiken van het toestel. We willen geen ActiveX toestanden van 10 jaar geleden die toegang heeft tot alles waarop de code draait.

[MacD]

Maar in de realiteit loopt een HTML5 app altijd TRAAG. Je kan nu nog niet een mooie app met leuke animaties etc in HTML5 maken die dan ook strak loopt.

[Murdock1985]

"Android: applicaties moeten constant op 120 fps blijven draaien, iets dat met de huidige programmeertools niet mogelijk is."
Heeft misschien te maken dat ze Android beter geschikt willen maken voor Virtual Reality als platform?
Daar heb je hogere framerates voor nodig.

[Iblies]

Google wil wel eens voowaarden tijdens het proces wijzigen.

Het lijkt me niet onrealistisch dat dat een gegronde reden is om Dart weer naar de voorgrond te brengen, maar gezien andere concurrenten zou ik toch eerst zoveel van software gebruik maken waarbij je minder gebonden bent aan de uitgever.

Een VR bril moet of alleen zijn werk doen of met een app op verschillende platforms werken zonder noemenswaardig verschil.

[simplicidad]

Waarom niet typescript zoals ze met atscript doen i.p.v. weer iets anders te doen ? Waarom moet het ene in Dart, het andere in een subset van typescript en als we toch nog bezig zijn vinden we nog iets anders om in GO te doen.

Het probleem is ook dat Google een kerkhof is qua technologieën en als je n aantal frameworks/talen moet kennen dan loop je het gevaar een investering in te doen die ze naar verloop van tijd mogelijk weer gaan uitfaseren.

Zo blijf je namelijk bezig en ik ben ook niet van de overtuiging dat het die platformen ten goede komt. Bij Google lijkt het soms een beetje als bij wat ik merk bij slechte IT projecten, het ene werkt niet dus we gaan iets anders proberen en dan zullen we wel zien waar we ermee landen.

Als je veel middelen hebt zoals Google kom je daar makkelijk mee weg, maar het getuigd toch ook niet van enorm veel visie op lange termijn.

Het zal ook aan mij liggen maar doet het verdomd hard aan phonegap/cordova/ionic denken.

[Reactie gewijzigd door simplicidad op 27 juli 2024 21:24]

[itcouldbeanyone]

zo denk ik er ook over , ik zou het als ontwikelaar niet gaan ondersteunen.
wij zijn meer van het multiplatform.

[Verwijderd]

Ik zie het wel voor me, 1 taal, die je kan gebruiken om websites te maken, command line apps, server side programs, android apps, ios apps.

Ben me de afgelopen maanden aan het verdiepen in dart, een erge mooie taal.

[runelaenen]

https://xkcd.com/927/
Wééral van toepassing

[guanche]

Dit heeft helemaal niks met concurrerende standaarden te maken. De Dart taal welke compileerde naar javascript was gewoon een superset om de Developers' leven makkelijker te maken, als ze er voor kozen.

Naar mijn weten was de adoptie van Dart erg laag en het is alleen maar goed dat ze nog wel potentie zien in andere vlakken.

Niks tegenstrijdige standaarden, maar meer opties en keuze vrijheid om Android apps te maken. Daar hoeven we toch niet sarcastisch over te zijn?

[Verwijderd]

Echter waar heeft dart nog nut met de komst van Ecmascript 6 en straks 7?
Dart heeft ook zijn eigen VM wat misschien beter draait als de V8 met Ecmascript 6. Echter zou ik eerder gaan voor de evolutie van Javascript omdat dat gewoon veel meer potentie heeft op lange termijn en voor alle partijen zo ook Microsoft. Typescript is bijvoorbeeld wel een mooi voorbeeld welke alles netjes omzet naar Ecmascript 5. http://www.typescriptlang.org/Playground

[guanche]

Precies, daarom was de adoptie voor webdev ook zo laag. Nu zetten ze het juist niet in als ecma 6 of typescript variant, maar zetten ze de blijkbaar zeer performant VM in voor native Android apps.

Ik ben op zn minst benieuwd, want volgens mij is de Dart learning curve voor een goede JS dev minder stijl, dan Java.

[Verwijderd]

Als ze dan nog steeds de compileer mode houden naar Javascript zou je zo makkelijk een applicatie kunnen schrijven native voor android, maar makkelijk te porten naar o.a. andere OSen met Javascript. Echter krijg je dan altijd een tweede rangs ervaring voor de andere platformen. Dat is altijd het nadeel.

[Verwijderd]

Google heeft laatst aangegeven dat ze geen DART runtime in Chrome inbouwen maar dat je je code net als TypeScript en CoffeeScript kunt transpilen naar plane old JavaScript. Zie nieuws: Chrome krijgt geen Dart maar wel pointer events

Off Topic: TypeScript kan ook naar ECMAScript 3 worden omgezet als je dit wilt.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 21:24]

[Qws]

Dart is gewoon een keuze. Als je niet van Javascript houd of van Java (voor dit geval) dan kan je alsnog kijken naar Dart.

[HerrPino]

Google lijkt een beetje last te hebben van het NIH (not invented here) syndroom. Ook wel bekend als 'not invented by me' syndroom of 'reinventing the wheel'. Regelmatig onterecht verwart met 'innovatie'. Waarom bijdragen aan het verbeteren van een bestaande standaard als je eigen, nieuwe standaard kunt introduceren lijkt Google te denken

[Reactie gewijzigd door HerrPino op 27 juli 2024 21:24]

[Soldaatje]

Ten eerste gaat dit niet om standaarden en ten tweede bestaat deze techniek nog niet dus Google kan niets anders gebruiken.

[itcouldbeanyone]

met een beetje creatief zijn komen ze net zover met de bestaande code

[robertpNL]

Sky... nu maar hopen dat ze geen rechtzaak aan hun broek krijgen van de British Sky Broadcasting Group. Recentelijk heeft Microsoft nog zijn SkyDrive moeten hernoemen naar Onedrive.

[arthur-m]

Ben ik de enige die denkt: toevallig dat Google dit bekendmaakt, nu Microsoft heeft aangekondigd code van Android te ondersteunen op het Windows platform?

Ofwel: schopt Google op deze manier deze plannen door de war, of is dat te simpel gedacht?

[uchiha]

Dat is niet mogelijk, anders moet Google alle bestaande Android versies updaten en niet vergeten de apps moeten dan ook opnieuw compiled worden.

Dit is gewoon een extra taal om mee te programmeren.