Naar content
Trending apps
  • Inbox by Gmail

  • Maps: Navigatie en OV

  • WhatsApp Messenger

  • Messenger

  • Facebook

Trending games
  • Dr. Mario World

  • Harry Potter: Wizards Unite

  • Breaking Bad: Criminal Elements

  • The Elder Scrolls: Blades

  • Ghostbusters World

Trending smartphones
  • Microsoft Surface Duo

  • OnePlus 7T Pro

  • Nokia 7.2

  • Xiaomi Mi 9T Pro

  • Samsung Galaxy Note 10 Plus

Nieuwste tablets
  • Samsung Galaxy Tab S6

  • Samsung Galaxy Tab A 10.5

  • Samsung Galaxy Tab S4

  • Samsung Galaxy Tab S3 9.7

  • Asus Zenpad 3S 10

Marvin

Marvin

  • Lid sinds 30 december 2009
  • Berichten 1778
  • Reputatie 10
  • #1
  • 23 juni 2010
  • 14:33

Niet soepel lopen op het target is een heel ander issue dan onstabiliteit ten gevolge van het gebruik van een ontwikkelomgeving. Dat kan te maken hebben met met minimal requirements die niet gehaald worden of een gebrek aan optimalisatie (performance problemen dus), maar van echte onstabiliteit (als in: crasht) heb ik niet veel gehoord. Ja, een paar custom ROMs zijn niet stabiel maar dat ligt niet aan de ontwikkelomgeving maar aan de tekortkomingen van de portering.

De uitspraak was: “native C kan onstabiel zijn”. In mijn optiek betekent dat dat er fouten zouden zitten in de toolchain en/of de libraries. Natuurlijk zitten er fouten in (het is en blijft tenslotte een flinke bak software!) maar ik kan niet zeggen dat de applicaties die gebouwd worden met native C onstabieler zijn dan in java of een willekeurig andere taal geprogrammeerde applicatie anders dan mogelijk door onkunde of gebrek aan design. Nogmaals, dat heeft niets te maken met de stabiliteit van de ontwikkelomgeving. Daarom hoor ik heel graag van “Rode Ridder” wat'ie precies bedoelt met zijn uitspraak dat native C onstabiel kan zijn!

Bewerkt (22 april 2013 12:26)
Rode_Ridder

Rode_Ridder

  • Lid sinds 14 maart 2010
  • Berichten 58
  • Reputatie 0
  • #2
  • 25 juni 2010
  • 05:32

kijk
Er zitten geen fouten in C, libraries etc etc, daarom zei ik "KAN
de ”KAN" kom van de verschillende hardware en OS versies
als je iets schrijft en werkt op een Nexus het kan ook falen op een andere toestel.

Bijvoorbeeld, Objective C is stabiel op het Iphone platform dat komt omdat er maar niet veel meer verschillende toestellen zijn uitgebracht.
Voor een iPhone developer is dat heel erg handig.
Hij hoeft geen zorgen te maken of het op XXX toestel en of XXX versies werkt of niet werkt.
alles is standaart volgens Apple.

Bewerkt (22 april 2013 12:26)
joyrider

joyrider

  • Lid sinds 06 juli 2010
  • Berichten 6
  • Reputatie 0
  • #3
  • 6 juli 2010
  • 23:48

Hey allemaal,

ik heb sinds kort ook een android toestel aangekocht, een htc desire. Nu ik heb reeds ervaring met het schrijven van kleinere games en ports op andere embeded devices zoals gp2x, dingoo a320, nokia N810, … dit werd voornamelijk gedaan via de gcc tool(chains). Al deze devices draaiden linux (niet android) dus dit is compleet nieuw voor mij.

Nu wat betreft het programmeren in C/C++ voor android, ik vermoed dat het gewoon een kwestie is van een (gcc) toolchain te downloaden voor de architectuur die men gsm gebruikt of eventueel zelf eentje te builden.

Is dit enerzijds mogelijk ? Ik bedoel als ik naar het gros van de applicaties kijk zijn dit allemaal feitelijk java appliacties (die apk files) of vergis ik me, is het dan enigsinds mogelijk om bvb applicaties op de marketplaces te plaatsen die gemaakt zijn via de gcc toolchains ? Of draait heel het android systeem in een soort van java virtual machine ?

Indien men toch applicaties zou kunnen maken via de gcc toolchains en deze zetten op de marketplace(s) vermoed ik dat het gebruik van bijvoorbeeld de SDL libs geen probleem zou mogen zijn. Het enige nadeel dat ik hierin zie is dat de applicaties die ik zou maken waarschijnlijk gebonden zijn aan de architectuur van mijn gsm maw de htc desire, aangezien er waarschijnlijk verschillende architecturen per gsm gebruikt worden en ik dus zou moeten crosscompilen om de applicaties op “andere” gsm's te laten draaien dan mijn htc desire. Dit verklaart misschien waarom de meeste applicaties op zich java applicaties zijn (voor compatibiliteit tussen de verschillende android toestellen).

Een ander vraagje dat ik hierover heb, is het feit of je phone root access nodig heeft om zulke applicaties te kunnen draaien of werken deze ook op niet geroote droid phones ?

Indien het gebruik van gcc toolchains niet echt “the way to go” is en ik dus gebonden ben aan java, wat ik dan wat zou moeten aanleren vraag ik me af of er soms SDL ports / wrappers libs voor java bestaan voor de android toestellen en indien zo wat de beperkingen hiervan zijn (bijvoorbeeld kan men het touchscreen gebruiken in deze mogelijke sdl wrappers en dergelijke …)

