Objc-runtime + Foundation framework running on android!

cocos2d for iPhone » Programming » iPhone SDK / UIKit / Objective-C / Xcode

Objc-runtime + Foundation framework running on android!

(70 posts) (36 voices)

Started 2 months ago by jordo
Latest reply from daimonio

Tags:

After a few long days, I've managed to compile the objective-c runtime on android as well an implementation of the Foundation framework. The motivation behind this effort is primarily to investigate the possibility of using cocos2d-iphone on android.

You may be familiar with our game Super Stickman Golf. For the iphone version we used cocos2d-iphone. When we made the decision to port it to android, we used cocos2d-x. Great that the api is pretty much the same, but not so great that it's c++... Most of the work was literally converting obj-c to c++... I do not want to do that again, and to be honest I prefer obj-c over c++ big time.

I wanted to share a code snippet I've managed to get running on android and how I accomplished it. As well as get some feedback from some of the core cocos2d developers (riq) on the possibility of continuing this effort to get a version of cocos2d-iphone running on android...

The following is a code snippet I have working and running on android NDK:

#import <jni.h>
#import <string.h>
#import <android/log.h>
#import <Foundation/Foundation.h>
#import <Foundation/NSString_placeholder.h>
#import <Foundation/TestObjClass3.h>
#import <TestLibrary/TestObjClass2.h>

#import <objc/NXConstStr.h>

#define DEBUG_TAG "NDKSetupActivity"

@interface TestNewObj : NSObject {

	int intProp;

}

@property (assign) int intProp;

- (void)testPrintMethod:(const char*)string;
- (void)testPrintMethodNSString:(NSString*)string;
+ (void)testStaticPrintMethod:(const char*)string;
@end

@implementation TestNewObj

@synthesize intProp;

- (void)testPrintMethod:(const char*)string {
    __android_log_print(ANDROID_LOG_DEBUG, DEBUG_TAG, "NDK: %s", string);
}

+ (void)testStaticPrintMethod:(const char*)string {
    __android_log_print(ANDROID_LOG_DEBUG, DEBUG_TAG, "NDK: %s", string);
}

- (void)testPrintMethodNSString:(NSString*)string {
	__android_log_print(ANDROID_LOG_DEBUG, DEBUG_TAG, "NDK: %s", [string UTF8String]);
}

@end

extern "C"
{

void Java_com_noodlecake_NDKSetup_NDKSetupActivity_printLog(JNIEnv * env, jobject thiz, jstring logString) {
		jboolean isCopy;

		const char * szLogString = (env)->GetStringUTFChars(logString, &isCopy); // get a java string

		// Lets print a string from java...
		[TestNewObj testStaticPrintMethod:szLogString];

		// Lets print a const char*
		[TestNewObj testStaticPrintMethod:"Starting tests..."];

		// Lets create some new objective-c objects
		TestNewObj* test = [[TestNewObj alloc] init];\
		__android_log_print(ANDROID_LOG_DEBUG, DEBUG_TAG, "NDK: Creating object: %p", test);

		TestNewObj* test2 = [[TestNewObj alloc] init];
		__android_log_print(ANDROID_LOG_DEBUG, DEBUG_TAG, "NDK: Creating object: %p", test2);

		TestNewObj* test3 = [[TestNewObj alloc] init];
		__android_log_print(ANDROID_LOG_DEBUG, DEBUG_TAG, "NDK: Creating object: %p", test3);

		//Lets test the object's property
		__android_log_print(ANDROID_LOG_DEBUG, DEBUG_TAG, "NDK: Setting object int property to: %i", 675);
		test.intProp = 675;
		__android_log_print(ANDROID_LOG_DEBUG, DEBUG_TAG, "NDK: Object property is: %i", test.intProp);

		// Lets create a mutable array and a mutable dictionary
		NSMutableArray* arr = [[NSMutableArray arrayWithCapacity:20] retain];
		NSMutableDictionary* dict = [[NSMutableDictionary dictionaryWithCapacity:20] retain];

		// Lets add some objects to the array
		[arr addObject:test];
		[arr addObject:test2];
		[arr addObject:test3];

 		// Lets iterate over the array (NOTE* gcc-4.6.1 can't use FastEnumeration in objetive-c++ files (.mm)
		for(int i =0; i < [arr count]; i++) {
			[TestNewObj testStaticPrintMethod:"Loop!"];

			// Lets grab the object
			TestNewObj* currentObj = (TestNewObj*)[arr objectAtIndex:i];

			// Lets create a NSString key and add this object to the mutable dictionary
			char tmp2[] = {'a', 'b', 'c', 'd'};
			NSString_placeholder* nss = [[NSString_placeholder alloc] initWithBytes:tmp2 length:i+1 encoding:NSUTF8StringEncoding];

			[dict setObject:currentObj forKey:nss];
			__android_log_print(ANDROID_LOG_DEBUG, DEBUG_TAG, "NDK: Inserting object: %p for key: %s", currentObj, [nss UTF8String]);
		}

		// Lets iterate over the dictionary and check the contents..
		NSArray* keys = [dict allKeys];
		for(int i =0; i < [keys count]; i++) {
			NSString* keyString = (NSString*)[keys objectAtIndex:i];
			TestNewObj* currentObj = (TestNewObj*)[dict objectForKey:keyString];
			__android_log_print(ANDROID_LOG_DEBUG, DEBUG_TAG, "NDK: Retrieved object: %p for key: %s", currentObj, [keyString UTF8String]);
		}

		[TestNewObj testStaticPrintMethod:"Ending Tests..."];

		(env)->ReleaseStringUTFChars(logString, szLogString);  // release the java string
	}
}

