As many Android developers know the Android NDK is used to cross-compile native (C/C++) code to run in Android programs. Unfortunately, because it uses JNI we’re limited to a C-style call interface. Tools like SWIG can be used to automatically generate wrappers for existing code including C++ classes. In this post I’ll provide an introduction to native backed objects in Java, which are objects whose implementation/resources are primarily implemented in a native language. I won’t be using SWIG since it might muddle everything a bit because of what it takes to get it to wrap standard library classes on the NDK.
What are we trying to accomplish? Our goal here is to have the ability to write Java code that operates on normal Java objects, but underneath all of the “magic” is happening in C/C++ land. There are two main use cases for this: speed-ups from using faster native code for memory intensive/processor intensive operations, and for leveraging existing code bases into a new Android project. Especially in the second case, native backed objects give you the ability to write UI code for a new Android project that uses your existing C++ classes as the main base of functionality; we simply create “wrapper” classes that can be used in Java land the same way you’ve been using them in C++ land, but now have the added benefit of being directly inter-operable with the Android framework. Continue reading “An introduction to native backed objects with the Android NDK”
At work we’ve been developing new Android hardware, and as such I’ve been porting a lot of our existing C/C++ code to Android using the NDK, a collection of GNU build tools (gcc, objcopy, etc.) and associated scripts to aid the development of native C/C++ code on Android. One of our projects is nearly 1000 source files, and therefore can be a bit of a headache to debug. For a while I’ve had a problem where this project would crash when built in release mode, but work fine when built for debug. Unable to spend the time to figure out what was going on, I’d simply been using the debug build of the code. However recently the performance implications were too great and I needed to get to the bottom of what was going on. Interestingly enough, the issue wasn’t uninitialized memory (as is usually the case with debug/release inconsistencies) but rather a bug in GCC 4.4.3’s optimization of memcpy. Continue reading “Over-aggressive GCC optimization can cause SIGBUS crash when using memcpy with the Android NDK”
This comes from a talk I’m giving at Penguicon 2012. The talk in general is about weight loss and getting healthy but part of it involves doing some predictive modeling of future weights based on calorie counting.
Consider the question “if I eat X number of calories a day, will I gain or lose weight?”. It’s a supremely practical question but without doing some research it isn’t immediately apparent how to answer this. The best place to start is one of the formulas for calculating basal metabolic rate. The obligatory Wikipedia link provides some more background but in short it gives us a formula for the “baseline” number of calories our body needs. Mifflin-St. Jeor is considered by many  to be the most accurate. It is of the form:
In this formula, m is mass in kilograms, h is height in centimeters, a is age in years, and s is a gender offset which is either +5 for men or -161 for women. This gives us P, our basal metabolic rate in calories. An interesting thing about BMR is that it’s a measure of your caloric needs at more or less complete rest. A normal person’s caloric needs to maintain weight will usually be strictly greater than their BMR. Because of this, P is usually scaled by an “activity factor” which factors in daily life. This can range from ~1.2 for someone with a desk job who gets no exercise to ~1.9 for someone who engages in some serious workouts. Now that we know our caloric needs, how can use this to model where our weight will be in the future? Continue reading “Modeling weight loss with differential equations”