Category Archives: programming

Developing Objective-C apps for Android using Mac OS X

7 Replies

** Unpaid mini-ad (Oct 31st 2012): **
Check out Yeecco’s StellaSDK. From my experiments with Stella and from interaction with the company, they may be a good choice if you need an easy-to-use solution right now, with as little work as possible. The PDF has not been maintained, and I have not experimented with improving the procedure; it may be good for improving the understanding of the problems, but if you need something that’ll work right now, talk to Yeecco — especially if you want to easily port a Cocos2d game.
** End of mini-ad **

** Unpaid mini-ad #2 (May 27th 2013): **
Another company that provides an SDK for easier porting of iOS apps to Android is Apportable. They have a free starter SDK (check out their plans) — and that’s the extent of my familiarity with their product, for now 🙂
** End of mini ad #2 **

** Clang in Android NDK! (Mar 20th 2013): **
Android NDK is now shipping with Clang. Additionally, there’s also some work on getting GNUstep Base to build for Android. Sweet! I’ll update this post with a link to additional information once this is proven to work okay.

** Rebuilding GCC (Jan 8th 2013): **
Instead of downloading prebuilt GCC, try rebuilding it.
– Instructions blogpost (with various reference links)
– Great presentation by Jackie Gleason
** End of rebuilding GCC **

I’m no fan of Java, and in fact, I’m not a fan of Android. When I originally heard Google is working on a Linux phone, I rejoiced. When I heard that Java would be the base of the userland, and that no existing program for Linux would be directly supported, my heart sank. In the meantime I became a big fan of Objective-C, Cocoa, Cocoa Touch, Mac, and all related technologies and projects.

So, I want to keep working in Objective-C. I sat down and studied my options. We have the Android SDK, we have the Android NDK, and a third party offering called Android NDK GCC 4.2.1 with Objective-C support.

SMALL UPDATE, May 8th 2012: I have not tested this, but here’s the CrystaX .NET Improved Android NDK. Thanks to jeffamaphone for pointing it out. I did not test it, but r7 ships with GCC 4.6+.

Studying all this takes a while. Well, more than a while. I spent a day or two wrapping my head around all this, reading Android documentation. All this not counting stuff that I read, heard and discussed in previous months on this subject.

Android SDK is documented well enough, as long as you stick to Java. Android NDK is not particularly well documented, but solidly enough. Playing with the Objective-C is however a bit more complex, especially since Android NDK by itself does not come with Objective-C support turned on. Authors of the add-on compiler for Objective-C did not publicly document its proper use at all. Its use is nearly ungoogleable.

Since I’d hate to see you, my little lemon drops, spend as much time as I did on studying all this, here is something that will help you understand the complexities of the design of NDK, and how to combine all this with the Objective-C compiler.

Proficiency with GNU Make and Objective-C is highly recommended.
Proficiency with Java and Android is not required (I have none).

Not much in this article depends on Mac OS X apart from the paths, and the fact that there is no prebuilt Objective-C compiler for platforms other than Mac OS X. Parts that are about SDK and NDK should cleanly apply to Linux version of the Android SDK and NDK. It probably cannot easily apply to Windows.

Update on December 7, 2011: I just learned about a great presentation by Jackie Gleason (@LifeIsTooShort) on the same subject: Adding Objective-C Support to the Android NDK

If you wish to do so, you can donate me via PayPal for writing this PDF. Definitely not mandatory, though!

Donation choice





You can also send me other amounts directly via PayPal to address: ivucica@gmail.com

Avoiding memory leak in OpenAL and crash in OpenAL for Mac

Leave a reply

UPDATE: We’re still seeing the crash on Mac. Procedure described does fix the memory leak, though.

UPDATE 2: Crash on Mac is caused by what appears to be a bug in Apple’s code relating to queueing commands for execution on dedicated audio thread, and mutex lock breaking down. Since mutex lock seems to stop working, it’s only natural that a threading-related crash occurs.

When calling alSourceStop(), you might forget to unbind a buffer from the source. Did you unbind it? 

alSourcei(this->sourceId, AL_BUFFER, AL_NONE);

If you get a crash on Mac with call stack containing OALSource::Play() and/or ending with OALSource::PrepBufferQueueForPlayback(), this is most probably a good fix. Looks like OpenAL on Mac might have a race condition somewhere unless you do this.

See difference between revision 293 and 294 in libxal, in file audiosystems/OpenAL/OpenAL_Player.cpp.

Using hggit with existing Mercurial projects

2 Replies

I want to use hggit. Not because I like git, but because Xcode 4 uses git. So I need a two way bridge between hg and git, which hggit provides.

1. Install dulwich:

sudo easy_install dulwich

Have multiple Pythons installed? Make sure you use correct easy_install, for example:

sudo /usr/bin/easy_install2.6 dulwich

2. Get hggit, either with git or hg (guess which one I prefer):

hg clone http://bitbucket.org/durin42/hg-git hggit

3. Edit your ~/.hgrc; add the hggit and bookmarks extensions:

[extensions]
. . .
bookmarks=
hggit=/Users/someone/projects/hggit/hggit/

4. In your Mercurial repository, punch this in:

hg bookmark master -r default
hg gexport

and voilà! You have a .git repository.

5. To pull git changesets (commits) back into hg, it should require just:

hg gimport

I didn’t yet get here.

Xcode 4 simply refuses to work with git repositories created from Mercurial. It recognizes the branches, but not the log itself. No idea why yet. Ah well. 🙂

Update: Xcode 4 is sensitive to repositories being “bare”, whatever that means for Git. (Apparently that is a locally created, non-cloned Git repository without a “remote”.) Edit .git/config, and change “bare = true” to “bare = false”. This allows you to see the history.

