Udvikler: Android stinker - vælg et andet mobil-OS

Umodent kørselsmiljø og dårligt designede API'er skabt af glade amatører. Det er den barske konklusion, som dansk udvikler kommer til efter at have kigget Googles mobilsystem efter i sømmene.

»Android stinker.«

Sådan lyder den benhårde konklusion fra Ole Friis Østergaard, som er Java- og Ruby-udvikler i det århusianske firma Trifork. Udmeldingen blev givet i en præsentation på et møde i Android-gruppen i Århus. Præsentationen er lagt på Version2's Android-gruppe.

Det er ikke mindre skønhedsfejl, som Ole Friis Østergaard ser i Android, men dybe problemer med det Google-udviklede mobilstyresystem.

»Teknologien i Android er dårlig. Googles mobil-udviklere er glade amatører,« lyder det.

Det er blandt andet Androids API'er og komponentmodel, som den er gal med. Som med Servlets og Midlets, to andre komponentmodeller fra Java-miljøet, skal Android-komponenter nedarves fra en superklasse. Denne model regnes for dårlig stil af mange, da det giver en tæt binding til miljøet og besværliggør test, som må udføres med mock-ups.

Derudover følger API'erne til Androids øvrige funktioner, som databasen SQLite og OpenGL, de underliggende bibliotekers C-grænseflader for slavisk.

Ole Friis Østergaard bryder sig heller ikke om de mystiske resurse-klasser, R.java, som indekserer resurserne uden typeinformation. De XML-filer, som benyttes til brugerfladelayout, finder heller ikke nåde.

»Jeg har nu ikke savnet XML ? har I?« spørger Ole Friis Østergaard retorisk i præsentationen.

Den virtuelle maskine Dalvik, som Android benytter, får heller ingen pæne ord med på vejen. Det er ydelsen, den er gal med.

Sammenlignet med Mono, open source-udgaven af .Net-platformens virtuelle maskine, er Dalvik 10 til 30 gange langsommere og har et større hukommelsesforbrug, ifølge Ole Friis Østergaards kilder. Det betyder i sidste ende dårligere batterilevetid, end hvis andre teknologier var anvendt.

Ole Friis Østergaard udelukker ethvert håb om, at fejlene kan udbedres i kommende udgaver af miljøet:

»Mange af disse problemer kan der aldrig rettes op på. Skaden er sket. Vælg et andet mobil-OS, hvis I vil undgå førnævnte designfejl,« lyder rådet til udviklerne.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (40)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Søren Nielsen

Har selv lige købt en HTC Magic for nogle dage siden.

Har lige snust til SDK'en og var ret overrasket over at jeg kom fra nul-viden til at have lavet min første Hello World app på ca 10 minutter (inkl download af SDK). Så kan ikke helt afvise Oles kritik, men umiddelbart synes jeg det virker positivt at platformen er så nemt tilgængelig.

  • 0
  • 0
#3 Martin Kofoed

De første Android-terminaler høster generelt gode anmeldelser, og én af de ting, der går igen, er den "smooth" afvikling af applikationer.

Også udviklere rundt om ser ud til at have gode oplevelser med applikationsudvikling til telefonerne.

Det er også første gang, jeg hører en SÅ sønderlemmende kritik af Android. Og det er vel i sig selv underligt, at man støder på det første gang i DK, for der er da ellers oversøiske interesser nok i at få smadret denne gratis opkomling på markedet?

Nu ved jeg ikke, hvordan Ole måler sig frem til sine konklusioner, men det klart vigtigste for succes, må være en god slutbrugeroplevelse. Og hvis det koster "et større hukommelsesforbrug", så er det vel givet godt ud?

  • 0
  • 0
#4 Casper Bang

Det virker noget følelsesladet og overreageret. Her er hvad jeg lige falder over:

Google's udviklere er alt andet end amatører. Der findes vist ingen arbejdsplads, hvor man skal så meget igennem for overhovedet at komme til jobsamtale. Man kan være uenig i API indkapslinger mv. men at kalde Google for amatører er utroværdigt.

Man behøver ikke bruge layout XML, det er blot den anbefalede vej til at adskille brugergrænseflade og logik (UI er nemmere at beskrive deklerativt end imperativt). Hvis man ikke bryder sig om dette, sætter man bare sit komponent-træ sammen manuelt i Java kode.

Hvordan kan man sammenligne et register-baseret mobil-runtime Android med Mono, et stak-baseret desktop-runtime? Når dét så er sagt, der er jo ikke noget i vejen for at Mono finder vej til Android telefoner, modsat alle andre platforme er man ikke låst specielt fast (Mono kører faktisk allerede på min G2 ligesom Lua og Python).

Google frigiver snart NDK (Native Development Kit), så hvis man har brug for virkelig hardcore ting (video dekoder) kan man jo vælge at se Android som et behageligt OO miljø med GC til brugergrænseflader mv.

