Hi, I'm Jeremy Foo.
I write software to make lazy people lazier.
tweet @echoz email jeremy@ornyx.net
Have been very much inspired by the work on nodejs. For those of you who don’t know, nodejs is a basically a system to do Evented I/O using Google’s V8 Javascript engine.
One such application of nodejs is the development of servers both HTTP or socket based that doesn’t require the spinning up of threads to handle connections and/or network events. Callbacks are assigned to events and when those events happen, the callbacks are ran. No threads, easy peasey, low overheads, etc.
Currently there are 2 ways to do NSURLRequests. You can either wrap it around a thread and execute the operation synchronously or implement its delegate methods and have it run within the runloop.
JOURLRequest is an encapsulation of the NSURLRequest and its delegate methods to provide for a way to easily implement run loop based event-ed NSURLRequests.
I’ve always loved backend code to be as cross platform as possible. Writing everything based upon Foundation and CoreFoundation only is one of the ways to do that and I’ve always strived to adhere to that principle as much as possible.
While that is cool, the problem begins when you actually want a universal library to work on both OS X and iOS. There is no such thing as Xcode clearly separates both. Understandably, this is seems to be an engineering and architecture decision. Still it would be cool to have a library that you can drop in either your OS X or iOS project.
There is largely 2 schools of thought.
- Create your own .framework directory structure
- lipo your own static library
There is inherently more flexibility with option 1, but the complexity of building such a framework is huge. Additionally it doesn’t allow you package everything in an Xcode project that can act as a dependency in your other projects.
Using lipo presents its own problems too as a Fat binary must contain code for unique architecture. In short, you cannot have a fat binary with code for the iPhone Simulator and OS X as both contain the same architecture.
After much experimenting I’ve figured out my own solution for this which I feel gives a much better workflow. The genius of the solution is that independently the project will build and create fat binaries for both iPhone Device + iPhone Simulator as well as iPhone Device + OS X.
Additionally, it can be added to existing projects as a dependency and build the appropriate static library which you can then use to automatically link to your project.
One thing to note though with this approach is that if you have the usage of Categories in your code, you will have to add to the Other Link Flags configuration of the Xcode build settings the “-ObjC” flag. Related Technical Q&A here.
Currently two of my projects use such a method of sharing code.
***Update: If you are using the dependency way of getting things done, just link to the “Device” build target. Every time you want to switch the build target you are working on, just do a Clean all. Xcode will build the architecture of either the simulator or the device depending on selection.
On to the steps.
There’s this curious thing about working on Xcode.
I’ve never seen myself, upon finishing a project, go immediately back to the IDE and start on a new one. Has never happened to me back in my Windows days with Visual Studio 5.0, 6.0, .Net and what not. Has never happened to me with NetBeans and whatever other incarnation of a Java IDE for school.
Maybe its just being a fan boy, but seriously, an IDE? Comparing Xcode to something that is more featured and complex like Visual Studio, you get a feel that Xcode is not truly in the the same game.
Hell, for newbies going to Xcode for the first time, its the most unintuitive POS ever. And yet, it still is a joy to work on once you get the hang of it.
I sometimes think, Objective-C has a part to play. But I can’t be sure.
Working on a new project. Using stuff learnt from the initial work on Traversity. Namely the process where creation of the data model and associated libraries are done first and foremost before connecting up the GUI.
As a usual practice, the library will be open source. No sense creating something that no one else will use. Check the progress on Github.
This should be fun.