The following is the output from the code snippet from android LogCat:

12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Starting tests...
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Creating object: 0x339880
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Creating object: 0x3372b0
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Creating object: 0x336dc0
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Setting object int property to: 675
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Object property is: 675
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Loop!
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Inserting object: 0x339880 for key: a
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Loop!
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Inserting object: 0x3372b0 for key: ab
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Loop!
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Inserting object: 0x336dc0 for key: abc
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Retrieved object: 0x3372b0 for key: ab
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Retrieved object: 0x339880 for key: a
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Retrieved object: 0x336dc0 for key: abc
12-08 09:49:12.371: DEBUG/NDKSetupActivity(3166): NDK: Ending Tests...

First I'll explain how the above code was actually compiled:
* GCC 4.6+ has built in support for objective-c and objective-c++ (gnustep-runtime). I've updated and patched the default gcc that comes with the android ndk to gcc 4.6.1. (https://docs.google.com/present/view?id=dfj692w3_351gq89x8fv&pli=1)
* I've modified the android make system to recognize .m and .mm as valid source files, android's gcc can now compile them
* GCC 4.6+ gives us an objective-c runtime, but no Foundation framework. With a lot of hacking and patching, I managed to get the cocoatron Foundation implementation compiling and linking. (http://cocotron.org/)

Some notes about the above code snippet and output:
* The JNI function is called from the java-side.
* My custom objc class inherits from NSObject.
* NSMutableArray and NSDictionary seem to be working properly.
* GCC 4.6+ doesn't have support for FastEnumeration in objc++ files (.mm). Support is only in (.m) files.
* GCC 4.6+ doesn't have built-in support for blocks.

What I'm looking for:
* Thoughts and feedback.
* What internal parts of cocos2d-iphone depend on frameworks other than Foundation? I know there's some CoreGraphics and some UIKit dependancies, but I suspect we can potentially use the cocos2d-x implementations for some of those pieces... Example, I *believe* the cocos2d-iphone texture loading uses UIImage. We could potentially use the cocos2d-x version instead of relying on UIImage.
* I'm also pretty sure there are implementations of some of the CoreGraphics stuff. I think cocotron has implementations of all the matrix transformations, etc.

I think with some effort I can get cocos2d-iphone into a state where it can be running on android. I will already be using this system to keep our game logic in objective-c for android and iphone platforms.

Posted 2 months ago #

jordo
Member

Some other things of note:

* The above snippets were compiled and running on ARM (HTC EVO). I suspect other archs wouldn't be a problem.
* cocotron uses the MIT license.

Posted 2 months ago #
riq
Key Master

Great!!!!

yes, UIKit is needed for some parts of the code, like touches and UIImage.
If we use the PVR format, (or libpng), then UIImage would not be needed.

I plan to replace UIImage from texture2d, with CGImage. But probably this change won't help you since it will still depend on CoreGraphics.

Posted 2 months ago #
jordo
Member

Yes your correct.

I'll need to take the Touch handler from cocos2d-x. (Touches are generated from java and passed through to their implementation of CCTouchHandler through JNI).

Yes. Cocos2d-x uses libjpg and libpng for texture loading. Most likely I would use their implementation of texture loading in CCTexture2D.

Posted 2 months ago #
clarus
Member

I'd love to see this happen. It would be great to have an easy path to Android (and Windows too).

Did you consider creating an Objective-C wrapper for cocos2d-x and using that along with cocotron? I'm not sure which approach would take less effort, but since cocos2d-x is already portable, it's a thought.

Posted 2 months ago #

jordo
Member

@clarus An obj-c wrapper around cocos2d-x would kinda defeat the point. The point being, I don't want to write c++. More-over cocos2d-x just doesn't 'feel' right. It's c++ but trying to be objective-c at the same time, and the reason cocos2d-x has to do that is to maintain API compatibility with cocos2d-iphone. I mean most of the Core classes, NSOjbect, NSDict, NSString, NSArray have all been implemented in c++. Along with an extensive list of macros to do objective-c things like properties and memory management... Example, here's typical header file for a custom CCLayer with a few properties:

#ifndef OVERLAYLAYER_H_
#define OVERLAYLAYER_H_

#include "cocos2d.h"
#include "Sprites/MyMenuItemSprite.h"
USING_NS_CC;

class OverlayLayer : public cocos2d::CCLayer
{
public:
	// Here's a difference. Method 'init' in cocos2d-x returns bool, instead of returning 'id' in cocos2d-iphone
	virtual bool init();
	virtual ~OverlayLayer(void);

	// implement the "static node()" method manually
	LAYER_NODE_FUNC(OverlayLayer);

	CC_PROPERTY_SYNTH(CCMutableArray<CCSprite *>*, powerupList, PowerupList)
	CC_PROPERTY_SYNTH(CCMutableArray<CCSprite *>*, powerupButtonList, PowerupButtonList)
	CC_PROPERTY_SYNTH(CCMutableArray<CCSprite *>*, hudStrokeList, HudStrokeList)

	virtual void onEnter();
	virtual void backButtonClicked(CCObject* pSender);
	void tickMe(ccTime dt );
	virtual void draw(void);

};

#endif /* OVERLAYLAYER_H_ */

There's no runtime support for this approach, and memory leak debugging is pretty hard. As they've used the objective-c memory management model. (CC_SAFE_RELEASE, CC_RETAIN, etc etc)

Posted 2 months ago #

bradparks
Member

sounds cool! and i have no clue if this'll be useful at all, but I remembered that someone ported some of UIKit to the Mac awhile back:

http://chameleonproject.org/

So it's probably still using Mac based APIs behind the scenes, but maybe it's closer to portable that way?

Posted 2 months ago #
clarus
Member

Got it. You might want to make this an opensource project--cocos2d-o or something like that. I think there are enough people interested that it could get a lot of support.

Posted 2 months ago #
Stepan Generalov
Moderator

That will be so FREAKING GREAT to have Objective-C Cocos2D-iPhone running on Android.
Soon on my fulltime job we will start new game, and it should support both Android & iOS.

@jordo Can you share you your fork of Cocotron & other stuf, that can help others to start playing with it?
I would like to contribute.

Posted 2 months ago #
slembcke
Administrator

I had been wondering how hard it would be to get an Obj-C runtime running on other platforms. Especially after Apple open sourced the Foundation code. The compiler support is certainly there, it's just missing the runtime. If your code doesn't heavily use classes outside of Foundation collection classes and such it should make it relatively easy to port things.

I sat on the fence about whether I sort of liked it or simply tolerated Obj-C for years. In the last few years with Obj-C 2.0 features like properties, automatic instance variables, ARC, etc. It's shaping up to be a pretty usable for developing games. I certainly wouldn't mind using it for making cross platform games instead of C++.

That's pretty awesome.

Posted 2 months ago #
DifferentSparks
Member

Oh man that's so cool.

Posted 2 months ago #
ksjogo
Member

Disliking C++ too, this sounds awesome.
I do not know Cocotron, but why can one not use the gnustep foundation? The GS seems to be more tested and used.

Posted 2 months ago #
jordo
Member

@Stepan Generalov - I will open source the project when it's ready for prime-time... Right now it's not even close to anything organized... Once I can actually get cocos2d-iphone compiling and running opengles1.1, I'll clean everything up and put it up somewhere..

jogo - Yeah. cocotron and gnustep foundation are what I've been working with. gnustep isn't really ready for cross compiling. (http://wiki.gnustep.org/index.php/Cross_Compiling) I've tried various attempts to get something working but gnustep uses its own make system which complicates things. Myself and another are trying to cross compile gnustep with our custom android toolchain, but changes need to be make to the gnustep make system for it to work. I'm on the gnustep mailing list, and we've started a thread about this, so yeah if I can get it working great... Theoretically whether the Foundation framework is cocotron or gnustep, we should be able to swap out implementations seamlessly.

Posted 2 months ago #
CJ
Moderator

I'd be happy to help. This is a great thing :)

Posted 2 months ago #
Panajev
Member

Awesome project :).

Posted 2 months ago #
hactar
Member

I think you'd get a lot of help and publicity with this, so keep us posted.

Posted 2 months ago #
Birkemose
Member

I agree - after having wasted to much time with Windows, C++, MFC, WDM, and whatever schemes Bill came up with to ruin my life - that ObjC is a much much better implementation of high level C.
I say that, even knowing that a dane invented C++. Just to illustrate how repentant I am.

But to get it running on ... that other Andruid thing?
I dont think so.

Unless Google's word for 2012 is, that they will officially support Obj-C, it is not going to happen.
No one at their rightful minds, would base anything on a hack, and while the undertow with cocos2d is strong, it certainly isn't strong enough to rock Google's boat.

Posted 2 months ago #
jordo
Member
@Birkemose - I'm not sure what you're talking about. It has nothing to do with Google supporting Obj-C. The default GCC that ships with the Android NDK is 4.4.3. It doesn't have Obj-C support. The latest GCC (4.6+) supports Obj-C 2.0 and has a built in runtime library (libobjc). You can read the obj-c support here: http://gcc.gnu.org/gcc-4.6/changes.html
```
From the GCC 4.6 changeset:

A new Objective-C 2.0 API, almost identical to the one implemented
by the Apple Objective-C runtime, has been implemented in the GNU
Objective-C runtime library. The new API hides the internals of most
runtime structures but provides a more extensive set of functions
to operate on them. It is much easier, for example, to create or
modify classes at runtime. The new API also makes it easier to port
software from Apple to GNU as almost no changes should be required.
```
Google provides you with all the tools and source to build your own toolchain... In fact they've made it dead simple. It was pretty trivial to get my android projects compiling with an android toolchain based on GCC 4.6 as opposed to 4.4.3. The tricky part is getting a Foundation framework to use. I mean, what good is an objective-c runtime if you don't have all those sweet NS* classes to work with right? That's where projects like gnustep or cocotron come in. Neither projects are what I would consider hacks either.
Posted 2 months ago #
vashpan
Member

Oh god. This is something I was thinking from some time now. I knew that GCC supports Obj-C on other platforms. Basically I was thinking about Windows first, Android later...

It could predict that someone will accept that challenge before me ;)