Da han selv er JME udvikler, ville jeg da mange gange hellere høre om forskellen på Android og JME eller sågar objective C (iPhone). Jeg har da f.eks. aldrig set en emulator så godt udført som i Android SDK'et.

Og den største success JME har haft, er da vist til JavaOne keynotes vi har hørt mantraen "Java deployed on a billion devices" til evighed.

  • 0
  • 0
#6 Esben Damgaard

Som linuxentusiast ser jeg jo gerne at Android bliver en success

Nu er Android på en købt mobil jo ikke åben. Du har kun mulighed for at lave programmer via java-api'et og du kan ikke ændre i selve Android. Med det sagt, er der ingen hindring for at installere Android på f.eks. en Openmoko Freerunner. Så kan du ændre i alt, og lave lige hvad du har lyst til.

Jeg er som linuxentusiast splittet angående Android, netop fordi de holde de købte mobiltelefoner så lukket. Så er det jo ligegyldigt om operativsystemet er open source hvis jeg ikke kan ændre i det.

On topic, så synes jeg også det virker lige lovlig subjektivt.

  • 0
  • 0
#7 Frej Soya

Sammenlignet med Mono, open source-udgaven af .Net-platformens virtuelle maskine, er Dalvik 10 til 30 gange langsommere og har et større hukommelsesforbrug, ifølge Ole Friis Østergaards kilder.

Jeg ejer hverken en iphone,android baseret eller anden smartphone... Men det er noget af påstand at give uden at underbygge den med andet en rygter.

Især fordi der står at 'teknologisk' problem og ikke et implementations problem? (Hvis jeg forstår brugen af ordet teknologi rigtigt i denne sammenhæng).

  • 0
  • 0
#8 Thomas Hansen

af et sønderlemmende review. Som linuxentusiast ser jeg jo gerne at Android bliver en success, men dette lyder ikke lovende... Er andre enige?

Well, hvor meget sandhed der er i udtalelsen om 'glade amatører' skal jeg lade være usagt, men Linux blev jo også udviklet af 'glade amatører', og det er da gået meget godt...

Jeg kan bare konstatere at jeg syntes min Dream er meget mere behagelig end den Sony Ericsson P1 den afløste, så hvis Symbian skulle være et bedre system, så foretrækker jeg klovne systemet Android.

Jeg er sikker på at den gode Ole kan komme med velbegrundede forklaringer til hans kritikpunkter, og foreslå bedre alternativer. Det kan jeg bare ikke køre på nogen mobil telefon.

  • 0
  • 0
#9 Troels Liebe Bentsen

Hvis man har haft en Android baseret telefon i hånden kan konklusionen jo undre, specielt hvis man kigger i googles app store som har massere af applikationer helt uden Apple's brandværdig har fluffet det op til noget folk betaler mange penge for. Også interfacet på den HTC Magic jeg havde fingerene i fungerede upåklageligt, var hurtig og nemt at gå til.

Jeg har selv kun udviklet en hello world app til android, da det først gang kom frem og så med glæde de flest præsentation af platformen igennem. På overordnet plan syntes jeg arkitekturen er gennemtænkt og vel designet, specielt at sikkerhed og separation af data, login og gui er tænkt ind fra staten. Noget man kan savne på stor set alle andre platforme, IPhone, Symbian, WindowsCE, etc.

At man så valgte at basere det hele på Java er måske lidt skuffende, men på den anden side er det jo der man finde den største udvikler masse og kode.

Så det undre mig derfor at der skulle være følgende problemer og det ville glæde mig hvis det blev uddybet lidt mere:

  • Nedarves fra en superklasse, hvorfor er det et problem??, kilder, eksempler?
  • SQLite og OpenGL for tæt på C API'et, hvorfor et det et problem, begge dele har fine C API'er og det ser sku ret nemt ud http://developer.android.com/guide/samples/NotePad/src/com/example/andro... .
    • XML til interface design, det er nu sådan man gør, MS med XAML og WPF, GTK og QT med Glade og QT Designer. Gui design er nu engang nemmere som træk og slip. Skulle det have været YAML i stedet?
    • Dalvic vs. Mono, JRE, etc. på at læse kommentar i denne blog: http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html , her bliver der svaret på hvorfor dalvik er lavet som den er og hvorfor mono ikke ville kunne bruges i nuværende tilstand.
  • 0
  • 0
#10 Esben Nielsen

"Nedarves fra en superklasse, hvorfor er det et problem??, kilder, eksempler?"

Her har du et:

class MyThing extends FrameForkThing { public void foo() { /* Noget beregning */ super.bar(); } }

Hvordan laver jeg en unit-test, som masere foo(), men ikke tager hele frameworket med?

  • 0
  • 0
#11 Torben Mogensen Blogger

Hvordan laver jeg en unit-test, som masere foo(), men ikke tager hele frameworket med?

