Android Thoughts - Opinions, News, Advice & Reviews on Android Devices

Be sure to register in our forums! Share your opinions, help others, and enter our contests.


Apple Thoughts

Loading feed...

Laptop Thoughts

Loading feed...

Digital Home Thoughts

Loading feed...




Go Back   Thoughts Media Forums > ANDROID THOUGHTS > Android Articles, Resources & Developer

Reply
 
Thread Tools Display Modes
  #1  
Old 03-04-2011, 03:50 AM
Yongki C. AndykaJong
Neophyte
Join Date: Mar 2011
Posts: 1
Default NDK - Unicode, w_char, and other useful information

Coming from Windows Mobile native programming, the first thing that I checked before jumping into Android is, naturally, NDK. Fast forward to today, after many months of playing with Android NDK; I can say, now, it is, indeed, fun to work with. I am trying to compile a small list of pitfalls that I believe you should pay attention to if you want to try this digital journey:

1. Unicode
UTF16 was not supported for NDK development targeting platform below Gingerbread. Android JString is UTF8, you need to adjust every string if you are using Unicode UTF16 in your C++ source. My solution is to wrap all GetStringUTFChars with a UTF8 /UTF16 converter.

2. w_char
w_char is 4 bytes long. So any w_char * will give you garbage if you are lucky and crash your program if you do not change it. So walk the bytes to get your w_char * exact content.


3. Heap memory
There is no heap memory limit for a native application but don't abuse it. Java environment of Android 1.6 has 16MB limit, Android 2.x with HDPI has about 24 MB and Honeycomb has 48 MB. If you use too much of heap memory, Android starts to kill background processes and your user won't be happy: after using your application the system will be sluggish as the Android OS needs to start almost everything all over again. My solution is to make a call to Android Dalvik for functions with heap memory calls and let the OS defines the limit. The downside of this is that once memory usage reaches below the threshold of the available memory for an application, Android will kill your application without any warning. Well, under such a limitation, this should be a better way out than the other evil trap. HoneyComb is, indeed, fantastic. It comes with 48 MB heap memory limit, there is a lot of porting we can do in native code. I am working on some applications targeting HoneyComb using much of its more advanced features. Just to remind anyone who might want to scream fragmentation, get an ice cream to cool down; it is not fragmentation, it calls taking advantage of the horsepower available, hit the gas pedal, and zoom! or xoom

4. NDK tools
If you use Cygwin, download the latest version, it saves you hours in compilation time! Up to previous version of NDK tools, compiling C++ sources with many sub folders take hours (Windows 7, I720, 6G RAM), making debugging next to impossible for a big project.

5. Clean up your JNI local reference call rigorously
There is a limit to local references in JNI, you get this error: "ReferenceTable overflow (max=512)..." if you open too many local references. You need to clean it up in every local reference call, it piles up pretty fast. Don't try making it a global reference, as many suggestions you might read throughout the Internet, it only makes the situation even worse in some case, so just do it, clean it up, you are in C++, right?
Your application will crash once reference table overflows.

The above issues are some of the major issues I believe most native developer will face. Native programming for Android is not that hard once you have overcome these issues, it is better than Windows Mobile in many ways.

Last edited by Yongki C. AndykaJong; 03-04-2011 at 08:04 AM..
 
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 01:27 AM.