Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 28 reacties

Google stelt de introductie van zijn Android-sdk enkele weken uit. Er is meer tijd nodig om verbeteringen door te voeren. Ook de deadline voor de Android Developer Challenge is uitgesteld.

Android logoDe eerste testversie van de Android-ontwikkelkit werd op 12 november 2007 al uitgebracht, maar leverde veel kritiek op. "Functionaliteit is er nog niet, is slecht gedocumenteerd of werkt gewoon nog niet. Het is duidelijk nog niet klaar", aldus ontwikkelaar Adam MacBeth destijds. Google heeft de feedback op de testversie gebruikt om de sdk grondig te verbeteren en zal de uiteindelijke versie binnen enkele weken uitbrengen.

Als gevolg van het uitstel van de sdk, is ook de deadline van Android Developer Challenge opgeschoven. Met deze ontwikkelopdracht met een totale prijzengeld van tien miljoen dollar wil Google de ontwikkeling van programmatuur voor zijn Android-besturingssysteem voor mobieltjes stimuleren. De deadline wordt opgeschoven van 3 maart naar 14 april.

Apple zal overigens in februari de sdk voor zijn iPhone uitbrengen. De verwachting is dat Apple meer restricties zal aanbrengen, zoals onder meer het blokkeren van voip-applicaties. Ook zal publicatie van software door Apple moeten worden goedgekeurd of gefaciliteerd via iTunes. Google is meer gebaat bij openheid met betrekking tot softwareontwikkeling voor Android en zal waarschijnlijk meer het Palm-model volgen. De sdk voor Palm OS is vrij te gebruiken, waardoor er diverse applicaties door derden zijn ontwikkeld voor deze handhelds.

Android screen
Moderatie-faq Wijzig weergave

Reacties (28)

Het is maar net welke definitie van "great software" je er op na houdt. De iPhone/iPod Touch is qua architectuur technologisch superieur aan de software van Android, maar is gesloten en zal daarom waarschijnlijk nooit een software-ecosystem hebben als dat Android poogt te gaan hebben.

Waarom is de iPhone (of iPod Touch) technologisch superieur?

- Multitouch met Android is traag. Erg traag. Bijna onwerkbaar.
- Dragging (zoals met maps) is op de iPhone erg "snappy" en op Android wederom erg traag.
- De enige manier van accellerated graphics op Android is door een OpenGL ES canvas te maken en daarop je werk te doen. Accellerated graphics zijn niet geintergreerd met het Android widget framework zelf. Iets wat de iPhone wel heeft met Core Graphics en Core Animation.
- In android zijn applicaties per definitie Java. Op de iPhone per definitie native. Veel developers zullen het met me eens zijn: Native is sneller. Op de desktop wellicht niet van belang. Op een klein apparaat met "limited resources" des te meer.

De innovatie van Android zit hem vooral in het open ontwikkelmodel, maar het is jammer dat ze daarvoor veel technologie moeten inleveren. Dit terwijl google best een mooie staat van dienst heeft in het bouwen van goeie software.

[Reactie gewijzigd door mOrPhie op 4 februari 2008 11:56]

Wellicht zan google ook een native implementatie ipv een java implementatie maken na een bepaalde tijd? Indien ze dat voor elkaar kunnen krijgen lijkt me dat probleem in ieder geval uit de wereld. Java heeft wel als voordeel dat -bijna- iedere programmeur er mee zou kunnen werken.

Ik heb verder geen ervaring met Android dus pin me hier niet op vast, maar het lijkt me niet onredelijk dat een OS dat kort in ontwikkeling is nog veel performance update kan krijgen.
Het lijkt mij dat Google ook liever een native implementatie hiervan had toegepast, maar dat Apple zoiets juist, als ze verstandig zijn, dicht heeft getimmert met patenten.
Maar nu las ik overigens pas wel ergens dat het een klein bedrijf is waar Apple zaken mee doet dat Multitouch ontworpen heeft.. Wellicht hebben ze handelsafspraken met Apple zodat concurrenten van Apple niet dezelfde techniek kunnen gaan gebruiken.

Vandaar dat Google dat patent dus omzeilt heeft door het softwarematig op te lossen.
Dat bedrijf heet Figerworks, deze hebben al die multitouch technolgy die je nu ziet ontworpen. Ze doen geen zaken met Fingerworks maar simpel weg opgekocht, kortom Apple is eigenaar van Fingerworks.
Nee. Dit probleem is terug te herleiden tot de architectuur van de graphische interface van het OS. Dit zou wel kunnen veranderen, maar daar zullen aardig wat ontwikkel-iteraties voor nodig zijn. Immers, mocht het widely used gaan worden, dan moet je backwards compatible zijn en mag je API dus niet per definitie wijzigen.