But don’t do that. There appear to be other incompatibilities that I could not fix. For example, all files are marked as “D-eleted”. Also, setting bare to false will make the following steps fail. So what you really want to do is:

cd ..
git clone MyProject MyProjectGIT
# now mess with the project in MyProjectGIT
git commit -m "Whatever"
git push
cd ..
cd MyProject
hg gimport

(First few commands are run through Xcode 4 GUI, of course.)

Don’t forget that your git username and email is unconfigured. (Absurdly, I could not find GUI in Xcode 4 to edit this!) Terminal back to the rescue again.

git config --global user.name "Your Name"
git config --global user.email your.email@example.com

Finding memory corruption of a C++ class member variable using GDB

Leave a reply

Source: Giant Water Bug by FreeLearning

Today I managed to catch a nasty bug of memory corruption of a C++ class member variable. This was related to a C cast being used in place of dynamic_cast. But more interesting is the way I caught the bug.

Luckily, the class that we saw get corrupted was the label, the corruption was very visible (a bool variable that should be permanently true was set to false) and the instance that we saw get corrupted was the game’s loading screen. Setting the breakpoint was easy, especially since I could easily just set it inside the constructor: loading screen contained the very first label instance that was created in the game.

Now, we were lucky that the memory that was corrupted was in our code. We were also very lucky to be able to pinpoint what gets corrupted before it gets corrupted.

Catching where it got corrupted could be a bit trickier if it weren’t for GDB.

So once the code stopped in the constructor, we issued this command manually to GDB:

watch -location mTextFormatted

This creates a hardware watchpoint that breaks execution when the location is read. You can alternatively use this syntax if you want to watch a specific memory location:

watch *((int*)0xdeadbeef

(substitute with correct C data type). Alternatively, there is rwatch and awatch. Read more on Stack Overflow

Xcode turned out to be very nice here. When the watchpoint is hit, it shows a sheet that alerts you pretty strongly that it was hit. Read more on Stack Overflow

Helpful post? Don’t forget to comment 🙂

libjingle with your own signaling or your own XMPP library

Leave a reply

Just sharing the link here, since I was googling for far too long to dig it out.

How To Use STUN In Applications

It’s surprising this is found as a part of the manual for Maemo, the fantastic OS that moved in the right direction, but was practically abandoned by Nokia.

NOTE: This is apparently a guide for the outdated libjingle 0.3.0. I can’t find any guide for the new version of libjingle.

What I'm missing in Xcode4?

5 Replies

I’m a big fan of Xcode3. Xcode4 is a step in the right direction for me, though. Not so much as it would be when I started with Mac and iOS development, but still, it’s ok.

However, there are large omissions and important bugs that are heavily influencing my productivity.

  1. Removed Right-click, Find In Documentation. (Update on April 1st 2011, 16:42 CET: Alt+left-click is a replacement for this.)
  2. Removed Command+shift+up to switch between header and source. Assistant views are not a replacement since I work on Macbook, which doesn’t have all that much screen real-estate, especially, when you have the File Navigator on the left. (Update on July 12th 2011, 16:21 CET: Use Ctrl+cmd+up, or three-fingers-down-to-up touchpad gesture.)
  3. No ability opening multiple Get Info dialogs on the screen for different project Targets. In fact, Get Info was removed and replaced with (admittedly superior) way of editing build settings.
  4. When autocomplete lists tons of options, Page-down (Fn+Down) does not work. That’s right, you can’t scroll over a screenful of symbols at a time.
  5. Command+shift+b has been reassigned to … get this … Build & Analyze. Ok, that needed a shortcut (maybe), but Command+shift+b used to be the shortcut to open “build progress” output dialog.
  6. Build progress is now assigned a navigator; that is, hit Command+7 to get it. However… the Editor view does not automatically focus on latest build progress and.
  7. Closely related to previous item: there is no obvious shortcut for switching focus between Editor and Navigator. I really want to quickly choose a file, to quickly choose a build log, and to quickly choose an issue from the list. While this is not something that used to exist in Xcode3 (or at least I couldn’t find it) it is still something that would be highly useful. Open Quickly – Command+Shift+O – is not a substitute.
  8. I really miss the old “Groups & Files” view. Not a big deal, but having that as an alternative to the new Navigators view would be excellent.
  9. While autocomplete got even better, Command+doubleclick is extremely dumbed down and cannot guess that in [[NSString alloc] initWithString:@"something"]; attempting to find initWithString in header probably means NSString‘s -initWithString:, right? Well, if you have another initWithString: in another class, Xcode4 will ask you which one you refer to (despite [NSString alloc] being declared to return NSString, thus there being no dillema whose -initWithString: needs to be used).
  10. Despite introducing tabs, they are next to useless: hard to open, and with no obvious keyboard shortcuts to switch tabs or close tabs.
  11. added March 18 2011, 14:12 Oh. Right-click, Add Files to “projectname.xcodeproj” does not take into account parent group path anymore. That means, despite configuring that pesky Window Systems/iOS group to point to path “relative to group” and pointing to “windowsystem/iOS” filesystem folder, Add Files dialog will no longer default to that folder. Meaning I nevertheless have to dig around the filesystem to find the relevant files.
  12. added March 18 2011, 14:40 You can no longer easily access full path to a currently open file by right-clicking on the titlebar. This is important in case error log refers to system-wide installed header file, which you go and happily change without affecting header file that you should be changing — the one in a subproject.

These are just some omissions that significantly reduce my productivity compared to Xcode3. I sincerely hope they will be patched by Apple, otherwise I’ll simply have to do without them. There’s no other way: iOS devs (and to some extent Mac devs) are hostages of the latest SDK which ships only with the latest IDE.