De Devschuur Coffee Corner - Iteratie 5

[Kobus Post]

Avalaxy schreef op vrijdag 07 maart 2014 @ 19:16:
[...]


Yup. Maarja, Windows Phone bewijst keer op keer dat er gewoon geen geld mee valt te verdienen. Ik stop maar gewoon het te proberen.

Als je voor het geld gaat, dan moet je voor iOS gaan. http://appleinsider.com/a...per-download-than-android

[Caelorum]

EddoH schreef op vrijdag 07 maart 2014 @ 19:13:
[...]
Pff, je bent verwend! Ik moet het soms doen met een enkele MB

Maar ik doe even de veilige aanname dat jij niet twee afbeeldingen (samen scherm resolutie) scherp op een full hd scherm moet tonen en die 16MB moet delen met whatever android ook maar wil inladen als je een activity opstart. Ohja... en het zijn meerdere afbeeldingen die afhankelijk van de gebruiker kort achter elkaar kunnen worden getoond. Disposen, disposed ze niet meteen, een garbage collect call ook niet altijd, zelfs niet als alle referenties er niet zijn.
16MB is ruim zat als je het geheugengebruik compleet in eigen beheer hebt, maar anders echt een enorm artificiële beperking. Al helemaal als je je bedenkt dat dit apparaat 512MB ram heeft, maar ik er maar 16MB mag aanspreken (soms wel tot een whopping 32MB, maar is niet gegarandeerd). Echt WTF? Vooral omdat dat ding de rest niet eens gebruikt
Het is zo erg dat dit project momenteel echt een hell is (maar daar hebben we het al eens over gehad hier)..

Om even aan te geven:
Bij android krijg je afhankelijk van wat de fabrikant heeft ingesteld ergens tussen de 16 en 64 MB RAM. In WP8 is dat 150 tot 570MB afhankelijk van hoeveel geheugen er in zo'n apparaat zit.

[ Voor 14% gewijzigd door Caelorum op 07-03-2014 19:44 ]

[Avalaxy]

Kobus Post schreef op vrijdag 07 maart 2014 @ 19:19:
[...]

Als je voor het geld gaat, dan moet je voor iOS gaan. http://appleinsider.com/a...per-download-than-android

No thanks.

[PrisonerOfPain]

Caelorum schreef op vrijdag 07 maart 2014 @ 19:23:
[...]

Maar ik doe even de veilige aanname dat jij niet twee afbeeldingen (samen scherm resolutie) scherp op een full hd scherm moet tonen en die 16MB moet delen met whatever android ook maar wil inladen als je een activity opstart.

Om even aan te geven:
Bij android krijg je afhankelijk van wat de fabrikant heeft ingesteld ergens tussen de 16 en 64 MB RAM. In WP8 is dat 150 tot 570MB

Zijn dat twee afbeelsingen van 8mb per stuk of zijn ze 8mb in totaal?

[ Voor 22% gewijzigd door PrisonerOfPain op 07-03-2014 19:37 ]

[EddoH]

Caelorum schreef op vrijdag 07 maart 2014 @ 19:23:
[...]

Maar ik doe even de veilige aanname dat jij niet twee afbeeldingen (samen scherm resolutie) scherp op een full hd scherm moet tonen en die 16MB moet delen met whatever android ook maar wil inladen als je een activity opstart. Ohja... en het zijn meerdere afbeeldingen die afhankelijk van de gebruiker kort achter elkaar kunnen worden getoond. Disposen, disposed ze niet meteen, een garbage collect call ook niet altijd, zelfs niet als alle referenties er niet zijn.
16MB is ruim zat als je het geheugengebruik compleet in eigen beheer hebt, maar anders echt een enorm artificiële beperking. Al helemaal als je je bedenkt dat dit apparaat 512MB ram heeft, maar ik er maar 16MB mag aanspreken (soms wel tot een whopping 32MB, maar is niet gegarandeerd). Echt WTF? Vooral omdat dat ding de rest niet eens gebruikt
Het is zo erg dat dit project momenteel echt een hell is (maar daar hebben we het al eens over gehad hier)..

Om even aan te geven:
Bij android krijg je afhankelijk van wat de fabrikant heeft ingesteld ergens tussen de 16 en 64 MB RAM. In WP8 is dat 150 tot 570MB

Klopt. Java is in dit geval niet ideaal als je je memory strict moet managen. En Android is wat dat betreft niet heel goed meegegaan met de schermresolutie qua geheugenlimieten.

Heel simpel gedacht hoor maar kun niet dezelfde buffers/stores whatever hergebruiken bij wisselen van afbeeldingen? Vooraf allocaten en steeds vullen lijkt me. Cpu power genoeg op die dingen.

[PrisonerOfPain]

Verder, kun je de afbeeldingen DXT/ PVRTC compressen? Zul je wel met OpenGL aan de slag moeten maar dan heb je iig 1/4 van de ruimte nodig of minder.

[Caelorum]

PrisonerOfPain schreef op vrijdag 07 maart 2014 @ 19:30:
[...] Zijn dat twee afbeelsingen van 8mb per stuk of zijn ze 8mb in totaal?

De library die ik gebruik verwacht een ARGB_8888 bitmap. Dat is dus 4 bytes per pixel = 5MB per bitmap. Dan wordt het geheel als opengl texture weggezet en gereleased. Wat het geheugen compleet vrijgeeft. Maar soms worden er 4 van die dingen kort achter elkaar geladen. Ik heb ze dan ook allemaal nodig en dan zit je al redelijk aan het max. Zelfs als Android zo lief is alles echt vrij te geven zit je op sommige momenten met 20MB aan bitmap data. Dat gaat nu wel goed, maar eigenlijk zou het ook op 16MB devices moeten werken. Ik kan er alleen nu niets meer aan doen tenzij ik alles compleet ga herschrijven als NDK app.
Ik moet nu ook al als ik deze activity open vanuit de vorige alle views compleet weggooien en garbage collector draaien anders is het instant crash. Dat zorgt voor een lelijke delay van ~2s en is alles behalve een fijne UX. En dat allemaal omdat iemand ooit heeft bedacht dat het handig was max 16-24MB RAM te geven voor apps.
Devices met 16MB RAM krijgen nu ook een grote waarschuwing te zien als ze de app opstarten.

Ohja, en die library moet ik wel gebruiken want ik heb de kennis, de wil en de tijd niet om zo'n ding te schrijven / herschrijven.

[ Voor 41% gewijzigd door Caelorum op 07-03-2014 19:46 ]

[F.West98]

Caelorum schreef op vrijdag 07 maart 2014 @ 19:09:
[...]

Duidelijk dus dat je hier niet genoeg mee leest Aantal pagina's terug kwamen de verschillende frameworks inclusief prijzen terug. Die prijs valt ook zeker mee, enige jammere is dat het per platform is. Persoonlijk had ik liever iets gezien als 99$ voor alle platformen met een limiet aan omzet voor app of zoiets.

Wut. Wat heb ik gemist. Ik lees altijd alles. ALLES.
Behalve als ik één week op vakantie ben geweest. Maar dat was een week geleden.

[Caelorum]

F.West98 schreef op vrijdag 07 maart 2014 @ 19:45:
[...]
Wut. Wat heb ik gemist. Ik lees altijd alles. ALLES.
Behalve als ik één week op vakantie ben geweest. Maar dat was een week geleden.

Zie daar je probleem ^^

[F.West98]

Ik ga het NU fixen.
Maar hoe. AJAX POST is altijd UTF8 en Tweakers niet.

[EddoH]

Caelorum schreef op vrijdag 07 maart 2014 @ 19:40:
[...]

dat gaat nu wel goed, maar eigenlijk zou het ook op 16MB devices moeten werken. Ik kan er alleen nu niets meer aan doen tenzij ik alles compleet ga herschrijven als NDK app.