Generelt er OO-sprog ikke velegnede til unit tests -- der er for meget skjult tilstand og for mange dynamiske bindinger. Kaldet til superklassen er ikke det værste problem -- man kan trods alt se, hvilken klasse, der skal inkluderes.

Hvis man vil programmere med unit test for øje, bør man bruge en overvejende funktionel stil: Et kald returnerer en værdi, men ændrer ikke nogen lokal tilstand og afhænger heller ikke af lokal tilstand.

  • 0
  • 0
#12 Christian Schiønning

Der kan være mange tekniske forklaringer på om Android er godt eller skidt, men afgørende er vel at køberne er tilfredse. Hvad jeg har hørt ind til videre, så er folk generelt tilfredse eller meget tilfredse med Android. Jeg har heller ikke hørt om desiderede bummerter som med iPhone der ikke kan copy/paste! :O

  • 0
  • 0
#14 Troels Liebe Bentsen

Prøv at læse kommentarene på den blog, der får du en fin forklaring på hvorfor mono eller java's std. jit ikke lige er til at bruge i nuværende tilstand. Specielt Dan Bornstein(danfuss) som er hoved udvikleren på dalvik svar er interessante.

  • 0
  • 0
#15 Troels Liebe Bentsen

Hvorfor er det et problem at tag hele frameworket med? Er det ikke mere en teoretisk problemstilling at alt skal kunne testes 100% og tilmed uafhængigt af det framework man benytter. Så med mindre man er "dit favorit paradigme/kode stil/sprog" jihadi burde den lille detalje ikke være den store produktivitets dræber.

  • 0
  • 0
#16 Dennis Krøger

Troels, enig, og især fordi at det kun gælder views, der under alle omstændigheder er noget hø at unitteste i de fleste frameworks (og det betyder ikke det vilde, der er alligevel ikke andet end præsentation af data i).

  • At XML til interfacebeskrivelse skulle være en dårlig ting kan man kun sige "HUH?" til.
  • 0
  • 0
#17 Esben Nielsen

Problemet ved at tage hele frameworket med er, at man ofte ender med hele telefonen, da basen sikkert hiver i noget GUI, som hiver i noget etc. Dvs. man ender med at køre sin unit test i noget, som minder om produktionsmiljøet. Hvis man skal nulstille det hele for hver test blive alle test meget langsomme at køre. Og hvis ikke aner man jo ikke hvad tilstand det er i ved hvert test.

Problemet er ikke OO; men brugen af nedarvning. Man kan godt lave OO uden nedarvning v.hj.a interfaces. Hvis API'et består af interfaces samt nogle factories, kan man stubbe hvad som helst. Og så kan man teste alle tilstande i sin "unit" (det vil ofte sige klasse) for så er det til at overskue. Men hvis du har nedarvet fra en sort boks, er det håbløst...

  • 0
  • 0
#18 Peter Strand

Som Android-udvikler ser jeg et stort potientielt problem med den tilgang Google har mht. standardisering af API'er.

Som jeg ser det har jeg meget få garantier mht. tilgængelige API'er, da det er fuldstændigt op til de enkelte producenter hvordan det skal se ud. HTC har netop idag introduceret endnu en Android device, med nye UI features. Det er uklart for mig som udvikler hvordan jeg kan tilgå/udnytte disse ting ( bliver interessant at se hvad HTC egentlig gør ).

Risikoen er en fragmentering af features og API'er som vil gøre det meget besværligt at udvikle til Android uden at have en masse device/producent specifik kode med.

Se evt. Goslings kommentarer på dette :

http://www.eweekeurope.co.uk/interview/gosling--google-s-java-attitude-w...

  • 0
  • 0
#19 Ole Østergaard

Nu er jeg på ferie i Finland den her uge, så det bliver sparsomt med opfoelgning fra mig. Min praesentation som der henvises til fra artiklen, fra Lenios glimrende Android-meetup, er selvfoelgelig ment som en provokation - jeg mente at Android-miljoet var gået hen og blevet lidt for fanboy-agtigt og traengte til en opsang. Derfor blev jeg inviteret af Tommy fra Lenio til at komme og ruske op i folk, og derfor satte jeg selvfoelgelig alt på spidsen.

Dog er det ikke påstande der er helt hen i vejret jeg kommer med, og jeg står fast på alle punkter. Hvor jeg kan se idéen i at Apple har valgt at bruge Objective-C, XCode og en masse af deres standard-halloej fra Mac til iPhone, kan jeg ikke se hvorfor Google, der er startet helt på en frisk, ikke har gjort det bedre til Android.

På den anden side er det nemt at komme i gang med Android-programmering. Det tager ca. 5 minutter at komme i gang, hvilket er meget, meget hurtigere end fx iPhone-udvikling. Det kan jeg da ikke fornaegte.

