Do you really need to take time to learn Java? It's not far off from C# or C++. Just read some material that assumes you want to transition from C++ to Java. Than just start writing, and refine things as you go along.
It's Android that you will have to learn.
Or you can try Lib GDX. It's cross platform Windows + Android, and it has a lot sof stuff implemented in NDK for speed. It's like meeting your goal halfway.
Feasibility of writing android apps purely through the NDK
It is very viable option. I'm using it all the time. And as I said before, it works fine.
Maybe you did set up it wrongly. If it doesn't work for you, it doesn't mean it won't work for everyone.
And this is for Native Activity or just Native?
IE: Purely C/C++ or a mix of C/C++ and Java?
L. Spiro
I was working on a native activity for a short while. I used this tutorial (you can go to the next or previous to see more) to do remote debugging, and it worked pretty ok. Certainly not as nice as when I debug with Visual Studio or gdb on my local machine, but still decent. One challenge is just the setup. The setup isn't super friendly, but once you finally set it up it's not overly horrible. Another issue is that the debugger has to attach itself, which takes some time, so you can't (or at least I couldn't) debug the first few seconds the app was running.
There can be a speed benefit, but it's not promised. Google says one good candidate for a native activity is a physics simulation, which is exactly what I was doing.
One issue with using the NDK is taking shortcuts. Normal Android apps (in Java) don't have a main loop (or even a main function), and the API is really built around activities (not applications). Long story short: if you use the NDK because you're used to having a main loop and C/C++, but don't properly understand how Android applications and activities work, you will suffer. I'd suggest you only use the NDK if you are already familiar with the Java API.
Some things in the Android API weren't readily available in the NDK, but I think most things are available. But then again, there are some things available in the NDK that aren't available in Java (like OpenSL (or any other low-level API that gives you fine control over things)).
In short, yeah, it's possible, but don't start there. If you're new to Android, start with its Java API and make sure you properly wrap your head around applications, activities, services, etc. because despite Android being Linux, it doesn't really function like Linux. After that, then move to the NDK. Sure, you can skip the Java API and move straight on to the NDK, but it'll likely be painful and take you longer to get to any level of competence.
There can be a speed benefit, but it's not promised. Google says one good candidate for a native activity is a physics simulation, which is exactly what I was doing.
One issue with using the NDK is taking shortcuts. Normal Android apps (in Java) don't have a main loop (or even a main function), and the API is really built around activities (not applications). Long story short: if you use the NDK because you're used to having a main loop and C/C++, but don't properly understand how Android applications and activities work, you will suffer. I'd suggest you only use the NDK if you are already familiar with the Java API.
Some things in the Android API weren't readily available in the NDK, but I think most things are available. But then again, there are some things available in the NDK that aren't available in Java (like OpenSL (or any other low-level API that gives you fine control over things)).
In short, yeah, it's possible, but don't start there. If you're new to Android, start with its Java API and make sure you properly wrap your head around applications, activities, services, etc. because despite Android being Linux, it doesn't really function like Linux. After that, then move to the NDK. Sure, you can skip the Java API and move straight on to the NDK, but it'll likely be painful and take you longer to get to any level of competence.
Long story short: if you use the NDK because you're used to having a main loop and C/C++, but don't properly understand how Android applications and activities work, you will suffer.
Yeah, I think this is one of the main problems. One of the main reasons why you'd want to get as much as possible into the NDK is to port a program written in C or C++ to Android with as little effort as possible, but the environment is so different that the idea is just completely stupid most of the time (not to mention the user interface changes), more often than not it'd be better to just rewrite it from scratch (on that note, how does SDL for Android work?).
Also I heard that the speed difference between NDK and Java code really isn't very noticeable (if at all) because the Java code gets recompiled to native instructions anyway (it isn't interpreted), so I'm not sure if that could really be considered an advantage. I suppose NDK still wins if you really don't like Java, though =P
[quote name='Sik_the_hedgehog' timestamp='1354770459' post='5007639']
Also I heard that the speed difference between NDK and Java code really isn't very noticeable (if at all) because the Java code gets recompiled to native instructions anyway (it isn't interpreted), so I'm not sure if that could really be considered an advantage. I suppose NDK still wins if you really don't like Java, though =P
[/quote]
I wrote a very simple space shooter and got performance problems as soon as there were like 30 ships moving around at once, than I wrote the same again in native code and suddenly could manage 10 times more ships without doing any structural changes to the code.
That was on api 8 though and I have heared that dalvik became faster since then and that FloatBuffers have been fixed (there was a problem that wrapping a floatbuffer around a float array would call floatBuffer.put on every element instead of doing something smart).
There were also some functions missing so one could not write efficient code and had to use JNI wrappers anyway.
In my opinion the google guys are a little too fond of their dalvik vm. In practice native code is a lot faster and should be prefered if there are even remotely computationally expensive tasks to do.
Also will give you more battery life.
I have written a windows/linux framework for developing and debugging, so I don't have to mess with eclipse/android can just copy the files for final release.
I did some work in this area; I don't think there would be major problems. The annoyance is that it's not just a single line of Java you need to write -- basically any event you actually want to use (screen touches, rotations, anything like that) requires a thunk to pass it into your NDK. On the plus side, once done, done.
You'll also need to think about whether you'll need to leave C++ and go back to Java to do things (to access other features on the phone). If you want to write something that uses screen taps and draws things, the work is pretty simple. If you want to start talking to servers, do GPS or use the camera or things like that then it gets complicated fast.
You can do this transition into C++ at any layer BTW -- you could do game logic in Java and the rendering in C++. It's just a call into a shared object -- a DLL.
Why did I do it? Simply because I'm more productive in C++ because I'm more familiar with it. If you're starting from scratch, you may be better off choosing the path of lesser resistance and working in Java.
Author
In my opinion the google guys are a little too fond of their dalvik vmAndroid was meant to run on several different architectures seamlessly. It may well be most popular on arm but then you get the issue of ARMv6 and ARMv7 and then on ARMv6 in particular issues about whether or not the CPU has a hardware FPU or not. Then there are a few devices that run on MIPS rather than arm (particularly in china) and a few x86. I think that is the perfect time to be using a VM rather than native code, although it does seem that they give options for compiling separate binaries for each platform.
Anyway, seems to be alot of useful insight on the subject in this thread.
A decision made to support another bad decision is still a bad decision. Saying that 'they meant to do that' doesn't make it any less of a bad decision.
They decided on chaos instead of order. And chaos is what they got. To the point where you can't even write a simple example app and expect it to work across the board. That decision has hurt app developers, middleware developers, and even more so consumers who have to come home with their new devices and realize that their expensive apps either aren't compatible or don't work properly anymore.
And then now that are trying to reign in that chaos a bit with standards to follow, and a official android distro to work off of, the ones causing all the chaos are laughing at them and continuing on with their chaos.
They decided on chaos instead of order. And chaos is what they got. To the point where you can't even write a simple example app and expect it to work across the board. That decision has hurt app developers, middleware developers, and even more so consumers who have to come home with their new devices and realize that their expensive apps either aren't compatible or don't work properly anymore.
And then now that are trying to reign in that chaos a bit with standards to follow, and a official android distro to work off of, the ones causing all the chaos are laughing at them and continuing on with their chaos.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