Memory management / lladen van afbeeldingen in C met de NDK doen en met JNI in je Java app gebruiken? Dat hoeft niet veel tijd te kosten om te implementeren en hoef je niet alles te herschrijven.

[PrisonerOfPain]

720p is 3,5mb (1280x720x4) 1080 is 7,9mb (1920x1080x4). Welke resolutie gebruik jij?

[Caelorum]

EddoH schreef op vrijdag 07 maart 2014 @ 19:49:
[...]
Memory management / lladen van afbeeldingen in C met de NDK doen en met JNI in je Java app gebruiken? Dat hoeft niet veel tijd te kosten om te implementeren en hoef je niet alles te herschrijven.

Zit niet veel anders op, maar loop al 3 maanden uit en ben er nu eigenlijk wel een beetje klaar mee. Zit constant dit soort issues op te lossen terwijl het helemaal niet nodig is. Enorm frustrerend dat. Had ik dit aan het begin van het traject geweten had ik alles wel in de NDK gedaan. Echt belachelijk dat je min of meer daartoe wordt gedwongen en dat Google vervolgens overal loopt te schreeuwen dat je de NDK nergens voor nodig hebt en je het echt niet moet gebruiken. Fuck dat.

PrisonerOfPain schreef op vrijdag 07 maart 2014 @ 19:51:
720p is 3,5mb (1280x720x4) 1080 is 7,9mb (1920x1080x4). Welke resolutie gebruik jij?

Ik rekende voor het gemak even met 1280x1024, maar je ziet in ieder geval het probleem wel met 4x zo'n bitmap tegelijkertijd in het geheugen? Geheugenlimieten zijn overigens over het algemeen afhankelijk van de resolutie van het scherm, aangezien Google zegt dat het minimaal zo groot moet zijn om de screenbuffer in het geheugen te krijgen, waardoor het probleem op lagere resoluties net zo goed aanwezig is.

*edit*
Ohja en een wrapper zal niet veel helpen aangezien de bitmaps alleen maar zolang in geheugen blijven als dat ik ze van 'renderen' naar de control kan krijgen die het in gfx geheugen stouwt. Ik zal dan dus het pad van 'renderer' naar control compleet moeten herschrijven naar C. Wat zoveel zooi raakt dat ik uiteindelijk eigenlijk de hele activity in de NDK moet gaat zien te krijgen. Geen idee hoeveel werk dat precies is, maar makkelijk en snel zal het niet zijn denk ik.

Eén ding heb ik in ieder geval geleerd. Zodra je met grote bitmaps moet gaan werken ben je beter af als die data nooit de java code haalt. Zodra je ook maar iets in java wilt gaan doen op android met relatief grote bitmaps ben je de lul.

[ Voor 20% gewijzigd door Caelorum op 07-03-2014 20:06 ]

[Firesphere]

Goed. Dat was het dan.
Ik heb 1x. Echt waar. Vriendelijk en serieus gereageerd op een recruiter.

Resultaat?
NUL!

Sterf toch lekker met je even linken.

[F.West98]

Die van een paar dagen geleden?

[OnTracK]

F.West98 schreef op vrijdag 07 maart 2014 @ 19:47:
Ik ga het NU fixen.
Maar hoe. AJAX POST is altijd UTF8 en Tweakers niet.

De enige concrete oplossing is in javascript een mapping bouwen van utf-8 naar cp1252+htmlentities. En dan handmatig bytes aan elkaar plakken. En dan submit je in feite een illegale utf-8 sequence.

[Firesphere]

F.West98 schreef op vrijdag 07 maart 2014 @ 20:03:


Die van een paar dagen geleden?

Nee, een echt serieuze recruiter, met goede reputatie, geen buckshot figuur (en al helemaal geen "mooi koppie" )

[F.West98]

Firesphere schreef op vrijdag 07 maart 2014 @ 20:06:
[...]

Nee, een echt serieuze recruiter, met goede reputatie, geen buckshot figuur (en al helemaal geen "mooi koppie" )

Had je die niet gepost
Testtest éééé - damned

[Firesphere]

Nee, die post ging over een buckshot recruiter die recruiter is om haar mooie koppie. (dat laatste is een gok)

[azerty]

Het werkt niet FWest...

[F.West98]

wsitedesign schreef op vrijdag 07 maart 2014 @ 20:12:
Het werkt niet FWest...

Nee? ^nee

[ Voor 9% gewijzigd door F.West98 op 07-03-2014 20:13 ]

[Caelorum]

Dank je in ieder geval voor het vermaak! ^^

[F.West98]

Caelorum schreef op vrijdag 07 maart 2014 @ 20:14:
Dank je in ieder geval voor het vermaak! ^^

Grom
Ja ik neem elke gelegenheid aan om te testen

[Firesphere]

Ik moet nu wel heel erg de neiging onderdrukken om m'n toetsenbord in Russisch te zetten

[EddoH]

Caelorum schreef op vrijdag 07 maart 2014 @ 19:56:
.

*edit*
Ohja en een wrapper zal niet veel helpen aangezien de bitmaps alleen maar zolang in geheugen blijven als dat ik ze van 'renderen' naar de control kan krijgen die het in gfx geheugen stouwt. Ik zal dan dus het pad van 'renderer' naar control compleet moeten herschrijven naar C. Wat zoveel zooi raakt dat ik uiteindelijk eigenlijk de hele activity in de NDK moet gaat zien te krijgen. Geen idee hoeveel werk dat precies is, maar makkelijk en snel zal het niet zijn denk ik.

Eén ding heb ik in ieder geval geleerd. Zodra je met grote bitmaps moet gaan werken ben je beter af als die data nooit de java code haalt. Zodra je ook maar iets in java wilt gaan doen op android met relatief grote bitmaps ben je de lul.

Tja ik weet natuurlijk niet echt hoe je code eruitziet, maar je kan in Java met JNI prima een buffer gebruiken die in C gealloceerd is. Daarna is het een kwestie van een reference doorgeven lijkt me. Maargoed, zoals gezegd, ik weet niet hoe je code eruitziet en welke componenten gebruikt, maar misschien helpt het je op weg.

[F.West98]

Firesphere schreef op vrijdag 07 maart 2014 @ 20:24:
Ik moet nu wel heel erg de neiging onderdrukken om m'n toetsenbord in Russisch te zetten

Dan heb ik daar toch geen problemen mee? Het weergeven werkt. Posten niet.
Nu is er wéér iets anders. Nu geeft hij het al fout door

[ Voor 12% gewijzigd door F.West98 op 07-03-2014 20:29 ]

[Caelorum]

EddoH schreef op vrijdag 07 maart 2014 @ 20:25:
[...]
Tja ik weet natuurlijk niet echt hoe je code eruitziet, maar je kan in Java met JNI prima een buffer gebruiken die in C gealloceerd is. Daarna is het een kwestie van een reference doorgeven lijkt me. Maargoed, zoals gezegd, ik weet niet hoe je code eruitziet en welke componenten gebruikt, maar misschien helpt het je op weg.

Mocht ik ooit nog eens iets met androids en bitmaps doen zal ik zeker naar kijken. Ik ben nu gewaarschuwd. Vooralsnog heb ik gewoon miminum requirements ingesteld en vind ik het wel goed.

[OnTracK]

F.West98 schreef op vrijdag 07 maart 2014 @ 20:27:
[...]

Dan heb ik daar toch geen problemen mee? Het weergeven werkt. Posten niet.
Nu is er wéér iets anders. Nu geeft hij het al fout door

Even een snel testje in elkaar gedraait, volgens mij zou dit ongeveer moeten werken.
http://jsfiddle.net/k4Vwu/

[MrAmos]

Android development.. *wil terugkrabbelen maar schoolopdracht enzo

[Firesphere]

