[Ervaringen] Android SDK

[Stukfruit]

Woah, dat zou echt geweldig zijn

* Stukfruit gaat meteen aan de slag met het updaten...

[Py.]

Als extra aanvulling op de emulator:

Other VM Drivers - If you are running another virtualization technology on your system such as VirtualBox or VMWare, you may need to unload the driver for that virtual machine hosting software before running an accelerated emulator.

Chris Smith - How does the hardware acceleration affect other virtualization software (VirtualBox)? The guide says we need to "unload" them. I'm not clear what that means. Do I need to uninstall VirtualBox? Is it possible to keep it on my machine but not use them at the same time?
10:50 PM

Xavier Ducrohet - +Chris Smith if you don't use them at the same time you should be fine.
10:57 PM

Chris Smith - Awesome thanks, you should make that more clear in the docs though, I was worried!

[Stukfruit]

Gelukkig maar

Het is trouwens wel wat werk om uit te vogelen zeg.. Zo staat er bij mij in de SDK manager (na de update) bv. *geen* system image voor x86 in de lijst.

De Intel Hardware Accelerated Execution Manager was daarentegen wel te vinden en te installeren, dus ik heb nu even daar mijn hoop op gevestigd. Misschien worden de extra opties voor de images zichtbaar zodra dat allemaal werkt?

Je moet trouwens ook een cpu hebben die Hyper-V ondersteunt. Als je cpu niet op de volgende lijst staat met een "yes" erachter, dan heb je pech: http://ark.intel.com/VTList.aspx

Ook moet je in je bios de ondersteuning voor deze feature eerst aanzetten, anders krijg je bij het uitvoeren van die hardware accelerated execution manager een foutmelding.

* Stukfruit gaat zometeen dus even voor het eerst in vijf jaar het bios weer eens bekijken...

---

Edit: oh, voor de mensen die geen ervaring hebben met het foutloos aanzetten van Hyper-V: http://www.shnake.com/blog/?p=419

Oa. de Execute Disable-optie moet blijkbaar op enabled staan (dus DEP zal dan uit staan).

[ Voor 11% gewijzigd door Stukfruit op 21-03-2012 23:53 ]

[Py.]

De image zit verstopt onder android 2.3.3 (API10) onder de naam: Intel Atom x86 system image
Deze ondersteund dus alleen 2.3.3... Zojuist even getest met mijn spel en het was inderdaad aanmerkelijk sneller in de emulatie.

Ik draai overigens ook regelmatig een VM in VirtualBox, zolang deze niet aanstaat geeft dit inderdaad geen problemen.

Aantal andere dingen die me opvielen bij de nieuwe SDK:
* er is weer het nodige depricated gemaakt
* actionbarsherlock wou niet meer compilen zonder codefix (protected -> public)
* ik moest een clean all doen om mijn libraries in sync te krijgen

Verder ziet het er tot nu toe goed uit

[ Voor 10% gewijzigd door Py. op 21-03-2012 23:56 ]

[Stukfruit]

Nee, hij stond er eerst echt niet tussen. Ook niet bij API10 Maar net voordat ik wilde gaan blaten checkte ik nog even de SDK Manager opnieuw en plotseling zag ik er opeens allemaal opties bij komen. Blijkbaar moet je soms even geduld hebben

Wat me trouwens in de release notes opviel is dat *alle* libs die nu onder de libs-directory staan automatisch zouden worden meegenomen door ADT, dus als je daar (net zoals ik tot nu toe) een paar loze libs in hebt staan dan is het een goed idee om die er eerst even uit te gooien.

---

Edit: nog even die Intel system image geprobeerd zonder Hyper-V. Dat is inderdaad al een klein beetje sneller. Kan nog beter, maar ieder beetje is mooi meegenomen. Sommige dingen werken alleen niet erg goed. Nine-patches laten soms bv. tekenfouten zien en advertenties van Admob zijn gewoon te zien, ondanks het gebruik van de testmode.

[ Voor 24% gewijzigd door Stukfruit op 22-03-2012 00:44 ]

[Anoniem: 18507]

Iemand anders die nu problemen ondervind na update met external JAR's ? Krijg nu alleen maar noclassdef exceptions.

[Stukfruit]

Clean all

[Anoniem: 18507]

Stukfruit schreef op donderdag 22 maart 2012 @ 00:58:
Clean all

Clean all had ik al gedaan. Probleem zit in hier

Added feature to automatically setup JAR dependencies. Any .jar files in the /libs folder are added to the build configuration (similar to how the Ant build system works). Also, .jar files needed by library projects are also automatically added to projects that depend on those library projects.

Jar files zaten in /lib .
Voordeel is nu wel dat projects nu ook de libraries overnemen in de /libs folder van een gekoppeld Android library project.

[TheCrius]

Ik wou al eens een poging doen: een Android App maken. De basis van Java heb ik wel, geen diepe kennis. Wat ik erg vervelend vond (rond 1,5 jaar terug), was dat er weinig te vinden was over het maken van een nette GUI. Hier zijn zeker geen plugins voor? Hoe hebben jullie dat ervaren?

[Stukfruit]

ADT (de Android-plugin voor Eclipse) heeft een tool om bestanden voor de interface visueel te bewerken, maar ik betrap mezelf erop dat ik eigenlijk altijd direct de xml-bestanden bewerk omdat dit duidelijkere structuren oplevert en sneller is.

Zolang je overal dips ipv pixels en altijd schaalbare layouts gebruikt (dus geen AbsoluteLayout) dan is het best simpel

En als je wat ingewikkeldere interfaces wil maken aan de hand van bv. een mockup die je in Photoshop hebt opgezet dan zijn er ook best veel mogelijkheden, zoals het gebruik van nine patches en LayerDrawable's (layer-list in xml). Bij dat laatste is het alleen wel aan te raden om 32 bpp te gebruiken voor je activity (bij versies lager dan Gingerbread is het nog standaard 16 bpp, wat je niet de werkelijk opgegeven kleuren geeft en alpha blending lelijk maakt).

Verder kan je natuurlijk veel afkijken uit de SDK demo, maar wat vooral belangrijk is is dat je *vooraf* bedenkt wat je wil maken en het dan pas gaat uitwerken. Anders ga je al snel zitten prutsen en raak je het overzicht kwijt zodra je xml-bestanden voor de interface wat complexer worden.