Bovendien. Wat moeten ze met al die mensen die Java-applicaties hebben geschreven? Moeten al die applicaties native gecompileerd worden? nah. :P

[Reactie gewijzigd door mOrPhie op 4 februari 2008 14:41]

Ja, kijk maar naar windows, de eerste versies waren ook retetraag, maar na wat updates zijn we nu bij het supersnelle Vista aangekomen.
Hoe kun je een systeem afkraken die nog niet eens uit is :?
Heb je Android al werkend gezien?

Native programmeren voor de iPhone of met Java voor Android (en wellicht andere JME VM's) is een groot verschil in moeilijkheid.
Hierdoor wordt de drempel voor ontwikkelen voo rAndroid zeer sterk verlaagd. Zeker met het vrij beschikbaar zijn van de API biedt dat mogelijkheden voor vele OS applicaties.
Native is sneller, maar veel scheelt het niet.
Je weet namelijk niet hoe het intern is geregeld. Tijdens het compileren zou je het als een native applicatie kunnen maken, waardoor nadelen zwaar verminderd worden.

En de graphic acceleratie zou geen deel uit moeten maken van de framework. Dat zou het OS waar het op draait moeten doen. Aangezien het OS het framework ondersteund lijkt het me zeer mogelijk dat zoeits ook gedaan wordt.

Let wel, Android is niet een uitbreiding op Java ME. Ze hebben er vele dingen in aangepast, waardoor het niet compatible is. Zo zullen er verscheidene dingen mogelijk zijn, waaronder hardware aansturing.

*let wel, ik heb de SDK van Android niet ingezien en ook de iPhone niet.
Hoe kun je een systeem afkraken die nog niet eens uit is :?
Heb je Android al werkend gezien?
Ja. Net als iedereen trouwens. Er is een publieke beta waar je al mee kunt werken.
Je weet namelijk niet hoe het intern is geregeld. Tijdens het compileren zou je het als een native applicatie kunnen maken, waardoor nadelen zwaar verminderd worden.
Android werkt met een VM en is dus niet native. Zelfs na de [url=http://en.wikipedia.org/wiki/Just-in-time_compilation]JIT[/quote] is de code "managed" en werkt de VM dus als tussenlaag naar de ABI van het OS.
En de graphic acceleratie zou geen deel uit moeten maken van de framework. Dat zou het OS waar het op draait moeten doen. Aangezien het OS het framework ondersteund lijkt het me zeer mogelijk dat zoeits ook gedaan wordt.
Nou, dat wordt dus niet gedaan. :P

De OS ondersteunt accellerated graphics ook wel. Immers, ze hebben een OpenGL ES implementatie. Maar dat zegt niets over het framework. Het Android framework maakt (buiten opengl) geen gebruik van graphics accelleratie. Op geen enkel punt. En dat merk je -heeel sterk- als je de iPhone en een Android applicatie naast elkaar legt.

Indien je hardware accelleratie in je widgets wilt, moet niet alleen het OS, maar ook de VM, het framework en vervolgens de widget-leafs van je framework het ondersteunen. Niets gaat magisch vanzelf. Was dat maar zo.
*let wel, ik heb de SDK van Android niet ingezien en ook de iPhone niet.
Je hoeft de SDK's ook niet te kennen. Zoek op youtube maar 'ns naar filmpjes van een android telefoon en die van een iPhone en aanschouw het verschil in snelheid.

Ik heb trouwens de iPhone SDK ook niet handson gezien, maar grafische laag is exact hetzelfde als die in Mac OS X en die API ken ik wel. :)
Multitouch met Android is traag. Erg traag. Bijna onwerkbaar.
Hoe weet je dat? Dat is helemaal nog niet te testen.
De enige manier van accellerated graphics op Android is door een OpenGL ES canvas te maken en daarop je werk te doen. Accellerated graphics zijn niet geintergreerd met het Android widget framework zelf. Iets wat de iPhone wel heeft met Core Graphics en Core Animation.
Volgens mij is het wel de bedoeling dat de standaard UI-dingen hardware-acceleratie krijgen. De standaard interface componenten gebruiken veel transparantie ed, dat zou nml best langzaam als dat 100% software is.
In android zijn applicaties per definitie Java. Op de iPhone per definitie native. Veel developers zullen het met me eens zijn: Native is sneller. Op de desktop wellicht niet van belang. Op een klein apparaat met "limited resources" des te meer.
Android draait .dex code, dat is - als het goed is - sneller dan 'standaard java' met een JIT. Sowieso is het verschil in snelheid tussen native code en goede java code vaak niet zo groot.
Hoe weet je dat? Dat is helemaal nog niet te testen.
Volgens mij is het wel de bedoeling dat de standaard UI-dingen hardware-acceleratie krijgen. De standaard interface componenten gebruiken veel transparantie ed, dat zou nml best langzaam als dat 100% software is.
http://www.youtube.com/watch?v=g4m73NXn7hY

Op een gegeven moment komt hij op "grab and pan". Je ziet letterlijk de frames voorbij komen. Dat is wel even iets anders dan de user-experience van een iPhone of iPod touch. Hier wordt duidelijk geen gebruik gemaakt van hardware accelleratie. Ten minste, niet op een manier zoals het zou moeten. Volgens mij wordt (en dat heb ik weer van het pluizen en uitproberen van de code en de API zelf) heel veel gewoon softwarematig in een backbuffer gerendered.
Android draait .dex code, dat is - als het goed is - sneller dan 'standaard java' met een JIT. Sowieso is het verschil in snelheid tussen native code en goede java code vaak niet zo groot.
Dat is ook wel zo. Ook als je native code maakt, moet je op je resources letten. De keuze van een ontwikkeltaal is op de desktop al helemaal meer een kwestie van smaak of beleid. :)

