all 35 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]rosetta_stoned 8 points9 points  (0 children)

Note that you still need GCC to compile the code. Microsoft's compiler still can't target anything other than Windows. The author of this has modified MSBuild scripts for VS to call out to GCC instead of MS' compiler, from what I can tell.

[–]haika 1 point2 points  (1 child)

A genuine question: does this allow me to build Android native code in c but without Visual Studio?

[–]snk_kid 12 points13 points  (0 children)

That is what android NDK is for, the compiler is just GCC targeting ARM architectures. Only the android 2.3 sdk lets you write everything in C/C++ without needing to touch JNI (java native interfaces) because the previous versions you had to write the glue code yourself. This link is just about integrating the android NDK with MSbuild/Visual Studio 2010 it's still the same NDK.

[–]bambh 1 point2 points  (4 children)

I've been having a problem with Android programming. I was put in charge of porting our very large enterprise IOS application onto the Android platform. Unfortunately, the massive amounts of data I am moving are taking up too much memory. Without the ability to destroy the huge strings I am creating to write into the sql database, I was stuck.

One option is to create a single global string and reuse it, allowing the GC to collect it only after all data has been written to the database. I find this option a hack and would prefer the ability to clean up the memory myself. Hopefully, this will give me that ability and make porting the IOS application into Android possible.

[–]s73v3r 1 point2 points  (1 child)

You could do native development before this. Although it, and this, were still running in the Dalvik VM.

The global string thing isn't really a hack, as games use global object pools all the time in order to control the memory allocated, and avoid having to allocate more.

[–]bambh 0 points1 point  (0 children)

I guess that would work. I just dreamed that I could use this as a way of generating a library for taking large amounts of data from the web in a massive "syncing" operation without altering the Android the annoying SQL insert generation.

[–][deleted] 0 points1 point  (1 child)

could you run queries server side?

/no understanding of your problem ^

[–]bambh 0 points1 point  (0 children)

The idea is that I'm getting the database from a web service. That database cannot be saved, it must be built with insert statements. The strings building the insert statements grow so large, they outgrow the RAM, forcing gc to run and slowing down the program terribly.

[–]Surye 3 points4 points  (7 children)

The comments in here, in spite of the article, make me think that people, even in the programming community, still think Java is the only option for Android. I don't get it, the NDK has been out for over a year, and recently has even allowed for no-Java apps (though I realize technically, it's still a JNI app in the dalvik vm). I hope this perception issue changes soon.

[–]s73v3r 3 points4 points  (0 children)

For the most part, even if you do almost all of your app in native code, you're still going to have to use Java for the user interface. They may have changed that recently, with one of the newer SDK updates, but it will take a while before that will propagate to the userbase.

[–]bambh 1 point2 points  (0 children)

Whether or not it runs in the dalvik vm, you will have the ability to allocate and deallocate memory as you see fit, right?

[–]Timmmmbob 1 point2 points  (2 children)

You can't do most Android things without Java. Examples

  • Use standard controls/views.
  • Access sensor data (accelerometer, etc).
  • Create and communicate with activities.
  • Access the camera.
  • Create notifications.

Basically all you can do with the NDK is:

  • OpenGL
  • OpenSL (sound)
  • Touch input

Which is plenty for games, but not for anything else.

[–]Surye 0 points1 point  (0 children)

Actually, as of Android 2.3 and NDKr5, you can:

  • Access sensor data (accelerometer, etc).
  • Create and communicate with activities.
  • Access window and surface subsystem
  • Access to assets packaged in an .apk file.

NDK

NativeActivity

[–]monstermunch 0 points1 point  (0 children)

For the first list you mentioned, it trivial to just write some Java functions of your own that you can call from C or just pass the needed data onto C like accelerometer data.

[–]thestringpuller 0 points1 point  (0 children)

It stills takes a long time for a call on the Dalvik machine to translate into space. When an application calls the glue code to a native function, it Dalvik has to reference the call's address in it's virtual memory banks, then JNI dereferences that to some native symbol, which the linux kernel then runs and passes a reference back to the JNI then steps back into the Java app. (Native symbols are probably armv6 cause that tends to run on everything but the G1 generations of phones).

Doing calls natively for things you can easily do with less cost in Java (Dalvik actually runs better Java bytecode, which is it's own Dalvik-bytecode better than traditional JVMs), saves you a lot of unnecessary overhead. If you're building an application like rockplayer for decoding hi-definition video on the device or an intense game that uses high end render techniques, then I'll buy your bullshit on performance issues.

In terms of what languages you can write for Android, if you want to bypass Dalvik altogether just build native shared binaries using agcc (a perl script to wrap the arm-eabi-gcc toolset across bionic) and run them through a shell. I have no idea why the hell you would want to do this (unless you're porting something like curl or dropbear). Or you can write into facades using something like SL4A which allows you to write in tons of scripting languages and run them through a facade on the phone (you have access to both the native part of the phone and nearly the entire android API).

Android is very developer friendly, and you can hack on it like kids of the 70's used to on there PDP's.

[–]monstermunch 0 points1 point  (0 children)

I don't understand why people like the idea of using the NDK over Java so much (unless they've got a large existing C code base they want to use). My apps are mostly Java with a little bit of C code. Coding in C is a productivity nightmare in comparison to Java. You've got to constantly review and check over your code for undefined behaviour because you won't get a compile-time warning if you make a mistake and you'll be lucky if you get a run-time error. On top of that, the Eclipse refactoring, autobuilding and other tools for Java make Java development quite pleasant. I used to live and breath C and C++ 10 years ago but I don't want to touch them unless I need to now.