I denne debattråd udtrykker skribenten alene deres egen holdning om emnet. Hold venligst vores debatregler i tankerne hvis du ønsker at deltage i debatten.

Mine første indtryk af Android-SDK'et...

1
30. oktober 2008 kl. 21:07

De sidste par dage har jeg for alvor leget med Android og lavet en lille "proof of concept"-applikation. Jeg har aldrig udviklet noget før til små enheder, så jeg tænkte at jeg ville dele og diskutere mine første indtryk med gruppen her.

Mit allerførste indtryk var at det var enormt nemt at installere. Og den første applikation (godt hjulpet på vej af Googles Notepad-eksempel) var også ret nem at få kørende, debugging fungerede glimrende.

OK dokumentation af klasserne i standardbiblioteket, selvom der er lidt mangler her og der. Det skal nok blive bedre med tiden. (Jeg brugte ca. 3 timer på at hitte ud af hvordan man kan binde data til en CheckBox i et ListView, hvorefter jeg måtte give op og lave det på en anden måde...)

Men... som sagt har jeg ingen baggrund i mobil systemudvikling, så hvad jeg synes er "god kode" er ikke nødvendigvis hvad en mobil systemudvikler synes er "god kode". Og jeg er gevaldig skuffet over hvordan Android-API'et er skruet sammen. Det ligner noget biks.

For det første skal man nedarve fra Activity-klassen når man skal lave sin egen activity. Ak, så har man lige bundet sig 100% til Activity og dens mange superklasser og kan derfor umuligt teste sin egen klasse i isolation. Hvordan hulen tester man sådan noget spaghetti? I det hele taget virker det ikke som om Google-folkene har bekymret sig særlig meget om hvordan vi stakkels udviklere skal lave testbar kode til Android.

Skal unit-test absolut være bøvlet når man laver mobil systemudvikling?

For det andet virker mange metoder i SDK'en som direkte pendanter til C- eller C++-funktioner: Et hav af argumenter, så man er nødt til at tælle efter med pegefingeren for at sikre sig at man har sat "null" ind de rigtige steder i metodekaldene, og at de resterende strenge står de rigtige steder. (Her tænker jeg især på interfacet til SQLite...) "Clean Code"-bogen prædiker max 3 argumenter pr. metode...

Så er der de mange småting... fx er det meget rart at R.java bliver autogenereret, men hvorfor hulen består den blot af en stavlfuld int'er? Et hav af kald til GUI-metoder bliver noget svære at konstruere, idet de typisk tager et par int'er som skal fiskes ud af R, men som nybegynder må man ofte fægte lidt i blinde for at finde frem til det rigtige tal. Er det mon en af dem under R.layout? Eller under R.id? Er mobile systemudviklere bange for at bruge typer? Måske der stadig lever en frygt for at det sluger sparsom ram?

Alt i alt: Mine allerførste indtryk af SDK'et var gode, men nu hvor jeg har haft fingrene nede i sølet, er jeg noget skuffet over kvaliteten - det virker lidt som om Google har hyret de folk der lavede de første versioner af J2EE :-)

Er det mig der er en sur stodder, eller har I samme oplevelser? Eller er der bare et eller andet jeg ikke fatter om mobil systemudvikling?

settingsDebatindstillinger
2
21. januar 2009 kl. 21:41

SQLite og andre dele af Android er ikke udviklet af Google, men er standarder der har eksisteret i længere tid og som har bevidst sit værd, så dem kan du ikke klandre Google for! :-)

Noget af det er måske ikke det smarteste, men på den anden side er de standarder som bliver brugt andre steder og som bliver vedligeholdt og derfor ikke indeholder børnesygdomme.

/Andrew

2
24. januar 2009 kl. 12:37

Jeg ved godt at SQLite, OpenGL ES osv. ikke er udviklet af Google, og fred være med det. De kunne nu nok godt have gjort noget ud af interfacet til dem. (Jeg går ud fra, fx, at det er Googles egen skyld at man skal lave en masse newIO-buffers for at interface med OpenGL ES, altså at det ikke står i nogen standard hvordan Java-interfacet skal være til OpenGL ES?)

Jeg er også irriteret over de Android-specifikke ting, fx at man absolut skal nedarve fra Activity for at... ja, lave en activity. Så er man med ét fedtet ind i en hel masse ting, og man kan umuligt unit-teste sin egen activity. Og Android-udviklerne har åbenbart fundet ud af at XML er det de unge vil ha' :-)

Sven, hvad er det for gode tanker i Android du taler om? Jeg kan godt se at der er mange gode politiske tanker (altså let tilgængelighed, open-source osv.), men teknisk set synes jeg ikke der er noget man fx skal bede nye datalogi-studerende om at efterabe :-)