johannessmit schreef op vrijdag 07 maart 2014 @ 20:41:
Android development.. *wil terugkrabbelen maar schoolopdracht enzo

Hey, lief zijn voor Java.

Voor Android daarentegen, mag je je gal spuwen wat je maar wilt

[MrAmos]

Firesphere schreef op vrijdag 07 maart 2014 @ 20:43:
[...]

Hey, lief zijn voor Java.

Voor Android daarentegen, mag je je gal spuwen wat je maar wilt

Laat het probleem nou precies java zijn.. raar taaltje

[Firesphere]

johannessmit schreef op vrijdag 07 maart 2014 @ 20:44:
[...]


Laat het probleem nou precies java zijn.. raar taaltje

U heeft nog nooit met PHP gewerkt?

[F.West98]

OnTracK schreef op vrijdag 07 maart 2014 @ 20:38:
[...]
Even een snel testje in elkaar gedraait, volgens mij zou dit ongeveer moeten werken.
http://jsfiddle.net/k4Vwu/

Heel erg bedankt, maar ik krijg in mijn lokale testje dit terug:
tr› als ik tré stuur

[Caelorum]

Heb met java niet zoveel problemen, maar Android..

[ Voor 3% gewijzigd door Caelorum op 07-03-2014 20:47 ]

[azerty]

F.West98 schreef op vrijdag 07 maart 2014 @ 20:47:
[...]

Heel erg bedankt, maar ik krijg in mijn lokale testje dit terug:
tr› als ik tré stuur

Dan is het toch duidelijk dat het probleem aan JOUW pc ligt?

[OnTracK]

F.West98 schreef op vrijdag 07 maart 2014 @ 20:47:
[...]

Heel erg bedankt, maar ik krijg in mijn lokale testje dit terug:
tr› als ik tré stuur

En wat krijg je terug als je tré zonder mijn code stuurt?

[ Voor 82% gewijzigd door OnTracK op 07-03-2014 20:54 ]

[Megamind]

Misschien ligt het aan de browser? Ik krijg namelijk dit terug in Firefox

code:

hoi ›•Ÿ£¨ ʥʦʧʨ

[F.West98]

%5Bquote%5D%5Bb%5D%5Bmessage%3D41897924%2Cnoline%5DOnTracK%20schreef%20op%20vrijdag%2007%20maart%202014%20%40%2020%3A49%5B%2Fmessage%5D%3A%5B%2Fb%5D%0A%5B...%5D%0A%0AEn%20wat%20krijg%20je%20terug%20als%20je%20tr%C3%83%C2%A9%20zonder%20mijn%20code%20stuurt%3F%0A%5B%2Fquote%5D%0AAls%20ik%20in%20jouw%20test%20het%20laat%20encoden%20gaat%20het%20goed%2C%20alleen%20PHP%20zet%20het%20dan%20niet%20goed%20om.%0AWat%20ik%20dus%20doe%3A%0A%5Bcode%3Djs%5D%0Avar%20text%20%3D%20%2F*%20inputcontent%20*%2F%0A%24.ajax(%7B%0A%20%20%20%20data%3A%20%7B%20string%3A%20text%20%7D%2C%0A%20%20%20%20success%3A%20function(j)%20%7B%0A%20%20%20%20%20%20%20%20log(j)%3B%0A%20%20%20%20%7D%0A%7D)%3B%0A%5B%2Fcode%5D%0AAls%20ik%20text%20door%20jouw%20functie%20haal%20krijg%20ik%20dus%20terug%20wat%20ik%20net%20deed.%20Als%20ik%20dat%20niet%20doe%3A%20tr%C3%A9%0AInfo%3A%20Server%20geeft%20HTML%20META%20attr%20met%20iso%2C%20ik%20stuur%20UTF8%20naar%20de%20server

LOL
WTF is er gebeurd met mijn script

dit moet het zijn:

OnTracK schreef op vrijdag 07 maart 2014 @ 20:49:
[...]

En wat krijg je terug als je tré zonder mijn code stuurt?

Als ik in jouw test het laat encoden gaat het goed, alleen PHP zet het dan niet goed om.
Wat ik dus doe:

JavaScript:

var text = /* inputcontent */
$.ajax({
    data: { string: text },
    success: function(j) {
        log(j);
    }
});

Als ik text door jouw functie haal krijg ik dus terug wat ik net deed. Als ik dat niet doe: tré
Info: Server geeft HTML META attr met iso, ik stuur UTF8 naar de server

[ Voor 26% gewijzigd door F.West98 op 07-03-2014 20:55 ]

[OnTracK]

ik vermoed dat je mijn code nog moet combineren met http://stackoverflow.com/...ript-string-to-iso-8859-1

The problem actually lied in how jQuery was urlencoding the message (or something along the way), I fixed this by telling jQuery not to process the data and doing it myself as is shown in the following snippet:

Na mijn code is de string namelijk een iso-8859-1 string, maar jquery denkt nog steeds dat het een utf-8 string is, dus probeert dat te escapen om het veilig over de lijn te krijgen. Dus moet je handmatig escapen, en jquery niks laten doen.

[ Voor 24% gewijzigd door OnTracK op 07-03-2014 21:01 ]

[MrAmos]

Firesphere schreef op vrijdag 07 maart 2014 @ 20:46:
[...]

U heeft nog nooit met PHP gewerkt?

Zeker wel, heb het meeste ervaring in deze taal, wil nu wat meer met talen als java en c++ aan de slag(en voor webdevelopment overweeg ik de overstap naar django)

[PrisonerOfPain]

Caelorum schreef op vrijdag 07 maart 2014 @ 19:56:
[...]
Ik rekende voor het gemak even met 1280x1024, maar je ziet in ieder geval het probleem wel met 4x zo'n bitmap tegelijkertijd in het geheugen? Geheugenlimieten zijn overigens over het algemeen afhankelijk van de resolutie van het scherm, aangezien Google zegt dat het minimaal zo groot moet zijn om de screenbuffer in het geheugen te krijgen, waardoor het probleem op lagere resoluties net zo goed aanwezig is.

Als die bitmap niet in RAM hoeft te staan zorg je toch dat 'ie daar nooit komt te staan? Je kunt een texture buffer aanmaken, die mappen en die pointer gebruiken om naar te schrijven (altans, dat zou je in C zo kunnen doen).

Maar goed, het makkelijkste lijkt me nu om je 3rd party lib te patchen met support voor compressed textures. Dat zal je memory usage reduceren tot een kwart. Verder kun je natuurlijk zorgen dat je maar een texture tegelijk in mem hebt - dan moet je GC d'r wel ruimte voor maken lijkt me.

[Caelorum]

PrisonerOfPain schreef op vrijdag 07 maart 2014 @ 21:13:
[...]
Als die bitmap niet in RAM hoeft te staan zorg je toch dat 'ie daar nooit komt te staan? Je kunt een texture buffer aanmaken, die mappen en die pointer gebruiken om naar te schrijven (altans, dat zou je in C zo kunnen doen). [...]

In c/c++ zou ik het ook zo doen, maar in java Android is dit volgens mij niet mogelijk. De control is afgeleid van een opengl surface control die weer een bitmap object nodig heeft, waardoor het weer vanuit JNI naar Android VM moet worden gezet.

[...]
Verder kun je natuurlijk zorgen dat je maar een texture tegelijk in mem hebt - dan moet je GC d'r wel ruimte voor maken lijkt me.

1 texture in geheugen is niet mogelijk. Ja, als ik het ga samenvoegen naar 1 grote en met uv coördinaten ga kloten, maar daar schiet ik nog niet veel mee op ^^
Beste manier zou zijn om deze opengl control te herschrijven naar c en effectief al het boeiende van deze activity dus buiten java om te laten lopen. Jammer genoeg heb ik de tijd daar niet voor waardoor ik nu met een suboptimale oplossing zit die op zich werkt, maar teveel geheugen vreet waardoor een deel van de targetdevices afvallen. Gelukkig zijn dat bijna allemaal oude apparaten dus niet zo'n super ramp.