[falcon4ever]

Naast wat Stukfruit al heeft benoemd denk ik dat het ook handig is om de tool hierarchyviewer uit te proberen. Hij zit in 't mapje tools van je android-sdk map. Daarmee kan je (mits je in de simulator zit of een debug rom draait op je phone) de layout van elk programma bekijken. Best handig als je op zoek bent naar voorbeelden of graag wilt weten hoe programma X in elkaar steekt. Het geeft je niet de broncode, maar wel hoe de lagen zijn opgebouwd.


Trouwens, zojuist de nieuwe SDK tools en x86 image geinstalleerd (inc de intel driver voor virtualisatie, Intel Core2 Duo P8700 wordt ondersteund), maar ik word noch warm noch koud van 't resultaat. Voor m'n gevoel is de emulator nog niet echt veel sneller geworden. Als ik bijv op de menu knop druk, zie ik niet echt een soepele animatie zoals op m'n phone.

[ Voor 28% gewijzigd door falcon4ever op 22-03-2012 01:41 ]

[TheCrius]

Bedankt Falcon en Stukfruit. Het was inderdaad het geval dat ik ging lopen prutsen. Uiteindelijk kom je uit bij een heel erg statisch en onoverzichtelijk xml bestand die je liever verwijdert dan houdt...
Ik zal binnenkort op een rustige dag weer eens een poging doen en de tips helpen me zeker.

[Stukfruit]

Valt wel mee met dat statische hoor Ik maakte zelf eerst liever interfaces via code, maar nu doe ik alles met xml. Zelfs bitmaps die bv. herhalend moeten worden weergegeven pleur ik nu vrolijk in een xml-bestandje als bitmap-drawable

Is ook goed omdat je zo de zaak gescheiden houdt van je code (wat daardoor weer mooier en duidelijker kan blijven).

Zolang je naast dat vorige hierboven ook onthoudt dat je LinearLayout's moet gebruiken om doelloos widgets onder of naast elkaar te stapelen en RelativeLayout's als je echt iets wil uitlijnen (kan zelfs op de baseline van een tekst) of specifiek naast of onder een andere widget wil hebben, dan komt alles al snel goed

Als je een voorbeeld hebt dat je wil maken dan mag je dat gerust hier posten trouwens. Altijd goed om wat kennis heen en weer te laten gaan voor het (beter) maken van goede interfaces

[Stukfruit]

Stukfruit schreef op donderdag 22 maart 2012 @ 00:10:
Sommige dingen werken alleen niet erg goed. Nine-patches laten soms bv. tekenfouten zien en advertenties van Admob zijn gewoon te zien, ondanks het gebruik van de testmode.

Ah, ik begrijp het al. Alles met WebView's werkt niet onder de x86 system image.

Nouja, het werkt wel, maar erg brak en crasht razendsnel. Sommige advertenties van bepaalde bedrijven laten zelfs de boel keer op keer opnieuw opstarten dankzij de brakke WebView (en blijkbaar ook brakke advertentiecode die in een loop blijft proberen om de gecrashte WebView opnieuw aan te maken zonder te stoppen).

Dus als je advertenties in je app hebt zitten dan is het erg onverstandig om x86 te gebruiken. En daarmee wordt het ook gelijk volledig nutteloos. Zucht.

[Jegorex]

Ik heb een subproject aan mijn project gekoppeld, maar alle classes die in het subproject staan worden niet meer herkent. Eclipse geeft geen foutmeldingen, maar als ik het in de emulator of op mijn eigen telefoon uitvoer krijg ik NoClassDefFoundError's.
De enige oplossing die ik tot nu toe gevonden heb ik het subproject te ontkoppelen en de source folders te linken in mijn hoofd project.

[JustAnotherDev]

Toevallig tijdens het browsen kwam ik een comment tegen van iemand met hetzelfde probleem als jij.
Daar werd deze oplossing gegeven.

[Jegorex]

Dat had ik ook al gelezen, maar dat gaat over jar libraries.
Ik had problemen met het toevoegen van een extra project (waar ik mijn gedeelde code in heb staan) aan mijn hoofd project. Dat is dus geen jar file.

[Anoniem: 18507]

Jegorex schreef op donderdag 22 maart 2012 @ 21:13:
Dat had ik ook al gelezen, maar dat gaat over jar libraries.
Ik had problemen met het toevoegen van een extra project (waar ik mijn gedeelde code in heb staan) aan mijn hoofd project. Dat is dus geen jar file.

Het library project moet ingesteld staan als Android library project het andere project moet dit als library toevoegen. Dit moet gebeuren in Eclipse bij de Android tab i.p.v. Java Build Path.
Project.properties van het library project moet ingesteld hebben: android.library=true
En in de gebruikers moet het verwijzen naar de folder van het library project: android.library.reference.1=../LibraryProject

[Jegorex]

Bedankt, daar was ik naar op zoek.
Ik zat de hele tijd in de Java Build Path tab te zoeken.

[Bananenspin]

Welke methode is geliefder onder jullie ervaren Android devvers?

Een android:onClick="dezeFunctie" in je xml
of
button.setOnClickListener(new View.OnClickListener() {
public void onClick(View v) {
dezeFunctie();
}
});

Ik ben zelf bekend met Java dus ben een actionListener gewend wat ongeveer op dat tweede lijkt maar dan een stuk onduidelijker! Is er geen kortere mogelijkheid voor?

[Stukfruit]

XML is niet kort genoeg?

[Bananenspin]

Haha dat wel, maar ik vroeg me af of er voor die tweede methode ook geen kortere methode was vanwege een stukje gewenning.

[ThinkCreative]

Ik heb er eigenlijk nooit bij stil gestaan om onClick="functie" te gebruiken. Om de een of andere reden doe ik het liefst zoveel mogelijk programmatisch.

[Jegorex]

Ik maak de statische layout in XML en alle interactie doe ik in Java.

[Jegorex]

Omdat ongeveer 93% van de Android telefoons Android 2.2 of hoger heeft dacht ik OpenGL 2.0 voor mijn nieuwe project te gebruiken...

[Enfer]

Jegorex schreef op woensdag 04 april 2012 @ 14:45:
Omdat ongeveer 93% van de Android telefoons Android 2.2 of hoger heeft dacht ik OpenGL 2.0 voor mijn nieuwe project te gebruiken...

