Android tutorialer/bøker?

[frankhaugen]

Jeg tenker at jeg skal leke litt med android app'er, jeg har litt kunnskap innen Java men min sterke side er PHP og .net, så jeg trenger noen Android tutorialer for noobs, bøker, videotutorialer, og lignende er det jeg ser etter.

 

takk for all hjelp

 

-frank

[etse]

Det du trenger er å lære deg java enda bedre. Når du kan java er det å lære seg android egentlig en lek, da hele opplegget er veldig enkelt og intuitivt.

 

Personlig gikk jeg gjennom "notepad" tutorialene her:

http://developer.android.com/resources/browser.html?tag=tutorial

 

Og da følte jeg at jeg fikk en god introduksjon, men kan være en ide og starte helt fra Hello, World og bygge seg oppover. Om du har god kjennskap med .NET og gui-utvikling fra før vil du ta det til deg veldig fort da det egentlig er veldig likt.

[frankhaugen]

Det du trenger er å lære deg java enda bedre. Når du kan java er det å lære seg android egentlig en lek, da hele opplegget er veldig enkelt og intuitivt.

 

Personlig gikk jeg gjennom "notepad" tutorialene her:

http://developer.android.com/resources/browser.html?tag=tutorial

 

Og da følte jeg at jeg fikk en god introduksjon, men kan være en ide og starte helt fra Hello, World og bygge seg oppover. Om du har god kjennskap med .NET og gui-utvikling fra før vil du ta det til deg veldig fort da det egentlig er veldig likt.

Jeg tenkte å ta det ifra scratch, da jeg av erfaring har lært at selv om programmeringsspråk er veldig like er de skjeldent identisk , og man kan aldri få repitert frasen "remember to comment your code" nok

 

takk for linken, så bra ut det der

 

-frank

[etse]

og man kan aldri få repitert frasen "remember to comment your code" nok

Om du må kommentere koden din, er ikke koden din god nok. Kode skal være selvforklarende. Føler du at du må bruke en kommentar for å gjøre den forstålig må du enten bruke bedre variabel, klasse og funksjons navn. Eventuelt så må du deler opp koden din i flere metoder, funksjoner og klasser.

[Kiff]

Vanligvis prøver jeg å styre klar av slike "meningsdiskusjoner", men i frykt for at flere tar til seg denne praksisen er jeg nødt til å presentere en motvekt

 

Det er grusomt å håndtere "selvforklarende" kode når du jobber med vedlikeholdsprogrammering og debugging, fordi den er aldri det. Uantsett hvor mye du prøver, så er kode til slutt ment for compileren og ikke mennesker. Det tar noen minutter å kommentere en lang metode, men det kan spare flere timer i debugging senere.

 

Ja du SKAL ha forklarende metodenavn og variabelnavn (bruk refactor og code completion i IDEen til å hjelpe deg, trekk gjerne ut kode i egen metode selv om den bare kalles en gang), men en kort kommentar som forklarer hva en komplisert blokk var ment til å gjøre (det kan jo hende den ikke virker slik det opprinnelig var tenkt) gjør underverker.

 

F.eks så skrev jeg nettopp en metode som ser ganske meningsløs ut, men det er en bug i et annet system som jeg må jobbe rundt. Jeg kan ikke ha et metodenavn/variabelnavn som forklarer en lang email korrespondanse, releaseversjonen dette skjer, situasjonen hvor dette intreffer og kontaktperson for status oppdateringer i fremtiden. En kort kommentar om at dette er en kjent bug og henvisning til oppgave-tracker systemet hvor utdypningen ligger derimot forklarer alt.

 

Tips:

Alle public metoder som du regner med andre skal bruke, bør ha forklarende javadoc.

Alle kompliserte kodesnutter bør ha en kort kommentar som forklarer hva blokken gjør.

Vurder package-info og kommenter hva pakken din inneholder

[anderfo]

Den beste Android-tutorialen jeg har funnet er lagd av "MyBringBack" og ligger på youtube. En serie med 38 tutorials som stort sett "henger sammen" men man kan hoppe inn hvor man vil omtrent.

 

Etter å ha kikket gjennom de første 8-10 tutorialene (tar ca 1 time) kunne jeg nok til å skrive min første app. Den er her:

https://market.android.com/details?id=skiwaxapp.norwegian&hl=no

[etse]

Vanligvis prøver jeg å styre klar av slike "meningsdiskusjoner", men i frykt for at flere tar til seg denne praksisen er jeg nødt til å presentere en motvekt

 

Det er grusomt å håndtere "selvforklarende" kode når du jobber med vedlikeholdsprogrammering og debugging, fordi den er aldri det. Uantsett hvor mye du prøver, så er kode til slutt ment for compileren og ikke mennesker. Det tar noen minutter å kommentere en lang metode, men det kan spare flere timer i debugging senere.

 

Ja du SKAL ha forklarende metodenavn og variabelnavn (bruk refactor og code completion i IDEen til å hjelpe deg, trekk gjerne ut kode i egen metode selv om den bare kalles en gang), men en kort kommentar som forklarer hva en komplisert blokk var ment til å gjøre (det kan jo hende den ikke virker slik det opprinnelig var tenkt) gjør underverker.

 