@johannessmit, je wilt meer met java aan de slag, maar vind al wel dat het een raar taaltje is? Op java zelf is IMO niet zoveel aan te merken, behalve dan dat ik een aantal dingen mis die in C# wel zitten.

[PrisonerOfPain]

Caelorum schreef op vrijdag 07 maart 2014 @ 21:35:
[...]

In c/c++ zou ik het ook zo doen, maar in java Android is dit volgens mij niet mogelijk. De control is afgeleid van een opengl surface control die weer een bitmap object nodig heeft, waardoor het weer vanuit JNI naar Android VM moet worden gezet.

GLES30.glMapBufferRange returned een Buffer object waar je zelf afbeeldingen in kunt stoppen, wat is je source data? Jpeg of zo?

Verder zou je ook delen van je bestand kunnen inlezen en uploaden met GLES11.glBufferSubData.

Maar goed, het makkelijkste advies lijk je te negeren. Waarom geen DXT compression?

[Caelorum]

PrisonerOfPain schreef op vrijdag 07 maart 2014 @ 22:11:
[...]
Maar goed, het makkelijkste advies lijk je te negeren. Waarom geen DXT compression?

Omdat ik dan een library moet gaan zitten herschrijven waarvan ik niet eens zou weten waar ik zou moeten beginnen. Ik kan wel de output nog eens compressen, maar dan zit het al in de VM en ben ik eigenlijk alleen maar slechter af.
Het maakt allemaal ook niet uit. Ik weet wat ik zou moeten doen en dat is zorgen dat al die data niet op de heap van de Android VM wordt geplaatst, maar daarbuiten wordt gehouden. Daar heb ik echter geen tijd voor en ga ik dus voorlopig ook niet aan beginnen.

Overigens wel jammer dat dit alles niet in een apart topic staat ^^ Was niet de bedoeling om het hier zo uitgebreid op in te gaan. Was alleen maar mijn frustraties aan het uiten.

*edit*
Ohja, en ik moet minimaal API 10 ondersteunen, dus GLES30 is niet beschikbaar

[ Voor 4% gewijzigd door Caelorum op 07-03-2014 22:25 ]

[azerty]

Woo, mijn eerste bug in een Open Source Project opgespoord en een "patch" (2 letters code letterlijk veranderd) naar 1 van de devs opgestuurd

Nu maar hopen dat het niks anders kapot helpt

[Alex)]

Avalaxy schreef op vrijdag 07 maart 2014 @ 19:16:
[...]


Yup. Maarja, Windows Phone bewijst keer op keer dat er gewoon geen geld mee valt te verdienen. Ik stop maar gewoon het te proberen.

Hoe komt dat dan? Zijn er zo weinig gebruikers, of is de discoverability van de apps zo slecht?

Firesphere schreef op vrijdag 07 maart 2014 @ 20:06:
[...]

Nee, een echt serieuze recruiter, met goede reputatie, geen buckshot figuur (en al helemaal geen "mooi koppie" )

Je hebt het hier niet over de recruiter die had gelezen dat je geen recruiterspam wilde, maar een andere?

[Pizzalucht]

F.West98 schreef op vrijdag 07 maart 2014 @ 20:53:


LOL
WTF is er gebeurd met mijn script

dit moet het zijn:

[...]

Als ik in jouw test het laat encoden gaat het goed, alleen PHP zet het dan niet goed om.
Wat ik dus doe:

JavaScript:

var text = /* inputcontent */
$.ajax({
    data: { string: text },
    success: function(j) {
        log(j);
    }
});

Als ik text door jouw functie haal krijg ik dus terug wat ik net deed. Als ik dat niet doe: tré
Info: Server geeft HTML META attr met iso, ik stuur UTF8 naar de server

Wat nou als je een php script maakt dat een sessie opent op Tweakers en het in de juiste encoding naar Tweakers post? Kan je die lekker zelf hosten.

.

..

....

[Alex)]

Pizzalucht schreef op zaterdag 08 maart 2014 @ 00:06:
[...]


Wat nou als je een php script maakt dat een sessie opent op Tweakers en het in de juiste encoding naar Tweakers post? Kan je die lekker zelf hosten.

Een Tweakers-API op basis van OAuth zou dan een uitkomst zijn.

[ Voor 3% gewijzigd door Alex) op 08-03-2014 00:07 ]

[Caelorum]

Alex) schreef op zaterdag 08 maart 2014 @ 00:04:
[...] Hoe komt dat dan? Zijn er zo weinig gebruikers, of is de discoverability van de apps zo slecht? [...]

Ik gok zo dat er weinig betalende gebruikers zijn. Zelf bijv. ook nog nooit een app gekocht en heb al een WP sinds oktober 2010. Ik dacht dat het gemiddeld besteed bedrag wel hoger lag dan iOS en Android.

Moest lang zoeken naar iets enigszins bruikbaars en recent maar:

quote: http://www.winbeta.org/ne...ps-compared-those-android

[...]According to the data collected by Statistic Brain, 62 percent of Android users never paid a dollar for an app, while the number is a little lower for Windows Phone -- currently at 58 percent. Even when you compare the number of downloads on each platform, Android has a whopping 29 billion downloads compared to 4.1 billion on Windows Phone, the difference is massive. In terms of total app store revenue, Android generated $1.2 billion dollars, while the Windows Phone Store racked up $950 million. [...] Android currently resides at $0.04 per app per download while Windows Phone makes almost $0.23 per app per download. [...]

Dus aantal downloads is 7x lager dan bij Android. Als je app verkoopt krijg je meer per verkoop (~5x), maar het totaal aan geld dat rondgaat is 1,2x minder dan bij Android. Niet heel gunstig dus, maar ook weer niet zo super erg. Best te vergelijken zo te zien. Nog steeds in schril contrast met de iPhone, maar ok. Enige wat wellicht wel een punt is, is dat dit globale cijfers zijn en de markt in Nederland echt compleet anders is!

En hier de bron Statistic Brain: Mobile Phone App Store Statistics voor mooie tabelletjes

Alex) schreef op zaterdag 08 maart 2014 @ 00:12:
[...]
Er zijn voor mijn gevoel minder apps beschikbaar, de apps die er zijn lopen kwalitatief of functioneel flink achter bij hun Android/iOS-tegenhangers.

4x minder, en op zich valt het wel mee. Wat er echt mist zijn de apps van super kwaliteit. Als je het zou kunnen uitdrukken in een cijfer zou het denk ik hetzelfde zijn, want de echt slechte apps vind je een stuk minder dan bij Android, maar de echt goede apps helaas ook. Het is allemaal middenmoot en dat is erg vervelend, want je hebt vaak maar 1 goede app nodig en niet 10 middenmootjes. Aan de andere kant zou je er als app developer blij van moeten worden want de markt ligt in principe wijd open voor developers die kwaliteit kunnen leveren.

[ Voor 87% gewijzigd door Caelorum op 08-03-2014 00:32 . Reden: 12x -> 1.2x ]

[Alex)]

Caelorum schreef op zaterdag 08 maart 2014 @ 00:09:
[...]

Zelf bijv. ook nog nooit een app gekocht en heb al een WP sinds oktober 2010.

Daar kan ik me op zich wel bij aansluiten. Ik zit inmiddels al aan m'n tweede Windows Phone (beide zakelijk, eerste was een HTC Trophy, tweede is een HTC 8S) en ook al vind ik het OS prima werken, toch trekt het mij niet echt over de streep om ook privé voor WP te kiezen i.p.v. voor Android.