Maar n ding is zeker, java heeft ten opzichte van native gewoon overhead. Of je dat nu leuk vind of niet. Die overhead is extra ontwikkelwerk (ontsluiten van ABI in API) en in runtime het gebruik van meer resources. Op een mobiel apparaat waar resources gelimiteerd zijn en energiegebruik duur zou hetgeen ik aan overhead heb liever steken in de ontsluiting en het gebruik van hardware accelleratie in de gehele GUI.

Overigens vind ik Android niet alleen maar slecht hoor. Zeker voor de openheid is veel te zeggen. Alleen vind ik het jammer dat ze niet voor het native accellerated model zijn gegaan. En van mijn credo's is altijd: "Drawing is done by hardware" en ik zie gewoon te vaak dat dat niet het geval is. Zo ook bij Android.

Als iemand mij het tegendeel kan bewijzen, dan lijkt me dat fantastisch. Maar alles wat ik tot nu toe zie is traag en onwerkbaar. :)
Kijk ns, het idee dat Java per definitie niet native is, is larie.
Er bestaan nl. processing chips die de gecompileerde java code als instructieset hebben, zodoende zijn die behoorljik snel in het verwerken van Java code.
OpenGL ES?
Waarom niet gewoon een OpenVG implementatie? Je hebt meer aan een 2d canvas als begin en OpenVG is erg veelbelovend...
Helemaal mee eens hoor. :) De hele implementatie van de Android GUI had OpenVG moeten zijn. Kijk naar frameworkfs als Amanith die dit al met succes toepassen.

Ik ben bang dat ze hardware accelleratie eruit houden om de accu te sparen. Immers is het apparaat al druk bezig met JIT'en (uiteindelijk naar ABI calls).

Wat ze nu hebben is een OpenGL implementatie (Voor (zeeeeeeeer beperkte) documentatie kun je zoeken naar de "Android.OpenGL" package) gebaseerd op ES. Zogezegd omdat ES light-weight is. ES heeft geen fixed function pipeline ja. Als dat light-weight betekent? ;)

Hoe dan ook. OpenVG had inderdaad een erg goed startpunt geweest. Wellicht dat er een setje hobby devvers is dat het aandurft Android te forken naar een OpenVG-versie oid.
Er is ook al OpenMoko. Zowel hun hardware als software is open.
Google stelt de introductie van zijn Android-sdk enkele weken uit. Er is meer tijd nodig om verbeteringen door te voeren.