Men man må sige at det har sat gang i en masse gode diskussioner, så selv hvis mit eftermaele bliver som gammel, forstokket udvikler, er det naesten det vaerd :-) Der er for resten også noget tidligere diskussion om alt dette på Version2's Android-gruppe.

  • 0
  • 0
#20 Peter Strand

@Casper Bang: Min bekymring går på at når nye hardware features introduceres ( lysmåler, kamera med nye egenskaber etc ), hvem står for standardisering af API'er til disse ? Apple gør det for iPhone, Sun for JME, men gør Google det for Android? Har de en fasttømret process med hardwareproducenterne, eller kan de gøre som de vil ?

  • 0
  • 0
#21 Casper Bang

@Peter Strand: Der er ikke noget umiddelbart unikt ved HTC Sence (Rosie). Det kører allerede på G1'ere og specs på den nye HTC Hero er stort set identiske til min HTC Magic. Og det er vel ikke specielt unikt for Android enheder?! Der er nu 3 iPhone versioner + div. iPod Touch, alle med forskellige hardware (seneste iPhone har kompas, 256MB RAM, 600MHz CPU og OpenGL hardware) - der alle kører på samme OS/API.

Det har ALTID været tricky at udvikle til mobil platforme, hvorfor JME jo rent faktisk som den eneste Java platform har preprocessor. Man kan med andre ord påstå, at Sun's "write-once-run-anywhere" er en fallacy. Android's approach er anderledes, hvilket de redegjorde for på dette års GoogleIO konference: http://www.youtube.com/watch?v=PAMtKVO2ch8&feature=channel

Mht. Goslings kommentar, så er han jo for længst reduceret til Sun evangelist hvis eneste formål er at markedsføre JEE/JSE/JEE/JavaFX, så det er klart at han har issues med både Android, App Store, GWT og alt andet der ikke officielt er Java og styret af Sun.

  • 0
  • 0
#23 Ole Østergaard

Det virker noget følelsesladet og overreageret

Foelelsesladet? Ikke det mindste. Sat på spidsen? Ja, og forklaringen står ovenfor :-)

Google's udviklere er alt andet end amatører

Google har masser af gode folk:

  • Google har udviklet dependency injection-frameworket Guice. Det kunne have vaeret rart hvis en eller anden fra dette team kunne forklare Android-teamet hvorfor det er en god idé med dependency injection, men det er ikke sket.

  • Google har Joshua Bloch ansat, og han er et af mine klare forbilleder. Hvis blot Android-udviklerne havde laest hans Effective Java, ville vi ikke have fx problemet med nedarvning af klasser og de C-agtige interfaces.

  • Lars Baks team er verdensmestre i at lave VM'er, men de har åbenbart heller ikke vaeret på banen ifm. Dalvik-VM'en. Det kunne den jo godt traenge lidt til.

Hvordan kan man sammenligne et register-baseret mobil-runtime Android med Mono, et stak-baseret desktop-runtime

Dalvik-bytecode er genereret fra Java-bytecode, som igen ligner IL-kode ret meget. Desuden er jeg da egentlig ret ligeglad med om den underliggende bytecode eller VM er register- eller stak-baseret. Eller har jeg en grund til at godtage en faktor 30 i performancenedgang på grund af det?

Da han selv er JME udvikler

Nix. Hvis jeg var, kan det da godt vaere at jeg ville se med mildere oejne på Android?

  • 0
  • 0
#24 Ole Østergaard

Det er også første gang, jeg hører en SÅ sønderlemmende kritik af Android

Som sagt er det også sat på spidsen pga. den kontekst jeg lavede slidesene og praesentationen i.

Nu ved jeg ikke, hvordan Ole måler sig frem til sine konklusioner

Tjah, det kan vel aldrig skade at laese artiklens kildemateriale, eller hvad synes du? :-)

  • 0
  • 0
#25 Ole Østergaard

Det er ret ligemeget hvad i har lyst til at vælge, det er ikke jer som bestemmer. Vælg det som folk vil have i stedet for at løbe rundt som en flok primadonnaer med fine fornemmelser...

Så vi må ikke have den her diskussion, bare fordi vi er noerder og synes sådan noget er interessant? Det er da også et synspunkt :-)

Men jeg er da enig med dig i at det nok ikke bliver "laekkerheden" i udviklingsprocessen der bliver afgoerende, men alt muligt andet. Det goer jeg også klart sidst i de slides som artiklen linker til.

  • 0
  • 0
#26 Casper Bang

Ahhh Ole, så nemt synes jeg nu ikke du kan fraskrive dig "glade amatører", "stinker", "umoden", "dårligste teknologi", "dårligere batterilevetid". Men ok, du har da fået sat en diskusion igang!

Google har udviklet dependency injection-frameworket Guice. Det kunne have vaeret rart hvis en eller anden fra dette team kunne forklare Android-teamet hvorfor det er en god idé med dependency injection, men det er ikke sket.