Er zijn voor mijn gevoel minder apps beschikbaar, de apps die er zijn lopen kwalitatief of functioneel flink achter bij hun Android/iOS-tegenhangers.

[ Voor 13% gewijzigd door Alex) op 08-03-2014 00:13 ]

[Avalaxy]

Alex) schreef op zaterdag 08 maart 2014 @ 00:04:
[...]

Hoe komt dat dan? Zijn er zo weinig gebruikers, of is de discoverability van de apps zo slecht?

Combinatie van dat vrijwel niemand een Windows Phone lijkt te hebben en het feit dat de gemiddelde Windows Phonebezitter gierig is als het aankomt op het betalen voor apps.

Zo heb ik een hele uitgebreide app gemaakt (de enige app waarmee men in Bitcoins kan handelen, tevens de hoogst gewaardeerde bitcoinapp voor WP, én de enige app met een prijsgrafiek) waar ik 100+ uur in heb gestoken, de app wordt door een grote groep mensen héél actief gebruikt (meer dan 75% is returning user en gebruikt de app elke dag). De app is volledig gratis, behalve het handelen, daarvoor heb je credits nodig die 1 tot 10 cent per stuk kosten. Met elke credit kun je één trade openen. Echter koopt vrijwel niemand die credits. Ik heb dus een survey ingebouwd om uit te zoeken waarom niet. Het meest terugkerende antwoord: het kost geld

Dan denk ik come on... Voor €3,49 heb je al 50 credits, daar kun je maanden mee vooruit, en als je het een beetje goed doet kun je er honderden euro's mee verdienen. Over een biertje kopen doet toch ook niemand zo moeilijk?

Dit is de app trouwens: http://www.windowsphone.c...9a-434f-8293-398745723de6.

Met Windows 8 eigenlijk exact hetzelfde verhaal. Ik steek 100+ uur in een app, schaf dure licenties aan (Telerikcomponenten), ik ga actief op zoek naar feedback, de app wordt zelfs gepromoot door Google zelf op Twitter, en uiteindelijk koopt vrijwel niemand hem. Allemaal opmerking dat de app er mooi uit ziet, maar dat men geen Windows 8 heeft of niet wilt betalen voor apps.

Paar voorbeeldjes, maar ik heb exact hetzelfde gehad met nog een sloot apps. Ik heb zo'n beetje alle business models geprobeerd. Een donatieknop resulteert in 0 donaties, ads resulteren in ongeveer €1 aan inkomsten per week door de belachelijke fillrate/eCPM van pubcenter, IAPs wilt men gewoon niet, etc.

Ik ben er dus gewoon goed klaar mee. Development voor WP8 en Win 8 is heerlijk, maar het zijn beiden echt to-taal geen interessante markten voor developers. Als je alleen al ziet dat een gemiddelde goede app op WP8 rond de 100 ratings heeft, en deze op Android 10.000+ ratings heeft dan weet je genoeg.

Overigens los van al dat is er met een aantal sleutelfiguren bij Microsoft gewoon niet samen te werken, afspraak na afspraak wordt niet nagekomen.

[Styxxy]

Bij Windows Phone is het ook vaak dat de current "populaire" apps (snelle boom) ook niet beschikbaar zijn. Tegen dat de hipheid over is, komt de app héél misschien ook naar WP. Dat vind ik vooral vervelend.

[Caelorum]

Avalaxy schreef op zaterdag 08 maart 2014 @ 00:43:
[...]
Combinatie van dat vrijwel niemand een Windows Phone lijkt te hebben en het feit dat de gemiddelde Windows Phonebezitter gierig is als het aankomt op het betalen voor apps. [...]

Dat laatste blijkt dus wel mee te vallen volgens de door mij eerder geposte statistieken.
Ik ben zelf trouwe gebruiker van Microsoft producten, maar kan niet zeggen dat ik als ontwikkelaar ook maar ooit heb nagedacht om een app in de markt te zetten voor win8 of wp8 om daar mijn kost mee te gaan verdienen. Heb het altijd aangevoeld als compleet hopeloos. Ben dus enigszins blij dat je je ervaringen hier post. Bevestigd eigenlijk wel weer dat tijd-opbrengst ratio compleet verkeerd uitpakt.

[ Voor 9% gewijzigd door Caelorum op 08-03-2014 00:52 ]

[Avalaxy]

Caelorum schreef op zaterdag 08 maart 2014 @ 00:51:
[...]

Dat laatste blijkt dus wel mee te vallen volgens de door mij eerder geposte statistieken. Ik ben zelf trouwe gebruiker van Microsoft producten, maar kan niet zeggen dat ik als ontwikkelaar ook maar ooit heb nagedacht om een app in de markt te zetten voor win8 of wp8 om daar mijn kost mee te gaan verdienen.
Heb het altijd aangevoeld als compleet hopeloos.

Tja, de statistieken zeggen ook dat In-App Purchases het populairst zijn... Uit m'n eigen onderzoek blijkt toch echt dat iedereen er een bloedhekel aan heeft

[Caelorum]

Avalaxy schreef op zaterdag 08 maart 2014 @ 00:52:
[...]
Tja, de statistieken zeggen ook dat In-App Purchases het populairst zijn... Uit m'n eigen onderzoek blijkt toch echt dat iedereen er een bloedhekel aan heeft

Kan ook de manier waarop zijn of de doelgroep van je apps. Dat er minder binnenkomt is wel te verwachten, maar dat je praktisch niets krijgt is wel vreemd.

[BikkelZ]

Ik zou een Windows Phone kopen om zo een goedkope en betrouwbare (Nokia) communicatietelefoon te hebben en wat Flappy Bird als ik bij de bank wacht. Ik ben die dure net niet Android telefoons helemaal zat en de Apple tax van 600 euro ga ik ook niet betalen, nog los van het feit dat ik geen dingen dagelijks bij me wil hebben die niet robuust zijn. Telefoons vallen gewoon bij mij, vroeg of laat. Ik wil een telefoon die mag en kan vallen, en als die dan toch kapot gaat, ik makkelijk een nieuwe kan kopen.

Of dat ik geld zou betalen voor apps? Neuh....als ik een Surface zou hebben wel. Voor mijn iPad betaal ik ook voor content als het interessant genoeg is.

[ Voor 13% gewijzigd door BikkelZ op 08-03-2014 00:59 ]

[Alex)]

Duidelijk verhaal beiden, thanks. Het bevestigt ook wel het gevoel dat ik heb bij Windows 8/WP8-development. Erg leuk, maar op dit moment (te) moeilijk om kostendekkend te krijgen.

In-app purchases vind ik een moeilijk thema. Vooral bij spelletjes kom je ze tegenwoordig heel snel tegen: "je hebt 50 credits nodig om het volgende level te unlocken, of je moet 1 dag wachten". Zeker als dat bij betaalde apps wordt gedaan voelt het als oplichterij.

[Avalaxy]

Caelorum schreef op zaterdag 08 maart 2014 @ 00:58:
[...]

Kan ook de manier waarop zijn of de doelgroep van je apps. Dat er minder binnenkomt is wel te verwachten, maar dat je praktisch niets krijgt is wel vreemd.

Ik hoor eigenlijk alleen maar soortgelijke verhalen van vrienden die Win 8 / WP8 dev doen. Ik ken niemand die zelfs ook maar bij een minimumloon in de buurt komt met z'n appinkomsten, ondanks hoge waarderingen (4+ sterren), gefeatured worden in de store, etc.

[BikkelZ]

Zelfde verhaal voor veel Android devs denk ik hoor, en de mensen die er wel geld mee verdienen verdienen hun geld ook wel terug bij een WP port. Melkkoeware zoals Candy Crush.

[Avalaxy]

