Android++: Native development and debugging extension for Visual Studio
android-plus-plus.com
Android++: Native development and debugging extension for Visual Studio
1–10 of 55 posts
Re: Android++: Native development and debugging extension for Visual Studio
#2Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.
Re: Android++: Native development and debugging extension for Visual Studio
#3Interesting - but to quote from the Android developer website: Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.
In general, you should only use the NDK if it is essential
to your app—never because you simply prefer to program in C/C++.
Which continues to annoy me even now.I recall the fireside android team chat one time (two years ago?) that went something like:
Question: So what about the NDK? You can't beat native for performance...
Android team member: *laughs* ... well, you can't beat java for portability
Comment from audience: Unless you want to use your code on another platform...
That's certainly how I feel about it.Re: Android++: Native development and debugging extension for Visual Studio
#4Interesting - but to quote from the Android developer website: Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.
I don't have any stats on that, but you can check out the following games made using the open-source C++ framework Cocos2d-x that the developers asked to be featured:
Re: Android++: Native development and debugging extension for Visual Studio
#5Interesting - but to quote from the Android developer website: Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.
Re: Android++: Native development and debugging extension for Visual Studio
#6Interesting - but to quote from the Android developer website: Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.
Personally, I'd like to get some reuse out of my iOS code. I'd do more C++ if I knew that I could reuse it. Of course, Objective C could actually be portable too.
Re: Android++: Native development and debugging extension for Visual Studio
#7Interesting - but to quote from the Android developer website: Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.
The most likely reason to use the NDK is when you are using existing C(++) code, for instance from your iOS or desktop versions of your app. For me the biggest advantage is building the app for Win64, using rich tools and a high power testing platform and just run a different make and now I have an Android app.
Re: Android++: Native development and debugging extension for Visual Studio
#8Interesting - but to quote from the Android developer website: Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.
What is like working with the NDK? C++ is the one language that can work on both iOS and Android (and Windows phone?) Personally, I'd like to get some reuse out of my iOS code. I'd do more C++ if I knew that I could reuse it. Of course, Objective C could actually be portable too.
I used to complain about certain niggles in Xcode, but having used ADT, I shall never complain again. Comparatively, using Xcode is a joy.
Re: Android++: Native development and debugging extension for Visual Studio
#9Obviously, there is the case where the code shop may have other project assets tied into the VS ecology-dev system but is that the only case?
Re: Android++: Native development and debugging extension for Visual Studio
#10Interesting - but to quote from the Android developer website: Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.
They also say: In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++. Which continues to annoy me even now. I recall the fireside android team chat one time (two years ago?) that went something like: Question: So what about the NDK? You can't beat native for performance... Android team member: *laughs* ... well, you can't beat java for portability C…