Bob Lee's Guice er smart ja, men IoC er jo laaangt fra nyt og det er jo endnu et lag der skal håndteres på runtime tidspunkt. Kunne man forestille sig at et sådant lookup/auto-wirings lag er lige lovligt heavyweight til en mobil enhed? Man kommer ofte rigtig langt med alm. SPI: http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider

Google har Joshua Bloch ansat, og han er et af mine klare forbilleder. Hvis blot Android-udviklerne havde laest hans Effective Java, ville vi ikke have fx problemet med nedarvning af klasser og de C-agtige interfaces.

Jeg er uenig med din stringente fortolkning af item 16,17 og 18 i Effective Java. Josh skriver jo at netop til frameworks, er det ok at bruge klasser. Man skal bare tænke sig om når man gør det, men fordelene for applikationsudviklere er jo enorme. Findes der nogen frameworks der IKKE gør således? Hvis din anke skyldes problem mht. mocking/unit testing, så husk på at en Activity er et skærmbillede - fuldstændig som f.eks. en JFrame. Skriver du unit tests til dine JFrames?

Lars Baks team er verdensmestre i at lave VM'er, men de har åbenbart heller ikke vaeret på banen ifm. Dalvik-VM'en. Det kunne den jo godt traenge lidt til.

Det er fint at have sine forbilleder (mine er Anders Hejlsberg og Miguel De Icaza), men har du belæg for at drage konklusionen at Lars Bak er bedre end Dan Bornstein? Prøv f.eks. at se hvorledes Lars Bak sløser med memory forbrug: http://dotnetperls.com/chrome-memory

Desuden er jeg da egentlig ret ligeglad med om den underliggende bytecode eller VM er register- eller stak-baseret. Eller har jeg en grund til at godtage en faktor 30 i performancenedgang på grund af det?

Jeg mener nu stadig ikke du kan sammenligne på basis af en naiv fibonacci micro-benchmark. Det minder mig om Java folk der skriger "se, vi er hurtigere i algoritmen end C kode" men hvor så programmet er 10 gange længere om at starte op, mindre responsiv mv.

Når det så er sagt, Android er langt fra perfekt, det har taget Sun 15 år at nå til hvor de er i dag med deres VM. Og jeg deler jeg da din interesse i at se Mono på Android. Meeen med 5.000 applikationer allerede i Android marked og batterilevetid der svarer til iPhone, kan det altså ikke være helt tosset.

  • 0
  • 0
#27 Peter Stricker

Kære Brugere!

Det er fløjtende ligegyldigt, hvilken telefon I synes, har de fedeste features. Det er ikke Jer der bestemmer, hvilke telefoner der bliver udviklet software til.

Vælg den telefon, udviklerne gider at lave software til i stedet for at løbe rundt som en flok primadonnaer med fine fornemmelser...

  • 0
  • 0
#28 Peter Valdemar Mørch

:-) Troede sgu lige et øjeblik at det var en repost af det tidligere indlæg indtil jeg opdagede de små men væsentlige forskelle.

Samme tanke har strejfet mig: Det har vel stor betydning for endelig udbredelse på "gadgetmarkedet" at frameworket er udvidelsesindbydende.

  • 0
  • 0
#29 Ole Østergaard

Kunne man forestille sig at et sådant lookup/auto-wirings lag er lige lovligt heavyweight til en mobil enhed?

Tjah, jeg har aldrig analyseret naermere hvor tungt autowiring er i en typisk applikation, men jeg vil tro at det er meget begraenset hvor meget DI-frameworket skal svede. Der er jo tale om klasser der alligevel skal instantieres, og VM'en skal alligevel hive klassedefinitionerne op. Det må kunne lade sig goere uden den store raketvidenskab at lave et DI-framework til en mobilenhed som ikke bruger naevnevaerdigt af ressourcer eller opstartstid.

Men måske - her er jeg ikke sikker - understoetter Dalvik-bytecode ikke annoteringer? Dependency injection er nu engang rarere med annoteringer i stedet for XML, og sikkert også mindre ressourcekraevende for DI-frameworket.

(Om nedarvning:)

Findes der nogen frameworks der IKKE gør således?

Ja da, alle komponenter i Spring-miljoeet er fx bygget op via dependency injection. Af og til kommer man selvfoelgelig ikke helt uden om nedarvning - eller rettere, af og til er nedarvning at foretraekke frem for at skulle implementere alle metoder i et stort interface, men store interfaces er alligevel sjaeldne i et godt designet framework.

Problemet med Activity-klassen i Android er også at den kan så hulens meget. Jeg blev noget forbloeffet da jeg fandt ud af at man kunne give en Cursor til en Activity, og så håndterer den på en eller anden måde livscyklusen. Tyder det ikke på at kagen skulle skaeres anderledes? I hvert fald goer det det helt uoverskueligt at unit-teste en Activity-subklasse.