BikkelZ schreef op zaterdag 08 maart 2014 @ 01:01:
Zelfde verhaal voor veel Android devs denk ik hoor, en de mensen die er wel geld mee verdienen verdienen hun geld ook wel terug bij een WP port. Melkkoeware zoals Candy Crush.

Oh, ik verwacht zeker niet dat ik ineens bakken met geld zal verdienen door over te stappen op Android Maar dan hoef ik ten minste niet meer de hele dag aan te horen: "ja, ziet er erg tof uit... Helaas heb ik geen Windows Phone" ~70% marktaandeel vs. ~10% marktaandeel (optimistisch)

[Caelorum]

De app markt is ook wel een beetje verziekt natuurlijk door alle mensen die het als hobby naast hun gewone werk doen en er geen tot weinig geld voor vragen.

[Alex)]

De meeste apps zijn dan ook wel hypes: ineens heel populair en daarna weer verdwenen. Danwel door desinteresse (Angry Birds, iemand?), omdat de maker het niet meer trekt (Flappy Bird) of omdat de API-eigenaar restricties ingesteld heeft (Twitterclients Rowi, Falcon Pro).

[MrAmos]

*gaat slapen en zich mentaal voorbereiden op morgen, de dag dat ik android ga breken, dat is iig de planning

[BikkelZ]

Avalaxy schreef op zaterdag 08 maart 2014 @ 01:02:
[...]


Oh, ik verwacht zeker niet dat ik ineens bakken met geld zal verdienen door over te stappen op Android Maar dan hoef ik ten minste niet meer de hele dag aan te horen: "ja, ziet er erg tof uit... Helaas heb ik geen Windows Phone" ~70% marktaandeel vs. ~10% marktaandeel (optimistisch)

Nee ik denk dat je op zich wel vette dingen maakt, wellicht dat je als je op Android de beste App maakt in een categorie dat het dan wel wat meer oplevert.

Maar wat vind je van Windows Phone als ontwikkelplatform op zich ten opzichte van Android? Of iOS?

[F.West98]