Is er iemand die me hier meer over kan vertellen? Het zou me wat tijd uit besparen met alles te moeten opzoeken en kan ik misschien wanneer ik zin en tijd heb me wat bezig houden met eens java te leren

Bewerkt (22 april 2013 12:27)
koenhoorelbeke

koenhoorelbeke

  • Lid sinds 11 juni 2010
  • Berichten 52
  • Reputatie 0
  • #4
  • 7 juli 2010
  • 00:12

Hey joyrider,

Moeilijke vragen die je steltIk kan er ook waarschijnlijk geen goed antwoord op geven. Ik heb enkele maanden terug ergens een e-book gedownload die juist dieper inging op het “native” programmeren in C voor de Android.

Vermits ik geen C ken (wel C#, maar dat is verre van C of C++), heb ik 't ook niet echt gelezen … ik ga nog eens zoeken of ik het nog ergens heb (ik gooi niet snel dingen in de prullenmand).

Enige wat ik wel kan zeggen is dat je moet zoeken naar de Android NDK (Native Driver Kit) … goed startpunt is: Android NDK | Android Developers

Voor zover ik weet (maar let op, dit zijn “assumptions”) moet je het NDK gebruiken voor performance-intensive apps, zoals bijv games. Eens je die gemaakt hebt, zijn ze gewoon net als andere apps te downloaden van de Android Market en werken ze “normaalgezien” op alle Androids, en moeten je users niet een geroote telefoon hebben.

Maar dat is natuurlijk onder “normale” omstandigheden, en ik weet natuurlijk niet hoe specifiek en hoe ver je kunt gaan in dat soort zaken. Hoe verder je kan gaan, hoe meer kans natuurlijk dat je dan toch opeens met heel machine-specifieke dingen bezig bent …

Succes met je zoektocht, en hou ons af en toe op de hoogte. Vind ‘t op zich interessante materie, maar voor wat ik doe, is het (voor zover ik ’t kan inschatten) overkill-materie.

Greetingz,
Koen<

Bewerkt (22 april 2013 12:27)
koenhoorelbeke

koenhoorelbeke

  • Lid sinds 11 juni 2010
  • Berichten 52
  • Reputatie 0
  • #5
  • 7 juli 2010
  • 00:17

Mail me anders even … heb dat e-book gevonden (Pro Android Games, van APress) … koen punt hoorelbeke bij gmail

Greetingz,
Koen<

Bewerkt (22 april 2013 12:27)
joyrider

joyrider

  • Lid sinds 06 juli 2010
  • Berichten 6
  • Reputatie 0
  • #6
  • 7 juli 2010
  • 01:16

Hey koen,

bedankt voor de tip over die PDF, ik heb hem ondertussen ook zelf gevonden en even snel doorgenomen. Voor zover ik zie is wat ik initieel dacht dat mogelijk zou zijn dus niet mogelijk (zie ook http://www.phonenews.com/five-common-myths-about-linux-and-android-5105/ ). Maar google / android api voorziet een systeem om shared (native) libraries op te roepen in java code (jni). Dus ik zal toch wat java moeten leren vrees ik. Dit is op zich niet zo erg, heb dankzij mijn job al ervaring met andere programmeer talen dus kan dit niet zo moeilijk zijn.

Mijn doel was feitelijk om vrij “gemakkelijk” games te “porten” van bvb de gp2x (www.gp32x.com) of dingoo a320 (www.dingoonity.org) naar de android mits crosscompiling, maar dit gaat dus niet zo maar, je moet feitelijk werken met een soort van callback systeem (die jni) waarmee je functies oproept in native c code. Maw de hoofdapplicatie (op de gsm) blijft java, maar je kan wel code hergebruiken van bestaande projecten die je naar android wil porten, mits de belangrijke delen op te splitsen en in een library te zetten. Dit zorgt ervoor dat de main loop altijd in java blijft gebeuren en je gewoon voor bvb ai of main game logic de originele functies in C/C++ kan oproepen. Het is dus meer werk dan een gewone port maar lijkt me wel haalbaar en vele minder werk dan alles om te zetten naar java code.

Ik heb recent nuja een half jaartje terug of zo voor de dingoo a320 (een koreaanse handheld), die standaard in een U-COSII systeem draait de gnuboy (opensource gameboy emulator) omgezet gehad naar u-cosII code. Dit lijkt me min of meer hetzelfde als wat ik met android porting zou moeten mits een tussenschakel namelijk die jni en wat andere aanpassingen maar het lijkt me niet onhaalbaar.

Ik zal me dus eerst wat verdiepen in java en dan wat spelen met die jni en misschien lukt het me ooit om op deze manier gnuboy ook te porten naar android, want ik heb gezien dat deze nog niet bestaat. Althans niet gratis, want ik vermoed dat die betalende versie gbcdroid of hoe heet ie ook weer, hetzelfde systeem gebruikt en dus op zich opensource / gpl code gebruikt van de originele source code van de makers van gnuboy(is dit eigenlijk conform de gpl license ???) , tenzij het een compleet nieuw geschreven emulator
is natuurlijk…

afin voor het daartoe komt zal ik wat moeten dingen bijleren met name voor de java kant en misschien best eerst wat expirimenteren met kleinere (linux) ports.

Nogmaals bedankt

Bewerkt (22 april 2013 12:27)

Reageer

Om te reageren, dien je te zijn ingelogd. Druk op de onderstaande knop om in te loggen of maak een nieuwe account aan.

Inloggen Registreren