Is there any reason other that conveniency, that cocos2d using iOS/OS X specific code for loading images ? Maybe we could replace this code entirely with 'external' cross platform sources ?

Posted 2 months ago #
Birkemose
Member

@Jordo
Maybe I didn't make myself clear. As you say yourself, a compiler without any framework, isn't worth much.
Maybe hack is a to strong word. I dont know about gnustep or cocotron, and while it certainly sounds like honorable undertakings, I doubt much will come from it. There is a HUGE gap from making a toolbox like cocos2d, to writing a complete ObjC based API for Android, and like I said, I don't think it is feasible for anyone but Google.
No matter what you ended up with, a worst case scenario could be, that changes to hardware or software, rendered anything written on such a platform unusable.

Posted 2 months ago #
zaaroth
Member

I second @Birkemose on this. From a test-and-have-fun perspective it is a really nice thing to exist. But in order to release a reliable product to the customers... I dont think someone would go that way.

Unless Google supports is from grounds up so things dont break at each update (and people dont have to test ahead each of the *numerous* updates the platform has).

Posted 2 months ago #
slembcke
Administrator

Well, Apple open sourced the Core Foundation code (CFArray, CFData, etc) that a lot of the basic classes are built directly on top of (NSArray, NSData, etc). I mean you can even cast objects back and forth between the Foundation and CoreFoundation types safely. So it's not too much of a stretch to imagine people making a pretty reliable reimplementation of the basics. Cross compiling a UIKit application is probably definitely never going to happen, but something like Cocos2D that mostly just builds on top of the basic NextStep runtime classes isn't really so hard to imagine being possible. It just takes somebody with the time/motivation to do it. ;)