[afbeelding]

Mjah, uiteindelijk merk je in praktijk dat het toch veel soepeler & beter is om de code op een echt toestel te testen.. De emulator is leuk en aardig, maar op een echt toestel merk je pas goed de look & feel van je app, alsmede het feit of je app vloeiend loopt of juist totaal niet.

Vooral bij games/simulaties (ik neem aan dat je daar OpenGL 2.0 voor gebruikt) is usability en soepelheid van je app een erg belangrijk punt, dus ik kan me ergens wel voorstellen dat ze OpenGL 2.0 niet in de emulator inbouwen..

[Py.]

Goed nieuws: http://android-developers...with-better-hardware.html

[...]
Today we’re thrilled to announce several significant improvements to the emulator, including a dramatic performance upgrade and support for a broader range of hardware features, notably sensors and multi-finger input.

Added GPU Support

The system image we’re shipping today has built-in GPU support (Android 4.0.4). With Android’s growing reliance on using the GPU to improve performance, the difference is significant. In the video below, the emulator is still interpreting ARM instructions; the performance boost is the effect of putting the GPU to work.

As a bonus, since we’re now supporting OpenGL ES 2.0, your OpenGL games can now run inside the emulator.
[...]
Meer info op de gelinkte pagina.

[ Voor 6% gewijzigd door Py. op 09-04-2012 20:48 ]

[Anoniem: 18507]

Eindelijk kan je ICS een beetje normaal testen in de emulator

[Stukfruit]

Wauw, en ook nog eens GLES 2.x!

* Stukfruit gaat het straks meteen testen.. dit voelt een beetje als een cadeautje op sinterklaasavond

[Stukfruit]

Sinds ik de image voor Android 4.0.3 gebruik valt het me op dat de kleuren er echt uitzien alsof ze kotsmisselijk zijn, terwijl ik *wel* overal getWindow().setFormat(PixelFormat.RGBA_8888); gebruik tijdens de setup van een Activity (natuurlijk alleen waar nodig).

Vooral met een kleurverloop is het probleem goed te zien. De boel wordt gewoon geconverteerd naar 16 bpp ipv 24 of 32 bpp, zoals gevraagd via de oproep hierboven, terwijl dit onder vorige versies van Android niet het geval was. Waarom werkt dit niet meer in 4.0.3?

Op Stackoverflow zijn er ook meerdere mensen die hier over klagen en wordt de suggestie gewekt dat het probleem zich alleen zou voordoen in de brakke 4.0.3-image, die uberhaupt niet bepaald een prijs mag winnen qua stabiliteit, maar nergens wordt vermeld of dit ook echt het geval is.

Zijn hier misschien mensen die het met 4.0.3 op een fysiek apparaat hebben getest en kunnen bevestigen dat het alleen in de emulator zo lelijk is?

[echthard]

Weet iemand hoe ik het makkelijkst/snelst aan de code met camera functionaliteit uit ICS kan komen?

[EddoH]

source.android.com ?

[echthard]

Is dat echt de makkelijkste optie? Om heel AOSP te pakken en daar dan ergens de camera functionaliteit in te zoeken?

[EddoH]

in de tijd dat je besteed hebt om de makkelijkste manier te zoeken had je de complete source tree al kunnen downloaden ja

Misschien kun je even verduidelijken wat je bedoeld en wat je wilt bereiken. Als je de Android sourcecode heb kun je daar redelijk makkelijk de camera interfacing code in vinden, maar of dit is wat je zoekt?

[echthard]

Ik wil de panorama functionaliteit gebruiken die in de camera app zit van ICS. Of ik dit er uit kan halen of de gehele app moet gebruiken is mij om het even, maar ik wil gebruik kunnen maken van die panorama functionaliteit.

[EddoH]

Dan zou ik de stock camera source app uit de GIT repo downloaden en daar is even gaan rondsnuffelen. source.android.com dus.

[Stukfruit]

dhhdante schreef op dinsdag 24 april 2012 @ 14:07:
Weet iemand hoe ik het makkelijkst/snelst aan de code met camera functionaliteit uit ICS kan komen?

Via Grepcode natuurlijk
http://grepcode.com/proje...m.google.android/android/

Veel handiger dan alles downloaden!

[echthard]

thanks!

Ik had ook al een pakketje gedownload van AOKP, volgens mij staat daar hetzelfde in: https://github.com/AOKP/packages_apps_Camera

Maar nu moet ik er wel uitkomen ( hopelijk )

[EddoH]

Stukfruit schreef op dinsdag 24 april 2012 @ 15:07:
[...]


Via Grepcode natuurlijk
http://grepcode.com/proje...m.google.android/android/

Veel handiger dan alles downloaden!

Wat is er handig aan om de source in een webinterface te bekijken zonder een fatsoenlijke searchfunctie?
Nouje, ieder z'n ding zal i kmaar zeggen

[Stukfruit]

Gebruik het en je weet het

[EddoH]

Heb ik net even gedaan: not for me Ik vind het niet lekker werken, maar dat heb ik bij vrijwel alle web interfaces.. Manier van zoeken bevalt me niet, layout vind ik k*t, en de algehele feel....ik weet niet.

Dan doe ik nog liever zelf een grep...

[Stukfruit]

Als je het echt moet gebruiken dan kom je er vanzelf achter dat het heel nuttig kan zijn. En natuurlijk, je kan zelf de code downloaden, zelf greppen, zelf branches uitkiezen, zelf branches switchen, zelf na het greppen naar de bijbehorende mappen met code zoeken (of doorklikken als je een IDE gebruikt), enzovoorts.

Maar dit is handiger.

* Stukfruit was trouwens ook ooit een webinterface-hater totdat hij eens wat meer begon rond te klikken en er bij sommige interfaces de meerwaarde van begon in te zien...

[Barryvdh]