Google havde muligheden for at lave et rigtig lækkert framework, idet de jo startede helt forfra og ikke fx havde Java ME at skulle holde sig til. Derfor irriterer det mig at de har forspildt chancen. Der går jo nok et par år inden en anden stor virksomhed også prøver at "starte forfra" med en let tilgængelig, mobil platform. /Ole

2
7. marts 2009 kl. 20:58

For det første er jeg bare glad for at der findes en sql database på den platform. Det er faktisk få mobil platforme man finder sådan noget på. Symbian havde ikke en for ½ år siden, og de andre jeg har set har haft noget hjemmestrikket hø. Så hurrah for databasen, at interfacet så er lidt kringlet..Tja det tager vel 11 minutter at lave en wrapper der passer til ens behov så man er fri for at tælle argumenter. For det andet, mener jeg det er ret sjældent du nogensinde vil have lyst til at unit teste din activity - af den simple grund at det meste der ligger her nok burde være user interaction, swipe, scrool, setup af dataservices + malloc ala findviewbyiD noget, og derfor er det nok ikke lige det mest oplagte i denne verden at unit teste, sådan en for sig selv..Men ja gu er der fejl i skidtet, også i de wrappere de har lavet til sql interfaces for feks media filer. Men alternativet taget i betragning, så er de langt foran, prøv at hente et symbian SDK, eller windows mobile for den sags skyld, og se hvor hurtigt du kommer igang :).

2
24. februar 2009 kl. 12:51

Du kan have ret i en del af dine anker, men til googles forsvar tror jeg at en del af designet at APIet er dikteret af at java bytekoden bliver kompileret videre til dalvik bytekode.

Der er et dokument der beskrive de konsekvenser det har, bla at virtualisering af kald og indirektion bliver uforholdsmæssigt dyrere i forhold til alm. JIT kompileret java kode.

Jeg gætter det har betydet en del for at APIet virker så C agtigt.

til gengæld er jeg enig i at det er skidt at understøttelsen af JUnit testing er så dårlig.

2
24. februar 2009 kl. 19:08

Hmmmm, så til Googles forsvar skal man huske at Google har lavet en dårlig VM? :-)

2
26. februar 2009 kl. 13:21

nu er jeg ikke embedded programmør, men jeg vil tro der er rigtig gode grunde til de begrænsninger der ligger i det.

Der er jo mange hensyn at tage når kode skal afvikles på en begrænset platform som en mobiltelefon. hastighed, strømforbrug osv.

Jeg er ret imponeret over at man rent faktisk er nået frem til noget der stort set er almindelig java.

2
26. februar 2009 kl. 20:46

Man har da i mange år kunnet køre Java på meget mindre telefoner end G1? Jeg har ingen anelse om hvordan Dalvik performer i forhold til de andre Java-VM'er til mobiltelefoner. Kender nogen til performance-sammenligninger?

Og man kan vel ikke engang kalde det en Java-VM, da den ikke kører på rigtig Java-bytecode?

Lars Bak & co. lavede en fin Java-VM til mobile enheder for nogle år siden. Lidt ærgerligt at Google satte ham til at lave en JavaScript-VM til Chrome i stedet for en Java-VM til Android :-)

2
21. januar 2009 kl. 17:23

Hej Ole.

Tror mest der er fodi vi har kodet ruby i et stykke tid, og derfor har nogle andre forventninget til hvad hvordan et api er skruget sammen.

Jeg har heller ikke været hel vild med det jeg har set alle steder.

Vil dog stadig nævne at der er så mange gode tanker i android er der så riligt ophæver de små fejl.

/Sven

2
21. januar 2009 kl. 21:36

Hej Sven!

Jeg har mest lavet C# og Java på arbejde, og kun lidt Ruby "her og der", så jeg er ikke så forkælet som I andre er ;-)

I statisk typede sprog kan man nemt lave løst koblede komponenter, og så fx bruge dependency injection til at sætte det hele sammen. Så er alting rigtig nemt at unit-teste. Det er der ingen af Googles programmører der har skænket en tanke. I stedet har de efterlignet hvordan Sun lavede de oprindelige udgaver af J2EE, hvor man i stedet for POJOs absolut hele tiden skulle nedarve fra alle mulige klasser i standardbiblioteket, med den konsekvens at man umuligt kunne hive sine egne klasser ud og teste dem i isolation.

Og så er der tåbeligheder, som fx det her blog-indlæg fra for nylig: http://android-developers.blogspot.com/2009/01/why-is-my-list-black-android.html

Vorherre til hest... her er åbenbart tale om udviklere der vælger at mikro-optimere, med den konsekvens at man har et API man ikke bare lige "tager fat på", men skal kende alle spidsfindighederne i.

Det virker meget umodent af Googles udviklere, men problemet er at nu har de publiceret deres API med alle de fejl der nu er, og folk koder op mod det, så det vil aldrig kunne fikses.

/Ole