I don't see how Google could regularly break libraries that you compiled yourself either. It's not like an Obj-C runtime would be plugging into the higher, more volatile parts of the API anyway. It's mostly going to be built on the standard C libs which are pretty rock solid on whatever platform you want to deploy on.

Posted 2 months ago #
jordo
Member

@Birkemose @zaaroth. Look guys, this is native code with a statically linked runtime. It runs like other native code. Like I mentioned above, we used cocos2d-x for our Android port of Super Stickman Golf. It's all native code, and runs fine. We support any device that is arm, opengles 1.1, and android OS v2.1+. Everything is statically linked, libpng, libxml, even the stdlib provided by google ends up being statically linked as well, so changes to hardware or software are really not a big issue. We've had more problems with the java code in cocos2d-x than any of the native code.

"writing a complete ObjC based API for Android" doesn't really make any sense, in fact I'm not even sure what that means exactly. The obj-c runtime shipped with GCC 4.6 is stable. If it wasn't they wouldn't have included it.

The first code snippet I pasted wasn't a joke. I've installed that test project on the 3 other android devices I have to test with and it runs fine on all of them as expected.

If you're concerned that native code on android is unstable, I'd bet 99% of all the top games on the android market are built natively. I'd argue that native code is actually more stable on android than java based interfaces. And for the record, cocos2d-x have been very very solid for us.