Hvis din anke skyldes problem mht. mocking/unit testing, så husk på at en Activity er et skærmbillede - fuldstændig som f.eks. en JFrame. Skriver du unit tests til dine JFrames?

Ja, anken skyldes problemer med unit-test. Og nej, jeg skriver ikke unit-tests af mine JFrames, netop fordi det er for boevlet. Men jeg ville gerne.

Jeg mener nu stadig ikke du kan sammenligne på basis af en naiv fibonacci micro-benchmark.

Det har du helt ret i - den refererede benchmark var blot hvad jeg kunne finde i dagene op til praesentationen hos Lenio. Det kunne vaere interessant med andre, mere realistiske benchmarks. Min egen fornemmelse er dog at Dalvik-VM'en virkelig er rigtig langsom, men jeg ved ikke selv hvordan jeg skulle foretage en god sammenligning.

(Dalvik-VM'en har kun en fortolkerdel p.t., ikke sandt? I så fald vil den vel komme til kort i stort set alle benchmarks...)

Jeg har selv proevet at lave noget 3D-vaerk på Android, hvor jeg sviner vildt med objekter. Det håndterer den rigtig dårligt, og man kan se på animationen hvornår der garbage-collectes. Det vil man selvfoelgelig ikke kunne maerke i en applikation der blot henter data, viser dem og venter på bruger-input, men jeg glaeder mig til at se hvor gode Android-telefonerne bliver som spilleplatform i forhold til fx iPhone (som jo slet ikke har garbage-collection, men overlader ansvaret til programmoeren, og hvor alt koerer "native").

Selvfoelgelig kan man bare lade vaere med at oprette objekter i vildskab som i mit eksempel, men på den anden side synes jeg også en VM boer håndtere det godt.

Og nej, selve Android-telefonerne ser også ud til at blive finere og finere, det er jeg helt enig med dig i. Og som sagt andetsteds, så er det alt andet end min mavefornemmelse der bliver afgoerende for mobilmarkedet om 5 år :-) Jeg kan bare ikke lade vaere med at aergre mig over at når nu Google har så mange smarte folk, og når de nu er startet helt fra bunden med et nyt framework og kunne have gjort det så godt for os udviklere, hvorfor kunne de så ikke stramme sig lidt mere an?

  • 0
  • 0
#30 Casper Bang

Tjah, jeg har aldrig analyseret naermere hvor tungt autowiring er i en typisk applikation, men jeg vil tro at det er meget begraenset hvor meget DI-frameworket skal svede. Der er jo tale om klasser der alligevel skal instantieres, og VM'en skal alligevel hive klassedefinitionerne op. Det må kunne lade sig goere uden den store raketvidenskab at lave et DI-framework til en mobilenhed som ikke bruger naevnevaerdigt af ressourcer eller opstartstid.

Men måske - her er jeg ikke sikker - understoetter Dalvik-bytecode ikke annoteringer? Dependency injection er nu engang rarere med annoteringer i stedet for XML, og sikkert også mindre ressourcekraevende for DI-frameworket.

Det kan det sikkert, netop Guice udemærker sig ved ikke at være monster stor/kompleks som f.eks. Spring. Men hver gang man tilføjer ting der skal resolves ved runtime tid istedet for compile tid, koster det i opstartsperformance. Faktisk tror jeg annotations er dyrere på en mobil enhed end XML, eftersom DI containeren aktivt skal scanne classpath igennem istedet for at kigge på en foruddefineret filplacering.

Ja da, alle komponenter i Spring-miljoeet er fx bygget op via dependency injection. Af og til kommer man selvfoelgelig ikke helt uden om nedarvning - eller rettere, af og til er nedarvning at foretraekke frem for at skulle implementere alle metoder i et stort interface, men store interfaces er alligevel sjaeldne i et godt designet framework.

Som grovkornet dependency mekanisme imellem subsystemer er DI smart, men som finkornet wiring-mekanisme tilføjer det ofte lige så meget kompleksitet som det fjerner. Du mister jo f.eks. fuldstændig evnen til at lade div. statiske værktøj inspicere koden og fortælle dig noget om relationer og dependencies. Og sidst jeg hentede Spring miljøet, snakkede vi altså 150MB og JavaDoc på 2400 klasser! Faktisk tror jeg det er umuligt at få Spring til at køre på Android, eftersom Spring bruger byte-code weaving til mange af dens ting - og Dalvik har jo sin egen byte-code.