Volgens mij zijn hier een aantal fan van phpStorm voor php, maar gebruiken er hier ook mensen Jetbrains IntelliJ IDE, in plaats van Eclipse? Het is wel mogelijk volgens de site (http://www.jetbrains.com/idea/features/google_android.html), maar werkt het net zo goed / beter / anders?

[EddoH]

Stukfruit schreef op dinsdag 24 april 2012 @ 19:33:
Als je het echt moet gebruiken dan kom je er vanzelf achter dat het heel nuttig kan zijn. En natuurlijk, je kan zelf de code downloaden, zelf greppen, zelf branches uitkiezen, zelf branches switchen, zelf na het greppen naar de bijbehorende mappen met code zoeken (of doorklikken als je een IDE gebruikt), enzovoorts.

Maar dit is handiger.

* Stukfruit was trouwens ook ooit een webinterface-hater totdat hij eens wat meer begon rond te klikken en er bij sommige interfaces de meerwaarde van begon in te zien...

Soms is een web-based code browser best briuikbaar, dat geef ik toe, maar dan gebruik ik liever OpenGrok, die ik echt een stuk prettiger vind werken:)

[ruby01]

Ik overweeg om eens te beginnen (ik heb al basiskennis java) met android-programmeren,
nu kom ik op 2 dingen:
http://www.androidworld.n...droid-de-benodigde-tools/ ->java-taal
en
http://developer.android....iews/hello-tabwidget.html ->andere taal?
Wat is het verschil in beide talen en zijn er meer/minder mogelijkheden met de eerste link?

[Lorem_Ipsum]

ruby01 schreef op maandag 07 mei 2012 @ 19:19:
Ik overweeg om eens te beginnen (ik heb al basiskennis java) met android-programmeren,
nu kom ik op 2 dingen:
http://www.androidworld.n...droid-de-benodigde-tools/ ->java-taal
en
http://developer.android....iews/hello-tabwidget.html ->andere taal?
Wat is het verschil in beide talen en zijn er meer/minder mogelijkheden met de eerste link?

Die "Andere taal" is xml en wordt gebruikt voor de GUI/Layout van je app. Voor het echte programmeerwerk moet je inderdaad java gebruiken.

[ Voor 12% gewijzigd door Lorem_Ipsum op 07-05-2012 19:21 ]

[alex3305]

Of C/C++ als je een native applicatie wilt ontwerpen, echter is dat alleen voor zeer specifieke doelen geschikt.

Maar inderdaad, Java + XML wordt normaliter gebruikt voor Android applicaties.

[ruby01]

ok, bedankt voor de reactie en sorry voor de stomme vraag

[jacobras]

ruby01 schreef op maandag 07 mei 2012 @ 20:11:
ok, bedankt voor de reactie en sorry voor de stomme vraag

Welnee joh, is niets stom aan. Kan me best voorstellen dat het er verwarrend uitziet als je net begint met Android-ontwikkeling en alles er omheen

XML wordt hier dus gebruikt voor de layout/GUI van je app. Je kan alles ook in code opbouwen, maar dat wil je doorgaans niet. Wat je wel eens kan willen is een XML-element in Java-code manipuleren. Dus stel je hebt een <LinearLayout> in je XML-bestand, die kan je in je Java-code gewoon ophalen en er dingen aan wijzigen. Verschillende talen, maar uitwisselbare elementen als het ware.

[ Voor 38% gewijzigd door jacobras op 07-05-2012 21:04 ]

[alex3305]

Je zal wel je interface moeten manipuleren in Java om een werkbare app eruit te krijgen hè . Een app zonder visuele feedback is ook zoiets.

Verder werkt layouts maken in XML best wel goed hoor. Je hebt er ook een (imho) simplistische layout designer bij waarin je een hoop kunt doen. In XML kun je dan wat zaken aanpassen zodat het er allemaal goed uitziet. Daarna kun je in Java eventuele feedback geven in je layout door R te gebruiken, maar voor zover ik weet staat dat allemaal netjes uitgelegd in de Android SDK reference en tutorials.

---

Zijn er overigens ook al mensen bezig geweest met de S-Pen SDK nu Samsung die leuke wedstrijd heeft uitgeschreven? Ik heb al wel wat ideeën voor een leuke app en game, maar goed het is voor mij alweer een tijdje geleden dat ik iets met Android heb gedaan om ontwikkelvlak.

[Khaine]

Na een behoorlijke tijd her en der erover gelezen te hebben heb ik toch maar besloten ook eens een stapje te wagen in de wondere wereld van Android .

Ik gebruik Ubuntu 11.10 en Eclipse met de ADT plugin en die combinatie maakt het toch best wel erg eenvoudig om een app te maken en draaien (simpelweg mijn hannspad via USB naar laptop en dan "run" doen om te draaien). Zelf kom ik uit de hoek van Python dus ik heb de basisprincipes van OOP al aardig onder de knie. XML is ook goed te doen en ik heb zojuist mijn eerste, doch simpele, dice-generator gemaakt. Rol een X aantal dobbelstenen met een X aantal kanten en laat het resultaat aan de gebruiker zien.

So far, so good, alleen heb ik geen idee hoe nu verder te gaan. Het uiteindelijke doel is simpele games/programmatjes te schrijven, maar voor nu zoek ik dus projectjes om nog eens flink te oefenen en de library's onder de knie te krijgen.

Hoe pakken de medetweakers dit aan? Hebben jullie altijd concrete ideen bij het begin? Een opdracht voor werk bijvoorbeeld, of wordt er gebruik gemaakt van tutorials e.d.? Ik ben wel benieuwd.

Tot zover ben ik trouwens ook wel erg tevreden over de snelheid en het gemak van het opzetten van een applicatie!

[Stukfruit]

Hetzelfde als met normale programma's eigenlijk. Idee > papier > uitwerken > opzetten > programmeren > polijsten > klaar.
Hoewel dat iets overversimpeld is

Om libraries onder de knie te krijgen doe je ook gewoon net als anders. Even snel een testprojectje maken en spelen met de API voor de library. Denk je te weten hoe het allemaal in elkaar zit en werkt het goed in de test, dan gebruik je het voor het echte werk.

En nooit zomaar wat aanprutsen en denken "het komt later wel goed", want dat komt het niet. Altijd eerst uitwerken. Zeker ook voor zoiets als de interface: eerst mockup maken in Photoshop (of GIMP, etc), daarna uitwerken. Dan maak je je leven een stuk simpeler omdat je dan niet meer hoeft te gokken (of honderd keer opnieuw compilen voor om bv. een knop netjes uitgelijnd te krijgen) hoe alles in elkaar moet passen.

[Anoniem: 241683]

Begin met een leuk idee
Anders krijg je alleen maar halve apps die net niets kunnen.
En met stukfruit ^ over de voorbereiding