Posted 2 months ago #
jordo
Member

I think you guys are perhaps lumping obj-c in with things like UIKit..

UIKit support on android? Never going to happen.

obj-c and a foundation framework? very real.

Posted 2 months ago #
Birkemose
Member

No matter what, the libraries you made, would have to rely heavily on Googles software, from everything to handling accelerometer, to supporting their implementation of Cloud. It wouldn't take that many misunderstandings in how they handled something, some unsupported functionality, or even just a bugfix, to make the ObjC implementation come crashing down.
And you couldn't fix it with any OS update. The app would be rendered useless.

Posted 2 months ago #
jordo
Member

hmmm, completely disagree. Anything cloud is definitely NOT in the scope of this project. And cocos2d-x has already implemented the accelerometer and touch handler delegates. I recommend spending some time with the Android NDK or even cocos2d-x for that matter to familiarize yourself with the platform.

Posted 2 months ago #
Birkemose
Member

@jordo
No, I don't want to spend time with Android ;)
At least not until you get that ObjC thing to work.

I think we look at this from different perspectives.
I like the way @slembcke put it, that you could ( with enough time and motivation ), make an cocos2d ObjC implementation for Android.
That would be a huge complex task, but why would you want to do that?

Unless you had a complete ObjC API for Android, so I could port my project from iPhone to HTC just by clicking on a compiler setting, it would just be a horrible mix of half this, and half that. In that respect I don't think anything would be gained, and cocos2d-x is as such, a much better path to follow.

I mean no disrespect to anyones work, nor am I in any way implying that this is a joke. I am certain that you guys are hardcore, and knows what you are doing, but I simply do not believe in such an undertaking, and if you ask me, there will never be anything remotely cross-platform for Android and iOS.
But I would be happy to be proven wrong.

Posted 2 months ago #
jordo
Member

@Birkemose cocos2d-x is cross-platform. However, it's the cocos2d api in c++.

