rosetta_stoned•

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.

9
Surye•

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.

3
s73v3r•

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.

3
bambh•

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

2
Timmmmbob•

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.

2
Surye•

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

1
monstermunch•

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.

1
thestringpuller•

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.

1
monstermunch•

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.

1
haika•

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

2
snk_kid•

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.

11
bambh•

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.

2
s73v3r•

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.

2
bambh•

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.

1
[deleted]•

could you run queries server side?

/no understanding of your problem ^^

1
bambh•

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.

1
[deleted]•

Bringing the best of two worlds together: Java and Visual Studio. m)

-11
evilbunny•

I think that this is more about a c++ framework for android, made to compile from VS :)

6
[deleted]•

But ... but ... why? If you can program in C# why would Java be any different? Seriously.

-13
schnuerbel•

Seriously dude... I hope you don't write any code if you can't tell the difference between C# and C++.

9
[deleted]•

[deleted]

1
ziom666•
  1. you clearly haven't even look on that page. it's about c++, not c#.
  2. maybe c# is not far from java, but java lacks many c# features, and for me programming in java is not pleasant.
7
[deleted]•

After C#, programming in JAVA is plain awful.

AWFUL!

8
geeteeaii•

Going from Java to C# is easy. Going back to Java from C# is painful since the IDE and language spoils you.

3
grauenwolf•

This is a c++ tool.

1
geeteeaii•

Going from C++ to Java is easy. Going back to C++ from Java is even easier since Java is terrible. Better?

2
grauenwolf•

Yep.

2
CowboyProgrammer•

Why bother with Java, when there's MonoDroid?

2
jbrechtel•

Why bother with Java, when there's Scala?

FTFY

PS: The post is about building Android apps in C++, not Java.

1
[deleted]•

[deleted]

1
jbrechtel•

I don't know F# so it's hard for me to say. With that in mind, I'd need to know more about you. The single largest factor I'd say would be your platform. If you're on Windows then F# may be a better choice simply because the tooling around Scala might take more time for you to get used to. That kind of thing is not really core to the language (though it is important) and can ultimately dissuade you from using it.

Relevant: I'm writing a series of blog posts addressing this specific problem with Scala and Android. First one is here http://nevercertain.com/index.php/2011/02/scala-android-intellij-win-part-1-prerequisites/

The flip side is true of F# if you're not a Windows guy. All things being equal, I think Scala is a great language with a lot of interesting and some unique features. I can elaborate if you'd like.

3
ziom666•

I'm not an expert either, but working with F# was very pleasant for me. It supports many exciting features like monads, "erlang light-threads", but you can also use whole .net platform (but you already know that probably). visual studio have really good support, and if you know basics of ocaml you can start creating f# programs right now. combining f# with c# is also very easy. Scala on the other hand (maybe it's just me), I don't get that language. those "i can program without using any dot" introduces uncertainly, and I was pissed i had to spend so much time just to understand what someone wrote. i also had troubles with running it on netbeans, but it's because i work mainly with visual studio. imho you should try both, they are much alike, but completely different, even though in the end you will stay with just one you will learn something :)

3
undershirt•

Hey, I'm starting to use Java at my job for OpenGL demos and on weekends writing things for Android. Can you tell me what you've used Scala for? I might be interested in using it.

1
jbrechtel•

Just a couple small apps so far. Working on a third, larger, Android app now in Scala. It will have a web component as well which I may also write in Scala.

1
s73v3r•

MonoDroid costs money.

1
CowboyProgrammer•

Most good things do.

1