Natuurlijk mag je verwachten van een beta versie dat het nog niet helemaal werkt zoals het hoort daarom, heet het in mijn ogen ook, een beta versie ;) kortom ik vind dat er nu nog geen speculaties over mag maken. Je praat er over alsof dit nu al definitief is terwijl de definitieve versie van de software nog niet eens is verschenen
Fijn, heb ik nog wat meer tijd (en de concurrentie ook natuurlijk). Overigens denk ik niet dat android een succes zal worden. Er zitten veel goede ideeen in, maar die zijn niet goed uitgevoerd. Vooral IPC is een ramp om te gebruiken. Aan de ene kant wordt je gedwongen van alle niet-volatiele componenten zoals TCP verbindingen een Service te maken, maar vervolgens moet je via een beperkte, inefficiente interface met die Service communiceren, is er geen asynchrone communicatie mogelijk, en moet je ook nog al je serialization zelf doen. De enige reeele optie is de Service in je eigen address space te houden en objecten te laten communiceren via globale variabelen, iets wat eigenlijk onacceptabel is.
Native is altijd sneller, java is enkel een vertragende tussenlaag. Het voordeel van die tussenlaag is dat applicaties op elke mobiel werken. Elke telefoon die Android ondersteund zal alle applicaties goed kunnen draaien. Omdat software voor de iPhone alleen op de iPhone zal draaien kan je net zo goed nativa programmeren. Je hoeft immers alleen rekening te houden met de iPhone en eventuele opvolgers. Volgensmij doet windows mobile het zelfde als android. Alleen gebruiken ze dan geen java maar .NET.
Apple zal overigens in februari de sdk voor zijn iPhone uitbrengen. De verwachting is dat Apple meer restricties zal aanbrengen, zoals onder meer het blokkeren van voip-applicaties. Ook zal publicatie van software door Apple moeten worden goedgekeurd of gefaciliteerd via iTunes.
Bij mijn weten heb je ook certificatie trajecten voor andere platforms zoals J2ME, BREW, Symbian en zelfs PalmOS oftewel ik zie het verschil niet. Als je applicaties via mobiele bedrijven wilt verkopen moet je applicatie ook gecertificeerd zijn. Anders kan je het wel vergeten... en dat kan nog best wel prijzig zijn... ontwikkelcertificaat kopen, testen/controleren (erg vervelend als je later nog een bug ontdekt kan je weer een paar honderd euro op tafel leggen voor de testcyclus!) door een testbedrijf. Niks speciaals aan...

[Reactie gewijzigd door alienfruit op 4 februari 2008 16:29]

Bij Windows Mobile krijgt de gebruiker de keuze om een niet-gecertificeerd pakket te installeren. Palm ken ik niet meer sinds mijn Vx, maar daar kon ik ook zonder certificaat voor devven, en ik denk dat ze dat nog steeds hebben / een model gebruiken net als Microsoft met WM. De gulden middenweg.
ik hoop toch nog rond de zomer maanden de eerste android devices te zien.. :/
Zet dat maar uit je hoofd. De eerste (aangekondigde) devices zijn gepland begin 2009.
Als de Android-sdk vrij gegevens is. Kan je het op elke PC mee werken :)
Het is gewoon slim van Google om snel een gerucht uit de wereld geholpen te hebben en maar te releasen.
Als er zo nodig een open systeem moet komen waarom gebruiken fabrikanten dan niet het Os van OpenMOKO of de greenphone? Ik zal wel wat missen maar deze zijn toch klaar voor productie?

Ben wel benieuwt hoe uiteindelijk Android zal werken.
Ik kan niet wachten op de eerste telefoon ontwikkeld met android. Eindelijk een open os voor telefoons waar iedereen mee kan doen wat ie maar wil.
Ik persoonlijk vindt dit een heerlijk vooruitzicht.
Laat HTC maar zsm met een telefoon komen, dan koop ik hem meteen.
En ach de iphone werkt ook niet echt goed als ik het zo links en rechts bekijk, heb wat familie in de VS en die zijn niet echt te spreken over dat ding.
Denk zelf dat snelheids problemen nog wel worden opgelost.
Een paar weken terug de Android sdk gedownload, eclipse && java maar op een gegeven moment liep ik vast op een knightrider/Cylon(Battlestar Galactica) Loading screen. Dus maar opzij gezet, voor een andere keer.

Vandaag weer even kijken of ik het aan de praat krijg, weer opnieuw installeren, alle config checken.. Googl`n op bugs, en waarom het niet werkt?
Dan is het leuk om te weten dat op slome computers het even kan duren voordat de emulator start. Op m`n pentium 3 - 866mhz hier duurde het voor mij 15+ minuten voordat de emulator met een notepad example en de menu interface kwam.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True