My point is this. We at noodlecake have already made the descision to use cocos2d-x for our future projects. We get mutliple platform distribution: android, ios, rim, and others. However, it's actually just a lot faster to write obj-c than it is c++. Obj-c has a great runtime that allows you to do things that take a lot more time in c++.... Sure it's slower, but it can interface with c and c++ if you need the speed.

Obj-c is just a language and a runtime. My goal is not to port everything that is written for objective-c to android. The goal is to port the cocos2d-iphone api.

Secondly, I'm not going to re-write the cocos2d obj-c implementation for android. The point is to use all the existing code. Granted I haven't looked over all the internals of cocos2d-iphone, but it looks like there's not a lot of dependancies on anything else than the core foundation classes (NS*). For things like (texture loading), which cocos2d-iphone uses UIKit for, I am going to plug-in the cocos2d-x implementations for, which directly uses libpng and libjpeg for example.

The next tests I'm going to do are testing NSInvocation, and NSAutoreleasePool. It looks like NSObject, NSArray, NSDictionary, and NSString are working great based on my tests so far.

Posted 2 months ago #
slembcke
Administrator

I didn't say that it would be a huge task. Just that it would take the motivation of somebody like Jordo to try and iron out a few of the kinks. ;) He already has a working Objective-C program because the compiler and runtime exists, and there are already working re implementations of the Foundation framework. The question now is how much work would it be to get something interesting like another library or a game to run on top of it. Something like Cocos2D really might not be that bad as it doesn't really rely heavily on non-Foundation classes. The parts that do (input, setting up GL, sound, etc) are at most a few thousand lines of code to be rewritten.

Google has a HUGE vested interest in not breaking backwards compatibility in Android. If they regularly broke their API there would be angry mobs of developers and users burning down the Googleplex because each new version of the OS broke all the old software. And like I said, the Obj-C runtime + Foundation classes are pretty safe from anything breaking as they are just built on top of the standard C libraries, and there are very very rarely any bugs in those as they haven't changed much in the last few decades. I mean expect that there might be a driver bug with some specific graphics command, but don't expect everything to break.

On the other hand iOS isn't exactly a safe haven for OS bugs either. In OS X, I always use a couple CFRunLoop calls to make my game loops work and to pump the user input. The code should have worked in iOS 2.x, it's a perfectly valid thing to do, but caused some nasty bugs with input lag. The workaround I found to fix it broke on iOS 3.x and I had to put in an OS version check for TWO SEPARATE WORKAROUNDS! Ugh. Shortly after that, CADisplayLink's came around and I never looked back.

And, you're right. You should never expect "write once, run everywhere" to actually work. Plenty of people like to advertise that like Unity, Java, etc. Yeah... I've never met anyone for whom it's worked that way in reality. As the joke goes, "write once, debug everywhere". So yeah, don't expect it to "just work", but I'd certainly be interested in cross-platform builds without resorting to converting my program line by line to a completely different lanugage. O_o

Posted 2 months ago #

jordo
Member

Happy to report that NSAutoreleasePool and NSInvocation are working fine and as expected. This code runs fine:

NSAutoreleasePool *pool = [NSAutoreleasePool new];

	NSString* tmp = [NSString stringWithFormat:@"hi there yo %i", 120];
	NSString* tmp2 = @"TestString";
	TestNewObj* tmpObj = [[[TestNewObj alloc] init] autorelease];
	[tmpObj  testPrintMethodNSString:tmp];	

	SEL cb = @selector(testSelectors);
	id rec = tmpObj;
	NSMethodSignature* sig = [rec methodSignatureForSelector:cb];
	NSInvocation* invocation = [NSInvocation invocationWithMethodSignature:sig];
	[invocation setTarget:rec];
	[invocation setSelector:cb];
	[invocation retain];
	[invocation invoke];

	[pool drain];

This code crashes (as expected):

NSAutoreleasePool *pool = [NSAutoreleasePool new];
	TestNewObj* tmpObj = [[[TestNewObj alloc] init] autorelease];
	[tmpObj  testSelectors];
	[pool drain];
	[tmpObj  testSelectors];

Objc-runtime + Foundation framework running on android!

Reply »