(Dalvik-VM'en har kun en fortolkerdel p.t., ikke sandt? I så fald vil den vel komme til kort i stort set alle benchmarks...)

Jo, hvis din benchmark alene er baseret på "tight loops" og ikke tager brugeroplevelse i betragtning. Grunden til at køre register baseret er jo at så kan de optimere bedre én gang (under compilering til .dex) til kode der passer til ARM CPU'en. I samme omgang kan de verificere koden bedre, noget der er uhyre kostbart når du starter et Java program op på en JVM og noget som Mono har valgt slet ikke at implementere.

JVM'en starter jo den dag idag også med at fortolke for så siden hen at lade dens JIT optimere "hotspots". Som du sikkert ved, har de jo sådan set planer for JIT/AOT. Hvorfor så ikke bare tage Sun's Java eller Mono? Tja det er jo nok bl.a. pga. licens spekulation, Google kan ikke lide at andre har veto ret (som f.eks. Sun har i JCP) og jeg tror da slet ikke de vil give Microsoft dét trumfkort at potentielt kunne sagsøge dem når/hvis Microsoft beslutter ikke at forny aftalen med Novell.

Jeg har selv proevet at lave noget 3D-vaerk på Android, hvor jeg sviner vildt med objekter. Det håndterer den rigtig dårligt, og man kan se på animationen hvornår der garbage-collectes. Det vil man selvfoelgelig ikke kunne maerke i en applikation der blot henter data, viser dem og venter på bruger-input, men jeg glaeder mig til at se hvor gode Android-telefonerne bliver som spilleplatform i forhold til fx iPhone (som jo slet ikke har garbage-collection, men overlader ansvaret til programmoeren, og hvor alt koerer "native").

Ok det har jeg så ikke. Jeg tror du har ret i at GC er relativ naivt implementeret (ligesom iøvrigt den er i Mono), men igen ser den ud til at være god nok til formålet. Du kan vælge et se på både Dalvik og Mono som umoden teknologi i visse henseender, men jeg vælger nu at se det som enormt potentiale. Mon ikke mange spil alligevel vil være lavet med NDK'et og C kode? Der er jo heller ikke ligefrem mange prangende Java spil til desktopper selv om vi her snakker om en ekstrem moden JVM.

  • 0
  • 0
#31 Ole Østergaard

Som grovkornet dependency mekanisme imellem subsystemer er DI smart, men som finkornet wiring-mekanisme tilføjer det ofte lige så meget kompleksitet som det fjerner. Du mister jo f.eks. fuldstændig evnen til at lade div. statiske værktøj inspicere koden og fortælle dig noget om relationer og dependencies.

Det er rigtigt: Man giver noget, man får noget. Selv er jeg, som det nok fremgår, ret vild med DI :-) Jeg synes at man vinder en masse ved at goere sine afhaengigheder mere synlige i constructors og properties end et antal "new"-statements spredt ud over sin klasse.

Og sidst jeg hentede Spring miljøet, snakkede vi altså 150MB og JavaDoc på 2400 klasser!

Det må naesten vaere "spring-all.jar", eller hvordan? Det er "spring-core.jar" der indeholder selve DI-containeren. (Sidder p.t. i Finland og er for doven til at checke det :-) )

Jeg har overvejet at man burde starte et projekt ala "Spring til Android". Det må kunne lade sig goere at lave et fornuftigt DI-lag oven på Androids standard-klasser og få lavet en ordentlig separation mellem views, controllere og model i Android-verdenen. Ak, hvis blot man havde tid...

Hvorfor så ikke bare tage Sun's Java eller Mono?

Så vidt jeg ved, er Java ikke "åben" når det drejer sig om koersel på mobilenheder, hvilket også er den egentlige grund til at Google har lavet sit eget bytecode-format - altså så Sun ikke kan komme efter dem og påstå at de bryder en licens ved at udelukke nogle klasser og samtidig koere Java-bytecode på en mobil enhed.

Og det ville nok afskraekke en del open source-entusiaster hvis Google lagde sig fast på Mono, vil jeg tro. Men de kunne jo nok godt have brugt indmaden af Mono-fortolkeren/JIT'en.

  • 0
  • 0
#32 Mikkel Meyer Andersen

Google frigiver snart NDK (Native Development Kit), så hvis man har brug for virkelig hardcore ting (video dekoder) kan man jo vælge at se Android som et behageligt OO miljø med GC til brugergrænseflader mv.

Jeps, det er nu sket. Blogpost: http://android-developers.blogspot.com/2009/06/introducing-android-15-nd... Download: http://developer.android.com/sdk/ndk/1.5_r1/index.html

  • 0
  • 0
#33 Casper Bang

Det er rigtigt: Man giver noget, man får noget. Selv er jeg, som det nok fremgår, ret vild med DI :-) Jeg synes at man vinder en masse ved at goere sine afhaengigheder mere synlige i constructors og properties end et antal "new"-statements spredt ud over sin klasse.

Det er jeg grundlæggende enig med dig i. Men der findes jo en hel arkade af design mønstre (creational) til formålet. Ja faktisk er Joshua Blochs første punkt i Effective Java omkring static factory methods.

