Another Android native code debugging link that you might find of use...:
http://pdk.android.com/online-pdk/guide/debugging_native.html
Monday, 25 January 2010
Sunday, 24 January 2010
vim - how to force .cpp files to have Objective-C syntax highlighting
This one has bugged me for a while - how to make vim and MacVim display .cpp files with full Objective-C++ syntax highlighting.
This is actually really easy to do; I can't believe it took me so long to figure out! Especially as I try to avoid using .m or .mm files in my projects, and almost exclusively use .cpp source files in all that I do to make my cross-platform work easier...
Anyways: all you have to do, is put these three lines in ~/.vim/filetype.vim (you'll almost certainly first have to create the .vim folder under your home directory...)
Sorted! Whenever you use the built-in vim, or MacVim, to edit a .cpp/.c/.h file, you'll see any Objective-C code in your editor displayed with nice syntax highlighting; your C++ code will also look lovely too!
This is actually really easy to do; I can't believe it took me so long to figure out! Especially as I try to avoid using .m or .mm files in my projects, and almost exclusively use .cpp source files in all that I do to make my cross-platform work easier...
Anyways: all you have to do, is put these three lines in ~/.vim/filetype.vim (you'll almost certainly first have to create the .vim folder under your home directory...)
au BufNewFile,BufRead *.cpp set filetype=objcpp
au BufNewFile,BufRead *.h set filetype=objcpp
au BufNewFile,BufRead *.c set filetype=objcpp
Sorted! Whenever you use the built-in vim, or MacVim, to edit a .cpp/.c/.h file, you'll see any Objective-C code in your editor displayed with nice syntax highlighting; your C++ code will also look lovely too!
Monday, 18 January 2010
Mixtikl update for iPhone coming soon - and Liptikl!
Tim and I both had a good break over Christmas; I think we both earned it after the long, hard push to releasing Mixtikl 2!
Now that we're refreshed, we've been busy working on an update to Mixtikl, which tidies-up various loose ends and generally makes it easier to get into! We're aiming to release this in a few weeks.
We've also been working on an iPhone version of Liptikl, which is fun and easy to use, so we hope to release that at some point after first releasing the Mixtikl update.
For those who are interested in the technicalities of such things things, most of the primary development for Mixtikl is done under Xcode on the Mac, targeting the iPhone version. Because Mixtikl is 95% cross-platform, I actually have the option to work under either Windows (with Visual Studio) or Mac OS (with Xcode). Despite Visual Studio being hugely more powerful than Xcode (with a far nicer editor model, debugger etc. etc....), I find myself working mainly in Xcode. Why? Simply because Mac OS is a great deal faster than Windows for running all my development scripts. Xcode is a lot less nice to use than Visual Studio, but overall I'm faster on the Mac because Mac OS mainly because shell scripting runs so much quicker...! Because I use the same editor on both platforms (vim ...) I can move easily between the two whenever I need to. I must say however, that if cygwin scripting were a lot faster under Windows, then I'd be back to Windows. :)
Now that we're refreshed, we've been busy working on an update to Mixtikl, which tidies-up various loose ends and generally makes it easier to get into! We're aiming to release this in a few weeks.
We've also been working on an iPhone version of Liptikl, which is fun and easy to use, so we hope to release that at some point after first releasing the Mixtikl update.
For those who are interested in the technicalities of such things things, most of the primary development for Mixtikl is done under Xcode on the Mac, targeting the iPhone version. Because Mixtikl is 95% cross-platform, I actually have the option to work under either Windows (with Visual Studio) or Mac OS (with Xcode). Despite Visual Studio being hugely more powerful than Xcode (with a far nicer editor model, debugger etc. etc....), I find myself working mainly in Xcode. Why? Simply because Mac OS is a great deal faster than Windows for running all my development scripts. Xcode is a lot less nice to use than Visual Studio, but overall I'm faster on the Mac because Mac OS mainly because shell scripting runs so much quicker...! Because I use the same editor on both platforms (vim ...) I can move easily between the two whenever I need to. I must say however, that if cygwin scripting were a lot faster under Windows, then I'd be back to Windows. :)
Android - NPAPI plugin - how to make a callback from the main thread
If you happen to be writing a browser plug-in using NPAPI/JNI for Android's built-in browser, and are doing some processing in the native side in C/C++ in a separate Posix thread; and want to get a callback into your native code from the main browser thread; you want to use this NPAPI function...!
void NPN_PluginThreadAsyncCall(NPP instance,
void (*func)(void *),
void *userData);
You can find some documentation on this if you search your Android source code for the file called npapi.cpp.
Basically, you call the above function from your native thread to register a callback function; the call to NPN_PluginThreadAsyncCall returns immediately. At some future point in the very near future, the browser will call your supplied function from the main browser thread, supplying the userData that you provided when you registered your callback.
Incidentally, if your Plug-in method is passed a JavaScript object that you're going to need to do something with at a later point (e.g. if you want to issue a deferred callback, through use of NPN_PluginThreadAsyncCall), you need to remember to keep your JavaScript object alive until you're ready to use it, by calling:
NPObject *NPN_RetainObject(NPObject *npobj);
Once you've used the object, remember to release it with:
void NPN_ReleaseObject(NPObject *npobj);
Hopefully that'll be of use to some people!
void NPN_PluginThreadAsyncCall(NPP instance,
void (*func)(void *),
void *userData);
You can find some documentation on this if you search your Android source code for the file called npapi.cpp.
Basically, you call the above function from your native thread to register a callback function; the call to NPN_PluginThreadAsyncCall returns immediately. At some future point in the very near future, the browser will call your supplied function from the main browser thread, supplying the userData that you provided when you registered your callback.
Incidentally, if your Plug-in method is passed a JavaScript object that you're going to need to do something with at a later point (e.g. if you want to issue a deferred callback, through use of NPN_PluginThreadAsyncCall), you need to remember to keep your JavaScript object alive until you're ready to use it, by calling:
NPObject *NPN_RetainObject(NPObject *npobj);
Once you've used the object, remember to release it with:
void NPN_ReleaseObject(NPObject *npobj);
Hopefully that'll be of use to some people!
Friday, 15 January 2010
Android - how to obfuscate your apps
If you're wondering how to obfuscate your Android apps, you should look at http://proguard.sourceforge.net/ ...!
Monday, 4 January 2010
Android debugging with gdb?
For those of you that have been struggling to find information on how to debug under Android with GDB (for example, if you've been writing JNI code for Android...), this looks like a useful link to follow!
http://pdk.android.com/online-pdk/guide/debugging_gdb.html
Pete
http://pdk.android.com/online-pdk/guide/debugging_gdb.html
Pete
Subscribe to:
Posts (Atom)