[Ryur]

Anoniem: 241683 schreef op vrijdag 11 mei 2012 @ 08:33:
Begin met een leuk idee
Anders krijg je alleen maar halve apps die net niets kunnen.
En met stukfruit ^ over de voorbereiding

Ook tips voor de zin "Begin met een leuk idee"?

Stukfruit schreef op vrijdag 11 mei 2012 @ 00:01:
En nooit zomaar wat aanprutsen en denken "het komt later wel goed", want dat komt het niet. Altijd eerst uitwerken. Zeker ook voor zoiets als de interface: eerst mockup maken in Photoshop (of GIMP, etc), daarna uitwerken.

Mockup in Photoshop of GIMP ofzo? Daar heb ik nog nooit van gehoord, dat is bij mij stap 2 altijd.
Ik maak eerst de Mockup in een aparte tool ervoor (Balsamiq ofzo, in mijn geval Axure RP), en dan pas met een Photoshop programma aan de slag.
Mockup != Photoshop.

[Stukfruit]

Mockup is een proefmodel om een beeld mee te vormen van hoe het er uiteindelijk uit gaat zien met alle details en kan prima in Photoshop. Als je uit de grafische wereld zou komen dan zou je dit moeten weten.

Wat jij bedoelt is een (ruwere) schets. Dat kan idd met het spul van Balsamiq (ik begrijp de verwarring na het zien van die pagina), wat inderdaad stap twee is: het ding op papier zetten

[Stukfruit]

Naar aanleiding van de reacties in het volgende (off)topic:
Anoniem: 296939 in "Post hier je eigen Android App!"

Even vooraf: het gaat hier om iemand met (relatief) weinig gebruikers die snel aan de slag wil voor (waarschijnlijk) weinig kosten. Waar haal je een Duitser vandaan die gratis voor je werkt? (op diensten zoals GetLocalization na).

Speciaal voor alle mensen die nog niet met GT om kunnen gaan:

Handleiding: lokaliseren met Google Translate

Zoals ik al eerder eens schreef moet je leren omgaan met GT. Als je niet de standaard vertalingen pakt, de vertaalopties, vertaalgeheugen en de al bestaande vertalingen van andere mensen gebruikt dan kan je er prima mee uit de voeten. Daarnaast is er nog het allerbelangrijkste: je moet "lokaliseren", niet vertalen!! (vertalen doe je per woord).

En dat laatste begint bij je brontekst.

Het voorbeeld uit het topic van de link hierboven, "rooted Gingerbread phone", gaat altijd problemen geven. Een machinale vertaling weet niet dat Gingerbread een productnaam is. Gelukkig weet je zelf heel goed waar je zelfgeschreven tekst over gaat en is dit een van de punten waarbij je Google Translate moet helpen door zelf het woord terug te plaatsen. In GT kun je dit doen door een woord aan te klikken en de juiste variant te kiezen. In GT Toolkit vul je het gewoon zelf in. Dit soort termen kan je met GT heel simpel terugvinden door de originele variant aan te klikken, waardoor de (tot op dit punt) onbekende en onjuiste vertaling in de andere taal oplicht.

Daarna gaan we door naar "rooted". Dit woord is met deze constructie (als in "rooted phone") en in de beschikbare context alleen mogelijk in de Engelse taal en is een verbastering van "root", wat in dit geval net als Gingerbread niet meer dan een naam is. Een accountnaam op unix-systemen, om precies te zijn, die is ontstaan doordat het weer zo'n typisch Engelse term is (root of all problems, root of this, root of that, etc - oftewel: de basis van iets, het basisaccount van het systeem). Ook hier geldt dat je dit niet *kan* vertalen, want er bestaat helemaal geen andere naam voor. Daarom moet je voor zulke woorden zoeken naar een benadering of omschrijving die zo dicht mogelijk in de buurt komt van de Engelse term.

Uiteindelijk komt het erop neer dat je met iets als "rooted Gingerbread phone" in je brontekst al helemaal fout zat en dus eigenlijk "root account of a Gingerbread phone" of "root account on a Gingerbread phone" had moeten schrijven, terwijl er nog veel meer mogelijkheden zijn wanneer je (in de brontekst, dus de tekst die vertaald moet worden) de context eromheen wijzigt.

Als je bewust je teksten op deze manier schrijft en na de automatische vertaling alle woorden nog even naloopt om te kijken of de constructies redelijk in elkaar lijken te zitten en alle namen en andere bijzondere termen terugplaatst dan is Google Translate (of eigenlijk liever met Google Translate Toolkit, wat handiger is) prima te gebruiken voor de lokalisering van je teksten. Wanneer je je werk goed doet zullen de meeste gebruikers zelfs denken dat je een zgn "native speaker" van de betreffende taal bent...

Mocht je na het lezen van deze reactie nog steeds denken dat Google Translate (Toolkit) niet geschikt is, dan heb je het nog nooit echt geprobeerd en mis je een hoop. Dat is jammer, want als je weet hoe je het moet gebruiken dan is het echt een briljant stuk gereedschap waarmee je op een enkele dag je complete app inclusief omschrijvingen naar een hele berg andere talen kan omzetten zonder dat het je iets kost.

Verder is het trouwens natuurlijk altijd verstandig om er een woordenboek of encyclopedie (voor de speciale termen) voor de betreffende taal bij te houden (je kan beiden op het interwebs vinden) zodat je de betekenis van een woord waarvan je niet helemaal zeker bent op kan zoeken, maar dat doet een professionele vertaler vast ook wel eens. Het punt is in ieder geval dat GT(T) je enorm veel op weg kan helpen naar een erg goede vertaling. Misschien niet perfect, maar zeker wel heel goed leesbaar zonder te vervallen in de zgn "Babelfish'ms".

Dus houd svp op met het gooien van die stereotype situaties, want na het voldoen aan de hierboven genoemde en simpele set met voorwaarden heb je daar geen last van.

Dus.

[Prulleman]

Tuurlijk heb je helemaal gelijk, maar om nou gelijk zo gestressed te doen... Als je de praktijk bekijkt gaat het om hele normale veel voorkomende problemen.


Dus bedankt voor de tip, maar doe de volgende keer niet of iedereen die dit niet weet achterlijk is...

[Stukfruit]

IK DOE NIET GESTRESSED?!
Just kiddin'