F.eks så skrev jeg nettopp en metode som ser ganske meningsløs ut, men det er en bug i et annet system som jeg må jobbe rundt. Jeg kan ikke ha et metodenavn/variabelnavn som forklarer en lang email korrespondanse, releaseversjonen dette skjer, situasjonen hvor dette intreffer og kontaktperson for status oppdateringer i fremtiden. En kort kommentar om at dette er en kjent bug og henvisning til oppgave-tracker systemet hvor utdypningen ligger derimot forklarer alt.

 

Tips:

Alle public metoder som du regner med andre skal bruke, bør ha forklarende javadoc.

Alle kompliserte kodesnutter bør ha en kort kommentar som forklarer hva blokken gjør.

Vurder package-info og kommenter hva pakken din inneholder

 

Om funksjoner og metoder er så lange at de blir uforstålige er ikke problemet at den er kommentert - men at metoden er for lang. Man deler den da opp i flere små metoder med greie navn.

 

Problemet med kommentarer er når man vedlikeholder kode og gjør endringer på koden - så glemmer man ofte å endre kommentarene. Man sitter da plutselig igjen med kommentarer som er upresise eller i enkelte tilfeller direkte feil; noe som gjør det enda vanskeligere å håndtere koden din. Dette problemet har jeg ikke merket på langt nær like mye når det gjelder kode som er skrevet selvforklarende. Man blir mye lettere minnet på å endre et metodenavn om man har endret funksjonaliteten - enn man blir minnet på å endre kommentaren som står noen linjer over.

 

Nå blir det feil å kanskje si at man ALDRI skal kommentere koden sin, da det finnes unntak. Men pleier å ha en fin tommelfinger regel at om jeg må kommentere koden min burde jeg se over koden og heller prøve å skrive den på en annen måte som er selvforklarende.

 

Om man lager et API som skal brukes av andre systemer er selvfølgelig dokumentasjon et must-have slik at man vet hva de ulike metodene gjør og hva de returnerer. (selv om det også burde være litt selvforklarende ut i fra metodenavn, klassenavnet + parametere.).

[Matsemann]

Etse, det finnes en mellomting. Og det er lite relevant for trådstarter.

[Sono Juventino]

og man kan aldri få repitert frasen "remember to comment your code" nok

Om du må kommentere koden din, er ikke koden din god nok. Kode skal være selvforklarende. Føler du at du må bruke en kommentar for å gjøre den forstålig må du enten bruke bedre variabel, klasse og funksjons navn. Eventuelt så må du deler opp koden din i flere metoder, funksjoner og klasser.

 

Muligens det dummeste jeg noen gang har hørt. Lykke til i utviklingen av større programmer. Når du kommer tilbake til prosjektet etter tre måneder, skulle du virkelig ønske du hadde kommentert. Når du også tar med deg en annen på prosjektet, kommer han/hun til å lynsje deg for å drite i kommentering.

 

Når folk så skal bruke ditt ferdige program, kommer de til riste på hode av at metodene dine ikke er kommentert.

 

Les opp på Javadoc og slutt å skrive piss...

[_Xorcist]

og man kan aldri få repitert frasen "remember to comment your code" nok

Om du må kommentere koden din, er ikke koden din god nok. Kode skal være selvforklarende. Føler du at du må bruke en kommentar for å gjøre den forstålig må du enten bruke bedre variabel, klasse og funksjons navn. Eventuelt så må du deler opp koden din i flere metoder, funksjoner og klasser.

 

Muligens det dummeste jeg noen gang har hørt. Lykke til i utviklingen av større programmer. Når du kommer tilbake til prosjektet etter tre måneder, skulle du virkelig ønske du hadde kommentert. Når du også tar med deg en annen på prosjektet, kommer han/hun til å lynsje deg for å drite i kommentering.

 

Når folk så skal bruke ditt ferdige program, kommer de til riste på hode av at metodene dine ikke er kommentert.

 

Les opp på Javadoc og slutt å skrive piss...

 

I et public API i et library/framework så er det kanskje nyttig med JavaDoc, men hvor ofte skriver du egentlig den type kode? Jeg vil stort sett mye heller ha eksempler i form av f.eks. unit-tester. De er jo tross alt nødt til å stemme overens med hvordan koden faktisk fungerer og kommer derfor ikke ut av sync med koden etterhvert som koden vedlikeholdes.

 

Når det gjelder denne type JavaDoc, som jeg faktisk har sett mye av på prosjekter hvor noen av en eller annen grunn har bestemt at JavaDoc er jævla viktig, så er det bare støy og faenskap

 

/**
* @param value the value to set
*/
public void setValue(String value) {
   this.value = value;
}

 

Det eneste som er verre enn dette er selvfølgelig følgende kodesnutt som også er ganske vanlig i slike prosjekter:

 

/**
* @param value the value to set
*/
public void setText(String text) {
   this.text = text;
}

 

Nei, skriv heller korte metoder, med gode navn og signaturer og ikke MINST små og presise unit tester med gode navn.

 

EDIT: Oi, dette var en Android-tråd. Jeg glemte det helt bort her jeg satt og leste meg nedover. Beklager OT!

Endret 25. februar 2012 av _Xorcist