Element4l is een mooi spel. Echt mooi en origineel. Geldt ook voor de soundtracks.
[YouTube: http://www.youtube.com/watch?v=Z8rlCkq-81g]

[ Voor 24% gewijzigd door F.West98 op 08-03-2014 01:51 ]

[Avalaxy]

BikkelZ schreef op zaterdag 08 maart 2014 @ 01:39:
[...]

Nee ik denk dat je op zich wel vette dingen maakt, wellicht dat je als je op Android de beste App maakt in een categorie dat het dan wel wat meer oplevert.

Maar wat vind je van Windows Phone als ontwikkelplatform op zich ten opzichte van Android? Of iOS?

iOS heb ik geen ervaring mee (en dat wil ik zo houden, ik heb helemaal niks met Apple), Android begin ik me nu pas eigenlijk echt in te verdiepen. Een aantal observaties zover:

Pro WP8

• Naar mijn idee is de Windows Phone emulator stúkken beter dan die van Android. Vooral ook sneller.
• Je kunt C# gebruiken die weer fijne features heeft als async/await (al moet je dit via een nuget package toevoegen, standaard zit het er somehow niet in) en LINQ. Verder natuurlijk de auto properties ipv getters/setters, lambdas, commands en events.
• Duidelijke, nette design guidelines.
• Goede scheiding tussen UI en de rest mogelijk, wordt lekker makkelijk gemaakt met data bindings.
• Visual Studio 2013, zeker met ReSharper een erg krachtige ontwikkelomgeving. Handige tools zoals NuGet. Uitgebreide debugmogelijkheden.

Con WP8:

• Dev center faalt volledig. Stats lopen 3 dagen achter en zijn zeer beperkt.
• Geen mogelijkheid om betaalde apps te giften.
• Heel beperkt aantal controls. Aantal zijn via uitbreidingen als WPToolKit te downloaden, maar matig dat bepaalde basiszaken er niet standaard in zitten.
• Werkt niet native op Windows 8.
• Geen alphatests zoals bij Android, geen mogelijkheid om updates gefaseerd uit te rollen, niet de mogelijkheid om te reageren op reviews en meer basale dingen die de play store wel heeft.
• Mist veel XAML features die WPF wel heeft.

Pro Android:

• Zéér nette en uitgebreide tutorials en richtlijnen op developer.android.com. Zelfs de manier waarop je foutmeldingen dient te formuleren is gedocumenteerd
• AndroidStudio lijkt alles een stuk beter gemaakt te hebben. Paar jaar terug wat met Android geprobeerd toen Eclipse nog aangeraden werd... Dat was minder.
• Erg fijn dat je gedwongen wordt met string resources te werken, dat promoot betere code. Bij WP8 is er niets dat je dwingt om het zo aan te pakken.
• Heel erg fijn dat je met fragments een responsive-achtige app kunt maken die native draait op smartphones en tablets, zonder gedoe met meerdere projecten, aangepaste code, etc.
• Hoewel ik al m'n ontwikkeltools toch gesponsord heb gekregen vind ik het toch wel fijn dat de Androidontwikkeltools gratis zijn en eventueel ook op linux te draaien zijn.
• Prettig dat je op al je elementen een weight mee kunt geven om ze in een bepaalde verhouding te positioneren. In Windows Phone kan dat alleen met grid rows en columns, maar vaak wil je het ook op andere elementen toepassen waarna je weer smerige hacks nodig hebt.
• UI-elementen zoals de app bar lijken vrij geavanceerd te zijn en een hoop handige features te hebben, zoals de mogelijkheid om buttons alleen te tonen als er genoeg ruimte is en ze anders automatisch te groeperen onder een knop.
• Alphatests, betatests, gefaseerde updates, app giften.

Con Android:

• Activities die vernietigd worden bij een screen rotation, wtf.
• Naar mijn idee moet je in je activities héél veel boilerplate troepcode neerzetten om basale dingen werkend te krijgen.
• Geen databindings, dus extra boilerplate rommel in je "code-behind" om dingen te binden.
• Geen LINQ, lambas, achterlijke manier van events binden, geen TPL/async/await (al heb ik me nog niet echt verdiept in het Android-alternatief).
• Verschillende APIversies die verschillende dingen doen. Al is 80% van de gebruikers tegenwoordig over naar >4.0, dus dat is niet zo'n groot probleem meer.

Dat is wat zo snel in me op kwam. Ik zal ongetwijfeld nog veel meer kunnen bedenken als ik er even voor ga zitten

[alienfruit]

Stijl lijkt een beetje gejat van FEIST (http://playfeist.net)

[BikkelZ]

Avalaxy schreef op zaterdag 08 maart 2014 @ 02:13:
[...]


iOS heb ik geen ervaring mee (en dat wil ik zo houden, ik heb helemaal niks met Apple)

Wel naar verhouding de beste markt per user als je geld wil verdienen. Ook een hogere barriere om aan apps te beginnen (moet ik daar een Mac voor hebben??) dus minder rommel en concurrentie terwijl veel toffe apps tegelijk weer wel als eerste op iOS uit komen.

Avalaxy schreef op zaterdag 08 maart 2014 @ 02:13:
[...]

Android begin ik me nu pas eigenlijk echt in te verdiepen. Een aantal observaties zover:

**SNIP**


Dat is wat zo snel in me op kwam. Ik zal ongetwijfeld nog veel meer kunnen bedenken als ik er even voor ga zitten

Nice, thanks.

[Megamind]

Avalaxy schreef op zaterdag 08 maart 2014 @ 02:13:
[...]


Dat is wat zo snel in me op kwam. Ik zal ongetwijfeld nog veel meer kunnen bedenken als ik er even voor ga zitten

Heb je dan wel eens Xamarin geprobeerd? Aangezien je daar wel alle features van C# + VS hebt is het veel fijner om mee te werken. Ook de boilercode is veel minder en je hebt veel meer componenten.

[Avalaxy]

Megamind schreef op zaterdag 08 maart 2014 @ 02:53:
[...]

Heb je dan wel eens Xamarin geprobeerd? Aangezien je daar wel alle features van C# + VS hebt is het veel fijner om mee te werken. Ook de boilercode is veel minder en je hebt veel meer componenten.

Nope, helaas. Geen geld over voor die licentie. Zelfde geldt voor iOS dev: een iPhone en een Mac kopen is gewoon een beetje duur, Android kan ik gelijk mee aan de slag zonder kosten, WP8 ook

Edit: voor Android heb ik wel een Moto G gekocht van 175 EUR, dus dat is m'n enige kostenpost. Alsnog stukken goedkoper dan een iPhone.

[ Voor 11% gewijzigd door Avalaxy op 08-03-2014 03:24 ]

[Megamind]

Avalaxy schreef op zaterdag 08 maart 2014 @ 03:24:
[...]


Nope, helaas. Geen geld over voor die licentie. Zelfde geldt voor iOS dev: een iPhone en een Mac kopen is gewoon een beetje duur, Android kan ik gelijk mee aan de slag zonder kosten, WP8 ook

Edit: voor Android heb ik wel een Moto G gekocht van 175 EUR, dus dat is m'n enige kostenpost. Alsnog stukken goedkoper dan een iPhone.

Klopt maar je zegt dat je Telerik componenten hebt gekocht, die zijn niet goedkoop zeker?

Ik heb Xamarin met een VM hackintosh draaien, werkt prima omdat je voor iOS nogsteeds gewoon in Windows blijft devven (compileren gaat met een tcp link naar je mac).

[Avalaxy]

Megamind schreef op zaterdag 08 maart 2014 @ 03:34:
[...]

Klopt maar je zegt dat je Telerik componenten hebt gekocht, die zijn niet goedkoop zeker?

Ok, you've got a point

Maar dat was noodzaak, omdat de Win 8 controls set dus zo beperkt is dat je niet eens charts kunt maken (zelfde geldt voor WP8)

[Scott]

BikkelZ schreef op zaterdag 08 maart 2014 @ 02:50:
[...]


Wel naar verhouding de beste markt per user als je geld wil verdienen. Ook een hogere barriere om aan apps te beginnen (moet ik daar een Mac voor hebben??) dus minder rommel en concurrentie terwijl veel toffe apps tegelijk weer wel als eerste op iOS uit komen.

Apple is gewoon duur. Voor gebruikers, maar ook voor ontwikkelaars. Maar de support, documentatie en online resources zijn ook wel super vind ik.

[MrAmos]

Java gaat luisteren, gaat git stout doen..
Over naar de andere schoolopdracht, waar nog een systeemtest voor gemaakt moet worden

[ Voor 52% gewijzigd door MrAmos op 08-03-2014 11:57 ]

[BikkelZ]

Scott schreef op zaterdag 08 maart 2014 @ 04:41:
[...]


Apple is gewoon duur. Voor gebruikers, maar ook voor ontwikkelaars. Maar de support, documentatie en online resources zijn ook wel super vind ik.

Je hoeft in principe maar drie devices te supporten, iPad formaat, iPhone4+ formaat (een van de twee minstens in Retina) en de 3GS nog heel even met iOS6. Met Android is je spreiding van hardwaretypes en OS versies vele malen groter en grotere ontwikkelstudios moeten zowel meer geld in ontwikkeling als in het aanschaffen van hardware steken om alles goed te testen op fysieke devices. Er zijn altijd weer kleine dingen die net niet werken onder een emulator, kan me voorstellen dat het bij performance kritische dingen zoals een game al helemaal brak werkt om niet op fysieke hardware devices te testen.

[MrAmos]

BikkelZ schreef op zaterdag 08 maart 2014 @ 12:09:
[...]


Je hoeft in principe maar drie devices te supporten, iPad formaat, iPhone4+ formaat (een van de twee minstens in Retina) en de 3GS nog heel even met iOS6. Met Android is je spreiding van hardwaretypes en OS versies vele malen groter en grotere ontwikkelstudios moeten zowel meer geld in ontwikkeling als in het aanschaffen van hardware steken om alles goed te testen op fysieke devices. Er zijn altijd weer kleine dingen die net niet werken onder een emulator, kan me voorstellen dat het bij performance kritische dingen zoals een game al helemaal brak werkt om niet op fysieke hardware devices te testen.

Nu ben ik nog geen expert op android, maar ben dus voor school met een app bezig en als ik gewoon androids richtlijnen een beetje aan houd werkt alles redelijk out of the box.. OS versies is best makkelijk te handelen, aan de hand van je API-level.. ook kun je de javadoc op API level selecteren. De hardwaretypes is inderdaad wel aan de orde, maar als ik developers die voor het android-studio tijdperk werkten in eclipse hoor, is het heel veel fijner om nu met android aan de slag te gaan

[BikkelZ]

johannessmit schreef op zaterdag 08 maart 2014 @ 12:13:
[...]


maar als ik developers die voor het android-studio tijdperk werkten in eclipse hoor, is het heel veel fijner om nu met android aan de slag te gaan

Dat sowieso maar Eclipse heb ik nooit begrepen dat mensen daar vrijwillig in wilden werken. Overigens denk ik dat veel studios in de VS iPhone eerst doen omdat nou eenmaal een enorm percentage van de developers een Mac heeft en een iOS device. Dan is de investering natuurlijk minimaal terwijl je veel minder (maar nog meer dan genoeg) geëtter hebt om het op verschillende types aan de gang te krijgen.

[Caelorum]

Ik vind het een hell. De grote hoeveelheid aan hardwaretypes en API changes in, maakt dat je nog redelijk wat uitzonderingen moet lopen programmeren*. Daarnaast kom je er vaak niet achter dat een bepaald iets niet helemaal goed werkt totdat je je 10e VM met yet another configuration hebt opgestart.
Dat is met iOS en WP8 toch wel eventjes anders.

*Uitzonderingen vind je ook echt op de raarste plekken, maar over het algemeen als je bij de 'gangbare' dingen blijft heb je er inderdaad niet tot weinig mee te maken.

[ Voor 19% gewijzigd door Caelorum op 08-03-2014 12:36 ]

[F.West98]

Jullie zijn hier toch ook wel enthousiast over Xamarin, en ik ook. Maar een vriend van mij (android-dev, anti-multiplatform developing) kwam hier mee aan. Wat vinden jullie van die punten? Limited UI sharing is natuurlijk logisch, maar die andere punten, van traag met opstarten?

[Ryur]

F.West98 schreef op zaterdag 08 maart 2014 @ 12:41:
Jullie zijn hier toch ook wel enthousiast over Xamarin, en ik ook. Maar een vriend van mij (android-dev, anti-multiplatform developing) kwam hier mee aan. Wat vinden jullie van die punten? Limited UI sharing is natuurlijk logisch, maar die andere punten, van traag met opstarten?

Ik heb zelf geen ervaring met ontwikkelen in Xamarin. Maar wel met apps die ermee gemaakt zijn.
Ik vind helemaal niet dat hij traag is met opstarten.
Verder is hij opzich wel positief over Xamarin hoor? Ieder platform heeft nadelen.

Heel interessant screencast om te kijken: http://channel9.msdn.com/...-Development-With-Xamarin
(Van mijn HELD Robert Green!)

[ Voor 6% gewijzigd door Ryur op 08-03-2014 12:47 ]

[Caelorum]

Nouja, Xamarin draait dacht ik een .Net VM waarbinnen de code wordt gedraait? In het geval van Android vervang je dan toch alleen de Android VM door een .Net VM? Resultaat zou dan min of meer hetzelfde moeten zijn.

[F.West98]

Dacht ik ook.
Mono ipv Dalvik, Mono gebruikt dacht ik de NDK.

[Caelorum]

F.West98 schreef op zaterdag 08 maart 2014 @ 12:57:
Dacht ik ook.
Mono ipv Dalvik, Mono gebruikt dacht ik de NDK.

quote: http://docs.xamarin.com/g...er_the_hood/architecture/

[...]Xamarin.Android applications run within the Mono execution environment. This execution environment runs side-by-side with the Dalvik Virtual Machine. Both runtime environments run on top of the Linux kernel and expose various APIs to the user code that allows developers to access the underlying system. Both Mono and Dalvik are runtimes written in the C language.[...]

Ja dus

[StM]

Nee, het is geen .NET VM. De .NET code wordt naar machinecode gecompileerd (AOT), maar er is een runtime omgeving ontwikkeld (vergelijkbaar met de Obj C runtime volgens mij) die een brug vormt naar de java wereld aangezien lang niet alles via de NDK aanspreekbaar is. Je .NET code runned op vergelijkbare snelheid als de Java code, maar je calls naar de Dalvim VM zijn relatief duur. Hoe meer je dus in .NET kan doen hoe lager de overhead is.

iOS ontwikkeling is inderdaad relatief duur, maar betaald zich wat mij betreft dubbel en dwars terug. Al was het maar wegens een hele bak minder frustaties door die hopeloze hw verschillen bij Android en de nog veel beroerdere abstractie

[Caelorum]

StM schreef op zaterdag 08 maart 2014 @ 14:05:
Nee, het is geen .NET VM. De .NET code wordt naar machinecode gecompileerd (AOT), maar er is een runtime omgeving ontwikkeld (vergelijkbaar met de Obj C runtime volgens mij) die een brug vormt naar de java wereld aangezien lang niet alles via de NDK aanspreekbaar is. Je .NET code runned op vergelijkbare snelheid als de Java code, maar je calls naar de Dalvim VM zijn relatief duur. Hoe meer je dus in .NET kan doen hoe lager de overhead is.[...]

Je verhaal klopt op zich wel, behalve dat er wel degelijk een .Net VM draait zoals ook het volgende plaatje duidelijk maakt:

[alienfruit]

Jongens en meiden, jullie moeten toch echt eens gaan kijken naar de RemObjects Oxygene oplossing. Inmiddels kan je kiezen tussen code kloppen in Pascal of C#. Maar het compileert gewoon rechtstreeks na de runtime, bijv. Objective-C runtime of JVM. Het gebruikt C# alleen als taal zonder de .NET runtime.

Q: What is the difference between RemObjects C# and Xamarin?

A: Xamarin is a commercial toolchain that brings the .NET Framework to Android and iOS. RemObjects C# looks at this idea of reusing C# on a different level: It brings the C# Language to the Cocoa and Java/Dalvic platforms, instead.

Zie ook: http://www.remobjects.com/elements/hydrogene/

[Caelorum]

Hoeveel aandelen heb jij zeg?! ^^

[Megamind]

alienfruit schreef op zaterdag 08 maart 2014 @ 14:16:
Jongens en meiden, jullie moeten toch echt eens gaan kijken naar de RemObjects Oxygene oplossing. Inmiddels kan je kiezen tussen code kloppen in Pascal of C#. Maar het compileert gewoon rechtstreeks na de runtime, bijv. Objective-C runtime of JVM. Het gebruikt C# alleen als taal zonder de .NET runtime.


[...]


Zie ook: http://www.remobjects.com/elements/hydrogene/

Ik heb er even naar gekeken maar imo krijg je een stuk minder .NET dan Xamarin.

F.West98 schreef op zaterdag 08 maart 2014 @ 12:41:
Jullie zijn hier toch ook wel enthousiast over Xamarin, en ik ook. Maar een vriend van mij (android-dev, anti-multiplatform developing) kwam hier mee aan. Wat vinden jullie van die punten? Limited UI sharing is natuurlijk logisch, maar die andere punten, van traag met opstarten?

Ik vind het maar zinloze argumenten eerlijk gezegd:

App Overhead

Agree, de startup tijd is enkeke seconde langer (Android 2.3 device hier nog), maar je hebt een splashscreen dus ik erger me er niet aan.

Limited Sharing of UI Code Across iOS and Android

Grootste non-argument. Xamarin is JUIST krachtig omdat de UI gemaakt worden zoals Android en iOS dat willen, dus geen gekloot met standaard UI builder zoals Crono, of Corona. Als het goed is heb je toch een gescheiden businesslaag van je UI laag.

Limited Sharing of Code Outside of Xamarin

Waarom zou je in hemelsnaam code willen delen met een HTML5 app? Dat is hetzelfde als zeggen dat je geen WPF controls kan inladen...

Ecosystem and Community

Soms kan het lastig zijn om iets te vinden in de Xamarin website maar de support is wel OK en de communitie leeft. Grootste voordeel is dat je Android Java code 1 op 1 kan porteren naar C# en je krijgt dezelfde resultaten.

The Third Learning Curve

Als je C# kent is de leercurve gewoon niet veel groter dan beginnen met native Android of iOS.

Ik denk dat de auteur het concept van Xamarin en RemObjects gewoon niet snapt en lekker bij zo'n crossplatform appbuilder moet blijven.

[ Voor 61% gewijzigd door Megamind op 08-03-2014 15:57 ]

[alienfruit]

Megamind schreef op zaterdag 08 maart 2014 @ 15:50:
Ik heb er even naar gekeken maar imo krijg je een stuk minder .NET dan Xamarin.

Klopt het is immers geen .NET… Verder wil je ook natuurlijk ook niet de .NET runtime embedded in je mobile app

Hoeveel aandelen heb jij zeg?! ^^

Geen, hoezo?

[ Voor 9% gewijzigd door alienfruit op 08-03-2014 16:18 ]

[Megamind]

alienfruit schreef op zaterdag 08 maart 2014 @ 16:17:
[...]


Klopt het is immers geen .NET… Verder wil je ook natuurlijk ook niet de .NET runtime embedded in je mobile app

Voor de prijs wat je voor REMobjects betaald vind ik dat nu nog niet waard, heb dan liever gewoon een full-blown .NET framework.

Heb nu bv een app waar ook SignalR inzit wat prima gaat aangezien er een mono DLL voor is.

[Caelorum]

alienfruit schreef op zaterdag 08 maart 2014 @ 16:17:
[...] Geen, hoezo?

Oh, gewoon omdat je zo super enthousiast de hele tijd weer aankomt zetten met RemObjects. Dacht dat je er een bepaald belang bij had ofzo, maar blijkbaar ben je er zelf gewoon heel erg blij mee ^^

[BikkelZ]

Gisteren een remote interview gehad voor een remote iOS Developer functie, ging lekker. Hopelijk goed nieuws volgende week.

[PrisonerOfPain]

[Caelorum]

Whaha! Zo toepasselijk.

[F.West98]

Je verwacht het niet.
Android Studio crasht on load. Na een update gedaan te hebben werkt Gradle niet. Crasht.

* F.West98 gaat wel weer verder in Visual Studio

Error: "De map is niet leeg."

* F.West98 wordt boos.

[azerty]

PrisonerOfPain schreef op zaterdag 08 maart 2014 @ 20:21:
[afbeelding]

Waar kunnen we die te pakken krijgen?

[BtM909]

Googlen naar CSS is awesome mug || T-shirt levert genoeg hits op

[azerty]

Heb je geen lmgtfy linkje voor me?

/luiheidsmodus

[Caelorum]

http://lmgtfy.com/?q=CSS+is+awesome+mug+%7C%7C+T-shirt daar

[azerty]

Caelorum schreef op zaterdag 08 maart 2014 @ 22:46:
http://lmgtfy.com/?q=CSS+is+awesome+mug+%7C%7C+T-shirt daar

Hartelijk dank voor de link!