[Anoniem: 296939]

Ik ben het daar helaas toch niet mee eens. Ik heb het onlangs nog eens zelf geprobeerd met een email van het Nederlands naar het Engels te vertalen. GT weet bijna elk woord correct te vertalen maar de zinsbouw is gewoon niet goed. Alles komt zo veel te geforceerd over.

Als je je app op een forum tentoonstelt, kan je daar vragen als er mensen zijn die de moeite willen doen om hem te vertalen. Ik heb dit ooit eens gedaan met een app die op XDA stond.

Google Translate kan dus wel een goede hulp zijn maar ik zou je vertalingen toch nog eens laten nalezen door een Duitstalige...

[Stukfruit]

"een email"? Met inhoud die je zelf hebt geschreven? Want anders heb je mijn punt een beetje gemist

Verder: probeer het eens met Engels als brontaal ipv Nederlands.

[Anoniem: 296939]

Ja, of het nu een email is of een beschrijving van je app, veel maakt het niet uit he ...
Engels als brontaal instellen heeft inderdaad impact op de performance

[JustAnotherDev]

Blijkbaar heeft Intel een nieuwe x86 image uitgebracht, Android 4.0.3 API15. Jammer dat de Maps api er standaard niet inzit .

[Stukfruit]

Ook jammer dat met de nieuwste release (v16, Jellybean) er ook niet meteen een Intel image bij is gestopt.

---

Daarnet nam ik trouwens even een kijkje in de Developer Console, maar dit deed ik per ongeluk in de incognito-mode van Chrome. Nadat ik dit deed viel het me op dat er opeens een oranje labeltje rechts bovenaan in de hoek stond, met daarin iets over of ik mezelf wilde aanmelden voor een preview.

"Preview?" Nieuwsgierig als ik ben klikte ik dus door... en kreeg het volgende te zien:



Geen idee of ik dit per ongeluk te zien kreeg (zonder incognito mode zie ik het labeltje niet), maar het klinkt interessant:

"It features a new look and feel, improved publishing experience, and auto-translations. You'll need to be already registered as a Google Play developer to sign up."

Aan de intropagina te zien lijkt het meer Jellybean-erig te worden.

* Stukfruit is volgens Google nu "among the next to try the new Google Play Developer Console" en zou binnenkort een nieuwe link moeten zien verschijnen

---

Edit: ah kijk, er zijn ook al screenshots van te vinden:


Bron: http://www.androidpolice....console-beta-coming-soon/

[ Voor 11% gewijzigd door Stukfruit op 01-07-2012 18:17 ]

[Jegorex]

Ik heb naast de sign out link een oranje knop genaamd "Sign-up for preview".
Misschien toch maar eens uitproberen

[Stukfruit]

Dat is idd de knop waar ik het over had

[Chip.]

Vraagje zijn er wat meer tutorials van google zoals http://developer.android..../notepad/notepad-ex1.html en daarnaast dus de helloworld?

[Jegorex]

Stukfruit schreef op zondag 01 juli 2012 @ 23:07:
Dat is idd de knop waar ik het over had

Ik kreeg de pagina in jouw eerste screenshot te zien en vervolgens moet je je developer email adres invullen om kans te maken binnenkort een uitnodiging te krijgen.
Nu is het afwachten.

[Sh4wn]

Op de Google I/O Conferentie is inderdaad de nieuwe developer console al aangekodingd, en daar werd ook getoond hoe je in de nieuwe versie een app publiceert in de play store. Zag er erg gelikt uit.

[Anoniem: 296939]

[Stukfruit]

Het is werkelijk prachtig dat je nu automatisch manifests kan laten mergen door manifestmerger.enabled=true in je project.properties te zetten, maar ze zijn vergeten om er een hele grote bug uit te halen waardoor de feature compleet nutteloos is

Je kan nl niet je project exporteren met de merger aan

Volgens de auteur (ben de link even kwijt) is het 12 juli opgelost en zou het binnenkort ergens in een tussentijdse update voor ADT moeten worden doorgevoerd, maar goed.. "zou", "als", daar heb je als serieuze ontwikkelaar natuurlijk weinig aan.

Maar goed. Toch fijn dat het er eindelijk aan zit te komen. Met libraries die op libraries steunen begon het toch behoorlijk complex te worden om zelf al die activity's en permissies toe te voegen in het hoofdproject

[Arie-]

Tijdens mijn opleiding heb ik slechts enkele programmeer vakken gehad (opleiding is BIT aan utwente), om een en ander op te halen ben ik begonnen met het schrijven van een eigen programma voor mijn Android telefoon. Het wordt een programma met een verzameling van een aantal verschillende simpele kleine spelletjes, denk hierbij aan Boter Kaas en Eieren. Een en ander wil me redelijk lukken en de eerste spelletjes werken (tot op zekere hoogte;)). Toch zit ik met een paar vragen waarbij ik wil weten of ik dit 'goed' heb aangepakt.
De eerste vraag gaat over reflectie, dit pattern heb ik of niet onthouden of nooit gebruikt, maar het is me gelukt om een wrapper class te maken voor NumberPicker welke bestaat vanaf Android 3.0, een alternatieve library wordt geladen als de versie lager is dan 3.0. Ik zit nu met een vraag over deze wrapper class, op het moment heb ik enkel de methoden die ik zelf aanroep voorzien van een wrapper methode, is dit good practice of is het "de regel" om voor alle methoden een wrapper alternatief te schrijven.

ps. Meerdere vragen kunnen volgen.

[EddoH]

Waarom extend je de class niet en override je de methods waar je de behavior van wil veranderen?

[Arie-]

Hmm snap ik het reflectie pattern dan verkeerd? Ik gebruik het als volgt. In het object waar met de library wordt gewerkt die niet in alle API levels bestaat kan ik niet naar deze library verwijzen, want op het moment dat dat object gecreerd wordt, wordt er ook gekeken naar alle mogelijke referenties in dat object. In plaats van het laden van de daadwerkelijke library heb ik een wrapper class gemaakt die enkel methode aanroepen forward.
Waarom deze wrapper dan die library niet extend: op het moment dat doe, is de verwijzing naar de wrapper indirect ook een verwijzing naar de library die niet bestaat. Nu bestaat de verwijzing pas op het moment dat de wrapper wordt gecreerd, dit is na de API level check.
Overigens heb ik deze handleiding als voorbeeld gebruikt.