Og det ville nok afskraekke en del open source-entusiaster hvis Google lagde sig fast på Mono, vil jeg tro. Men de kunne jo nok godt have brugt indmaden af Mono-fortolkeren/JIT'en.

Ja, selv om Mono jo virkelig er open-source og modsat Java, er standardiseret af en standardorganisation (ECMA) hvor Microsoft har én stemme ligesom alle andre. De dele der er kontroversielle (WinForms, ADO.NET) ville jo nok ikke finde vej til en evt. Mono Android platform, ligesom Swing ej heller er at finde på nuværende Android platform.

Men årsagerne er jo nok den (desværre) religiøse modstand imod ALT Microsoft relateret samt det faktum at Android jo egentlig blev startet i 2005 med dét mål at tiltrække det eksisterende store Java community.

  • 0
  • 0
#34 Joakim Recht

Det kan godt være, at Google-folkene ikke har været helt grundige i deres api-design (det er set før, fx med GWT, som også startede som et relativt tyndt lag ovenpå DOM), men i det mindste bruges der en velkendt platform og et velkendt sprog. I modsætning til Evil Empire no 2s bud, så skal man ikke til at lære et nyt mere eller mindre obskurt sprog, hvor man lige pludselig skal til at bekymre sig om pointere og garbage collection igen. Måske er der nogen, der hellere ville have haft Mono, men jeg vil til enhver tid foretrække den tooling, der er til rådighed på Java-platformen. Uanset hvad, så er vi jo nogen, der ser det som noget af en fordel at hele skidtet er open source, hvilket ikke kan siges om de eksisterende alternativer :)

  • 0
  • 0
#36 Per Steffensen

Det er godt nok lidt af en diskussion I har gang i her. Det er rart at mærke så stor interesse, og at janteloven lever i bedste velgående - Ole skal jo f..... ikke tro at han er i en position til at kritisere et produkt fra populære Google.

Nu har jeg selv en del erfaring med Android. Har lavet et par spil, og har også lige fået mig en HTC Magic.

Jeg synes telefonen efterlader et rigtigt godt indtryk. Tingene virker! Men når det er sagt, betyder positive brugerreaktioner altså IKKE, at Android SDK er lækkert designet. Man kan sagtens skrive velfungerende applikationer i et middelmådigt SDK.

Jeg vil give Ole ret i alle de problemer han påpeger, men synes bestemt ikke det er nok til at droppe at udvikle til Android. Og desuden mener jeg også at flere af de problemer der påpeges sagtens kan udbedres i fremtidige versioner.

  • 0
  • 0
#37 Mark Gjøl

Hvordan har jantelov noget med noget at gøre? Om noget burde den vel mere gå efter Google for at være store og tro at de kunne opfinde en mobil platform sådan uden videre. Det virker som en kommentar der forsøger at gøre alle der ikke er enige med Ole smålige hoveder der kun mener at han tager fejl af irrelevante grunde.

  • 0
  • 0
#38 Casper Bang

Jeg kan godt nok heller ikke rigtig se hvad jantelov har med sagen at gøre - og det tjener i alt fald ikke noget formål at begynde at sætte folk i bås bare fordi de ikke æder alt ting råt.

Kommer man med så sønderlemmende og ensidig kritik som Ole oprindeligt gør, må der vel forventes en reaktion fra andre der også måtte synes at vide bare lidt om tingene. Som udgangspunkt vil de fleste nok have en "lad os nu lige slå koldt vand i blodet" holdning og prøve at modargumentere. Ole siger jo ikke at det er et middelmådigt SDK, men at det er ekstremt ringe og at man bør holde sig langt væk.

Du har ret i at man ikke skal blande SDK og telefon-oplevelse sammen, men det synes jeg nu heller ikke denne tråd primært bærer præg af.

  • 0
  • 0
#39 Ole Østergaard

Jeg vil give Ole ret i alle de problemer han påpeger, men synes bestemt ikke det er nok til at droppe at udvikle til Android.

Helt enig - og at det står i overskriften på denne artikel, må stå for Tanias egen regning. Det er ikke noget jeg har sagt - tværtimod siger sidste slide på det slideshow hun har brugt som kilde, at jeg sagtens kan forestille mig at Android ender med at blive det dominerende mobil-OS.

  • 0
  • 0
#40 Per Steffensen

Jo OpenGL API'et følger C bibliotkerne, men sådan må det nu engang være. De operationer der findes i Java OpenGL API'et, er nu engang de operationer som OpenGL består af. Man kunne selvfølgelig godt have tilføjet et mere smooth abstraktionslag ovenpå, men det tror jeg godt nok også man skal være forsigtig med. Jeg tror OpenGL interfacet har udviklet sig til det det er, fordi de operationer der findes deri, er de operationer der bringer os op på højeste abstraktionsniveau, uden at lede os ud at skrive ineffektiv kode.

  • 0
  • 0
Log ind eller Opret konto for at kommentere