I was wondering if anyone knew how iSimulate automatically registers/hooks itself into a debugged iDevice application? It's as simple as including the static library (and a couple of frameworks) and it just works. There are no methods or functions to call. How is this possible?
A:
Short answer: using categories in Objective-C, you can extend or augment any class in the system, including core classes and NSObject itself. (Similar to "monkey patching" in Ruby for example.)
The actual communication is most likely a broadcast, sending packages that don't expect to get an answer back. When you start your app, it just starts intercepting these packages. So it's the simulator app that hooks into the iSimulate stream, rather than iSimulate somehow "reaching into" your app.
Have a look at the open source accelerometer simulator project. You could easily extend it to broadcast touches too, and basically duplicate what iSimulate does. And you learn about the nifty side of Objective-C.
Felixyz
2010-03-09 21:26:31
I didn't know about that project, but it's handy to know. I do love Objective-C and Ruby for their abilities to override/extend existing implementation. It's not the solution I was original after, but it does give me a idea for another problem I was having :)I think I found the solution using an initialization function (INIT_ROUTINE in XCode) of the linker, via the Mach-O ABI File Format Reference. I'm about to give a whirl.
pryomoax
2010-03-09 21:56:58
Ok, INIT_ROUTINE is only for dynamic libraries, which we all know cannot be created for iPhone applications - Grrr!
pryomoax
2010-03-09 22:10:48
`__attribute__((constructor)) static void MyInit() { doSomething(); }` works, as does adding an `+load` or `+initialize` method to classes.
rpetrich
2010-03-10 03:44:18