[alex3305]

Ik ben inmiddels weereens begonnen met Android development. Een tijdje afwezig gewest, en dus een beetje roestig. Maar anyway, nu weer aan het stoeien met de heerlijke *kuch* Bitmap's op Android. Nu wil ik eigenlijk de Bitmap's serialiseren en daarna op een computer weer inlezen. Heeft iemand toevallig ervaring hiermee en concreter een manier om het te doen? Ik krijg het namelijk niet voor elkaar .

[Stukfruit]

Het is mij eigenlijk compleet onduidelijk wat je wil. Misschien lukt het als je eerst even voor jezelf bedenkt wat het is.

Mocht je vanuit een app bitmaps willen doorsturen naar een pc dan doe je dat natuurlijk via een netwerkverbinding. Of nog makkelijker: zet ze ergens op internet en maak gebruik van standaard API's om ze op de pc weer in te lezen. Waarom zou je het wiel opnieuw uitvinden als je toch al gebruik moet maken van een netwerkverbinding...

En als je het echt perse moeilijk en direct wil doen dan kan je gewoon de rauwe data uit de bitmap halen en de rest is standaard werk met (bluetooth?) sockets ed.

[Stukfruit]

Hebben anderen hier inmiddels ook toegang gekregen tot de nieuwe Developer Console?

Het viel mij daarnet opeens op dat het oranje knopje bovenaan de pagina een andere tekst had, dus ik klikte er snel op. En wauw... dat is echt een enorme verbetering!

Nog niet alles is klaar, zo ontbreekt bv. de profielpagina en wat andere dingen, maar wat er is is erg goed. Echt een stuk overzichtelijker. En het dansende robotje bij het laden bovenaan de pagina is

[jacobras]

Ik heb al een tijdje het oranje knopje met de tekst "sign-up for preview", maar nog geen toegang helaas. Beste toevoeging lijkt me het kunnen reageren op reacties in Play!

[Stukfruit]

Dat is voorlopig helaas nog voorbehouden aan "top" developers

Hij springt bij een volgend bezoek trouwens ook steeds weer terug op de normale variant, dus het is echt letterlijk een preview...

[Anoniem: 296939]

De nieuwe Play Console is hier!

[ Voor 30% gewijzigd door Anoniem: 296939 op 17-10-2012 09:19 ]

[Stukfruit]

Ik zag laatst ergens dat een niet-"top" developer kon reageren op commentaar van gebruikers.. wtf?

[jacobras]

Stukfruit schreef op woensdag 17 oktober 2012 @ 09:29:
Ik zag laatst ergens dat een niet-"top" developer kon reageren op commentaar van gebruikers.. wtf?

Hm? Voor zover ik weet kunnen voorlopig helaas alleen top developers reageren op reacties. Jammer, want dat is eigenlijk de enige vernieuwing in de developer console waar ik op zit te wachten.

[Stukfruit]

Daarnet zag ik opeens weer een voorbeeld van een developer die kon reageren zonder top developer-badge:
Google Play: Triple Town (eerst even doorklikken naar reviewpagina).

Is in dit geval wel een Editors' Choice, maar de vorige waarbij ik dit zag was het afaik niet.

[Stukfruit]

Nou, ik moet zeggen dat ik toch wat minder positief begin te worden over die integratie van Google+ met de Play Store.

Het heeft mij maar liefst een hele keer geholpen om contact op te nemen met een gebruiker die klachten had. Maar deze persoon probeerde me ook op andere manieren te bereiken, dus G+ hielp daardoor eigenlijk weinig.

De rest van de reviews bestaat uit mensen die zo goed als allemaal de mogelijkheid om te reageren via hun G+-profiel uitgeschakeld hebben staan, dus het grote wachten is helaas nog steeds op de optie om direct via de Play Store te reageren.

[echthard]

Kan iemand mij helpen met de architectuur? Ik heb een menudrawer, minstens 1 activity, enkele fragments en enkele viewpagers (dit kan volgens mij daadwerkelijk 1 viewpager zijn).

Wanneer er op een navigatie link uit de menudrawer geklikt wordt, dan moet het content_frame gedeelte waarin al een fragment of viewpager zat vervangen worden door een ander fragment of viewpager. Of zie ik dit verkeerd?

[Stukfruit]

Ik denk dat je dat goed ziet Maar meerdere viewpagers zou ik dan weer niet voor kiezen.

[Py.]

Ik begrijp je verhaal niet helemaal dhhdante, viewpagers zijn UI compontenten die je in een layout plaatst (1 voor een activity, 1..n voor fragments in activities) net als een listview. Viewpagers kun je in een fragment plaatsen en zo hergebruiken, zolang er maar geen fragment in de view van je viewpager zit (fragment in fragment mag pas vanaf android 4.2 zo uit mijn hoofd...)

Indien je je afvraagt wat een best practice is ('moet' klinkt weer zo overdreven verplicht, doe wat handig/praktisch is voor jezelf!): ik geef zelf de voorkeur aan het scheiden van schermen op basis van activity met daarin 1..n fragments of 1 layout indien die op elk formaat device hetzelfde is. Voor elke herbruikbare interactieve layout gebruik ik fragments die weer gekoppeld zijn aan de bijbehorende activity. Het liefst koppel je zo min mogelijk ivm. onderhoudbaarheid van je code, dus liever 3-4 activities voor je views dan alles samengeklonterd in 1. Je Drawermenu code kun je als het goed is hergebruiken in al je activities.

Als voorbeeld van fragments hergebruiken: je zou voor een tablet layout je lijst weer kunnen geven in het linker blok en deze via een viewpager swipe-baar maken rechts. Voor je telefoon layout gebruik je dan alleen de viewpager ivm. het ruimtegebrek.

Zoiets dus (let niet op de vormgeving, deze app krijgt binnenkort een layout/holo makeover ), door te swipen scroll je ook door de lijst.


en telefoon layout:


Ik meende dat er een google I/O presentatie op youtube stond hoe Google dit toepastte in de destijds nieuwe market/Play app waarbij een scherm uit meerdere fragments bestond, ook in telefoon-layout, maar die kan ik zo snel niet meer vinden.

[ Voor 3% gewijzigd door Py. op 26-02-2013 20:07 ]

[echthard]

Sorry heren, ik had jullie reacties niet gezien (vakantietje in NYC )

Maar dank voor de respons, ik kan idd ook voor elke menu knop vanuit de drawer een activity maken, alleen vraag ik me af of dat wel zo fijn werkt. Je klikt dan nl op een menudrawer item en dan wordt die overlapt door een nieuwe activity met weer exact dezelfde menudrawer code. Schuift de drawer dan wel eerst dicht en opent de nieuwe activity dan wel netjes. Ik betwijfel het. Ik denk ook dat het per library verschillend zal werken, ik gebruik momenteel die van simonvt (menudrawer) ipv die van jfeinstein (slidingmenu).

Maar gelukkig heb ik mn baas zo ver gekregen dat ik samen met hem de mockups mocht herontwerpen, waardoor er nu geen drawer meer is, we gebruiken nu een uitgebreidere spinner. Nu wordt het leven een stuk eenvoudiger, maar ik ben nog steeds geinteresseerd in oplossingen met die drawer. De library examples laten mi net even te weinig zien.

[Py.]

De updates voor o.a. R22 van de SDK, Google Play services en de support library zijn nu beschikbaar als update in de Android SDK manager.

[Anoniem: 84021]

Ik heb een beetje het idee dat de Android SDK nog niet helemaal rijp is. Maar ik vraag me af, ligt dat nu aan mij? Of is dat ook een beetje zo?

Zo was ik eerst bijvoorbeeld verbaasd dat ik bij Android ZELF de onclick actie moest schrijven. Zo'n listener maken en knopjes declareren...
Het was even uitzoeken en is nu nog maar een kwestie van een paar regeltjes toevoegen en het knopje werkt.

Maar nu wilde ik bijvoorbeeld vanuit mijn main activity in een nieuwe activity voor instellingen (gewoon een nieuw scherm/form of hoe je het wilt noemen) bepaalde checkbox waarden uitlezen, maar ook hiervoor moet je eerst hele dingen programmeren voordat het werkt, anders crasht het gewoon.
Hier ben ik nu mee bezig.

Maar klopt het dat dit gewoon nog best omslachtig is? Of ligt het gewoon aan mij? Ik heb wel alles zelf uit interesse geleerd, en ben heel nieuw op het gebied van Android. Ik heb geen opleiding of zo op het gebied van programmeren.
Ik ben gewoon benieuwd, anders moet ik zelf gewoon nog meer leren.

[Daos]

Vanuit mijn SettingsActivity schrijf ik naar de SharedPreferences van de MainActivity. De MainActivity leest deze SharedPreferences in de onCreate en de onRestart. Het lezen/schrijven van/naar de SharedPreferences zit in een aparte klasse met de naam Settings. In de onCreate van mijn MainActivity moet ik wel eerst Settings.init(this); aanroepen.

Stukje uit mijn Settings-klasse:

Java:

private static SharedPreferences sp;

public static void init(Activity c) {
    sp = c.getPreferences(Context.MODE_PRIVATE);
}

public static String getString(String key) {
    return sp.getString(key, "");
}

public static void putString(String key, String value) {
    SharedPreferences.Editor edit = sp.edit();
    edit.putString(key, value);
    edit.commit();
}

[ Voor 1% gewijzigd door Daos op 16-05-2013 17:49 . Reden: onRestart vergeten ]

[Anoniem: 84021]

Daos schreef op donderdag 16 mei 2013 @ 17:39:
Vanuit mijn SettingsActivity schrijf ik naar de SharedPreferences van de MainActivity. De MainActivity leest deze SharedPreferences in de onCreate. Het lezen/schrijven van/naar de SharedPreferences zit in een aparte klasse met de naam Settings. In de onCreate van mijn MainActivity moet ik wel eerst Settings.init(this); aanroepen.

Stukje uit mijn Settings-klasse:

Java:

private static SharedPreferences sp;

public static void init(Activity c) {
    sp = c.getPreferences(Context.MODE_PRIVATE);
}

public static String getString(String key) {
    return sp.getString(key, "");
}

public static void putString(String key, String value) {
    SharedPreferences.Editor edit = sp.edit();
    edit.putString(key, value);
    edit.commit();
}

Bedankt! Was al bezig met de SharedPreferences manier, dus dit stukje code kan ik goed gebruiken!

[Py.]

Voor de mensen die tegen NoClassDefFound errors aanlopen na het compilen met de nieuwe SDK (versie 22) icm. library jars zoals Acra:

* In project properties (bij het project) -> java build path -> order and export -> selecteer Android private libraries.
* Vervolgens "Android Tools -> Fix Project Properties" en "Project -> Clean"

[codex]

jacobras schreef op woensdag 17 oktober 2012 @ 15:35:
[...]

Hm? Voor zover ik weet kunnen voorlopig helaas alleen top developers reageren op reacties. Jammer, want dat is eigenlijk de enige vernieuwing in de developer console waar ik op zit te wachten.

Ik kan al een tijdje reageren op gebruikers. En ik ben geen topontwikkelaar Wat wel jammer is aan de nieuwe console is dat ik als tip krijg om mijn strings.xml te vertalen naar Russisch en ik in de presentatie de mogelijkheid zag dit direct door te zetten naar een vertaalbureau. Die optie lijkt alleen niet beschikbaar. Dat vond ik wel een handige feature.

[jacobras]

reemprive schreef op vrijdag 24 mei 2013 @ 07:23:
[...]

Ik kan al een tijdje reageren op gebruikers. En ik ben geen topontwikkelaar

Ja, ik kan er inmiddels ook al een tijdje gebruik van maken, was een post van vorig jaar hé ;-)

reemprive schreef op vrijdag 24 mei 2013 @ 07:23:
Wat wel jammer is aan de nieuwe console is dat ik als tip krijg om mijn strings.xml te vertalen naar Russisch en ik in de presentatie de mogelijkheid zag dit direct door te zetten naar een vertaalbureau. Die optie lijkt alleen niet beschikbaar. Dat vond ik wel een handige feature.

Die optie moet je aanvragen. Heb ik meteen na het zien van de presentatie gedaan, kan niet wachten tot ik toegang heb! Aanvragen kan via formulier, link staat in je developer dashboard onder Services en API's, onderaan de pagina.

[dik_voormekaar]

Android SDK 18 is uit