Back in 2010 when I started implementing the Mac version, the main task was to reach the feature level of the Windows version (developed for several years) as fast as possible, and also to prepare ground for an upcoming iOS version (available now in App Store). At that time I neither had access to the Windows version’s source code, nor was going to reuse any of it. Therefore I have settled the following constraints that yielded the following results (described in detail in following sections):

(1) Source code must be divided into a framework part and GUI part, where the framework part should contain most of the application logic and use API available on both Mac & iOS platforms, while the GUI part should be reduced to a minimum. Altogether it should match Model-View-Controller architecture.

• Protocol.framework is now 60% of both platforms total source code, manages server communication and models such as LCVisitor or LCChat.
• Protocol.framework does not use any platform specific API and relies only on Foundation.framework.
• Mac & iOS use separate source code for views & controllers driving GUI, however these contain almost no application logic.

(2) Source code should be self-describing and object-oriented, utilizing (where possible) dynamic facilities of Objective-C.

• All model classes visible to controllers are Objective-C classes, controllers have no direct access to protocol.
• Application logic talks with the server through an OO proxy object using dynamic message dispatch to translate messages back and forth into text protocol commands. This makes the protocol layer really small in comparison to the whole application logic.

Protocol.framework

Protocol.framework contains most of the application logic, manages creating and releasing model objects of LCVisitor, LCOperator & LCChat classes, and supplies GUI controllers with them. It contains LCServer private class which is responsible for “message to protocol command mapping”. Applications’ controllers are delegates of LCAccount class.

Mac version may dynamically follow model object’s state updates via Cocoa bindings (not available for iOS) without a need to manually process delegate methods. Therefore, for example inspector pane uses only bindings to update its contents, without actually knowing that it is part of complicated program logic. Inspector view contains just a layout and names for model properties presented to the user.

Strengths:

• Putting whole application logic into Protocol.framework makes platform dependent GUI code reduced to minimum and responsible only for seamless translation of logical objects into GUI views.
• Protocol.framework relies only on Foundation.framework that is a OO bridge for CoreFoundation and CFNetwork C libraries. These libraries were published open-source and are known to build on several other platforms than OSX & iOS. Therefore in theory this code is portable to other platforms as well. Unfortunately source code of CFNetwork is no longer updated. Last available version matches OSX 10.4.11 Tiger. Moreover CoreFoundation on other platforms is stripped from some functionality (named as CFLite) and latest releases have serious build problem on non-OSX platforms. There are several efforts to bring OSX API to other platforms, i.e.: OpenCFLite & PureFoundation  fixing and extending CF & CFNetwork sources, Cocotron redoing whole Cocoa API.

Weaknesses:

• Application must present same logic on all platforms. It is hard to code any exceptions.
• Reusing Platform.framework to other platforms is possible in theory but problematic in practice. If all LiveChat applications were to use single protocol framework, C++ would be a better choice.

Server OO Proxy

While LCAccount translates messages received into model objects, LCServer class is responsible for translating textual protocol commands to Objective-C messages sent and received by LCAccount. LCServer class implementation is really small in comparison to other classes.

Once LCAccount wants to initiate server communication using LCServer, it needs first to provide protocol command to selector maps: (1) incoming map mapping to LCAccount methods, and (2) outgoing map mapping to LCOutgoingMethods protocol. LCServer is the lowest level class that works directly with sockets. Without going into details LiveChat protocol resembles MSN and thanks to its linear (non-structural) construction it is possible to implement such mapping.

Command Reception

Given that following incoming map is provided:

static LCCommandMapping incomingMap[] = {
 …
 { @"R0004", @selector(didReceiveFromClientWithIdentifier:message:senderNick:conferenceIdentifier:hidden:)},
 …
 { nil }
};

Upon each command reception LCServer, parses NSMethodSignature of mapped method and marshals all incoming command arguments into method arguments doing NSString to argument type conversion.

It supports all basic types such as BOOL, NSInteger and NSString. It also supports NSArrays for more advanced callback based commands (beyond the scope of this article). Altogether, calls when receiving following message: R0004|12341|Hello!|Joe|2134|0<LF>

[account didReceiveFromClientWithIdentifier:12341 message:@"Hello!" senderNick:@"Joe" conferenceIdentifier:2134 hidden:NO];

Where called method has the following signature:

- (void)didReceiveFromClientWithIdentifier:(NSInteger)clientIdentifier
                                   message:(NSString *)message
                                senderNick:(NSString *)senderNick
                      conferenceIdentifier:(NSInteger)conferenceIdentifier
                                    hidden:(BOOL)hidden

Of course this method is not called directly (like presented above), but in fact LCServer:

1. Constructs proper NSInvocation object via [NSInvocation invocationWithMethodSignature:methodSignature]
2. Does marshaling and type conversion of received string arguments via [methodSignature getArgumentTypeAtIndex:index]; example for NSUInteger argument:

   if(!strcmp(type, "Q")) {
     NSUInteger value = [string integerValue];
     [invocation setArgument:&value atIndex:index + 2];
   }

3. finally calls [invocation invoke].

LCServer also handles situations when there are too many or too few arguments received from the server:

1. In case there are too few, we may be working with an older server and all missing method arguments get nil, numeric get 0.
2. When there are too many arguments, then we are working with a server more recent than the application. In such case the application ignores extra arguments and emits a warning in the log.

Command Issue

Sending protocol commands to server is done in an opposite way. This time LCServer acts as OO proxy to LCAccount that provides methods mapped to protocol command and handled via Objective-C message forwarding mechanism implemented by:

- (NSMethodSignature *)methodSignatureForSelector:(SEL)selector
{
  struct objc_method_description mdesc =protocol_getMethodDescription(outgoingProtocol, selector, YES, YES);
  if(mdesc.types == NULL) {
    return nil;
  }
  return [NSMethodSignature signatureWithObjCTypes:mdesc.types];
}

- (void)forwardInvocation:(NSInvocation *)invocation
{
  NSString *commandName = (NSString *)CFDictionaryGetValue(outgoingCommandMap, (const void *)invocation.selector);
  … converts all arguments to string representation and send command over socket
}

Once LCAccount provides LCServer an outgoing map and proxy interface:

static LCCommandMapping outgoingMap[] = {
  …
  { @"S0004", @selector(sendFromIdentifier:toConferenceWithIdentifier:message:messageType:) },
  …
  { nil }
};

@protocol LCOutgoingCommands
…
- (void)sendFromIdentifier:(NSInteger)senderIdentifier
toConferenceWithIdentifier:(NSInteger)conferenceIdentifier
                   message:(NSString *)message
                    hidden:(BOOL)hidden;
…
@end

It can cast internally LCServer to id<LCOutgoingCommands> and send message to LCServer:

[server sendFromIdentifier:431 toConferenceWithIdentifier:5488 message:@"Hello to you too!" hidden:NO];

Strengths:

1. Simplicity: No need to maintain long switch & case statements.
2. Separation: Only simple LCServer private class has direct access to the protocol.
3. Argument type casting done automatically at method invocation level.
4. Easy to debug: If program crashes we can deduce command sent by the server from stack backtrace.

Weaknesses:

1. All protocol commands must follow the same rules for formatting and escaping arguments. It is really problematic to handle any exceptions in this model.
2. Protocol commands themselves must be linear (non-structural). Some recently added LiveChat protocol commands have structural arguments that must be parsed separately via external parsers, like XML parser for add-on action commands.

Conclusion

I believe it would not be possible to easily implement solutions described in this article with other API and languages such as C++ or Java. Unfortunately I observe that Objective-C dynamic facilities are less and less utilized by recent Mac OS X (Cocoa) and iOS (Mobile Cocoa) releases and newcomer developers. For example iOS (Mobile Cocoa), which is kind of a rewrite of OSX Cocoa does not implement bindings, like if they were considered deprecated.

Altogether sparse documentation for Objective-C principles, lack of solid examples (for bindings) and finally company politics that intentionally turn this powerful, dynamic language & its APIs into close environment supporting selected products only, deny original ideas of keeping NeXTStep and Objective-C solutions for modern applications running on all platforms.

Yesterday yet another nice little app produced by me was accepted into App Store. You may read original release note at LiveChat blog.

This app is not just a companion app for desktop LiveChat version, but is full fledged client for iPhone, letting you monitor your website activity live and chat with customers. Of course this is just a beginning, so expect new features coming soon with the updates.

Network enabled apps such as news aggregators, blogging clients often load lots of small files, such as thumbnails, trough HTTP connection. One of them is my app – Kozaczek, that loads thumbnails for every UITableView item when it is about to be displayed. Usually we expect that such application is: (1) responsive (does not block scrolling while loading), (2) it does load thumbnails almost realtime.

I suppose the first thing everybody tries is calling [UIImage imageWithData:[NSData dataWithContentsOfURL:someURL]]. There is nothing wrong with it, except it make your UI stutter and load images painfully slow. After trying that one may think of using background threads, NSOperationQueue, or something like that, but still any modern web browser loads those images much faster when they are embedded into regular web page than your application. Wonder why?

Man behind the bar at HTTP server

HTTP 1.1 introduces feature called persistent connections – later backported also to HTTP 1.0 in the form of an extra header Connection: keep-alive sent by the client. This is the clue of the solution here.

You may think of HTTP server working thread serving you as bartender taking your order and bring back drinks. First your connection is waiting in the queue to the bar, once bartender dispatches all orders of clients in the front of you, he asks for yours. Then (during the connection) you have the bartender (almost) exclusively serving you. Once you disconnect, the bartender focuses his attention on the next client, so if you decide to make another request short while afterwards you need to go back in the queue and wait again for your turn.

Back in HTTP 1.0 times, server was taking only one order, sending back response and disconnecting. But since HTTP 1.1 you may send many orders to the server one after the other (or even parallel). You can also stay connected while you are non sending requests, just in case you want something extra. All modern web browsers follow simple rule of trying to execute all the requests using existing persistent connection while not making more than 2-4 connections to single server.

Thats why putting your thumbnails download in background threads or NSOperationQueue does not do any better, but just pollutes remote HTTP server with many connections, that anyway will not be served altogether. Moreover the overall time you gonna spend waiting for response for all requests will be significantly longer than time use with single persistent connection sending requests one-by-one.

CFNetwork HTTP connection pooling

It is better then to keep your application single threaded, but instead use good event driven download mechanism based on persistent connections. The first candidate for that is NSURLConnection which unfortunately has some problems with keeping persistent connections to HTTP 1.0 servers via keep-alive header, even it uses internally CFNetwork. This is the reason I will focus on more low level solution directly based on CFNetwork‘s CFReadStream object and CFReadStreamCreateForHTTPRequest function.

CFNetwork documentation states that this framework tries to pool and reuse existing HTTP connections for newly created CFReadStream if there is still other CFReadStream connected to the same server. This implies two facts: (1) CFNetwork does queue all read requests to the same server where possible trough single connection (2) if only you keep the CFReadStream reference to the server (i.e. using global variable), so every time you open new CFReadStream, it will reuse connection kept inside previously used CFReadStream.

Below I attach ready to use implementation of Fetch class (under MIT-like license) that does all of that for you. All you need to do is to [Fetch fetchURL:someURL delegate:self tag:someTagForYourComfort]. The connection itself does retain Fetch instance and releases it once the request if over, so you do not need to retain it yourself. The delegate (also retained in case it is deallocated before request is over) should implement 3 methods:

- (void)fetch:(Fetch *)fetch didFailWithError:(NSError *)error;
- (void)fetchDidFinishLoading:(Fetch *)connection;
- (void)fetch:(Fetch *)fetch didReceiveStatusCode:(NSInteger)statusCode contentLength:(NSInteger)contentLength;

HINT #1: Once you receive didReceiveStatusCode, you should assign fetch.data property (retained) some NSMutableData instance otherwise it will not store downloaded data anywhere.

HINT #2: If you wish to cancel Fetch request you may use -[Fetch cancel].

• Fetch.h downloader class interface
• Fetch.m and implementation

Since iPhone/iPod Touch is pretty quick to do image decoding in main thread once you get the data, creating image with [UIImage imageWithData:fetch.data] in fetchDidFinishLoading and binding the image to UITableView cell works for me fine.

Implementation part that deserves the attention is initialization part:

- (id)initWithURL:(NSURL *)_url
         delegate:(id<FetchDelegate>)_delegate
              tag:(NSInteger)_tag
{
    // Copy properties
    self.delegate = _delegate;
    tag = _tag;

    CFHTTPMessageRef request = CFHTTPMessageCreateRequest(
                                                          kCFAllocatorDefault,
                                                          CFSTR("GET"),
                                                          (CFURLRef)_url,
                                                          kCFHTTPVersion1_1);
    CFHTTPMessageSetHeaderFieldValue(request, CFSTR("Keep-Alive"), CFSTR("30"));

    stream = CFReadStreamCreateForHTTPRequest(kCFAllocatorDefault, request);
    CFRelease(request);
    CFStreamClientContext context = {
        0, (void *)self,
        CFClientRetain,
        CFClientRelease,
        CFClientDescribeCopy
    };
    CFReadStreamSetClient(stream,
                          kCFStreamEventHasBytesAvailable |
                          kCFStreamEventErrorOccurred |
                          kCFStreamEventEndEncountered,
                          FetchReadCallBack,
                          &context);
    CFReadStreamScheduleWithRunLoop(stream,
                                    CFRunLoopGetCurrent(),
                                    kCFRunLoopCommonModes);

    // In meantime our persistent stream may be closed, check that.
    // If we won't do it, our new stream will raise an error on startup
    // FIXME: This is a bug in CFNetwork!
    if(persistentStream != NULL) {
        CFStreamStatus status = CFReadStreamGetStatus(persistentStream);
        if(status == kCFStreamStatusNotOpen || status == kCFStreamStatusClosed || status == kCFStreamStatusError) {
            CFReadStreamClose(persistentStream);
            CFRelease(persistentStream);
            persistentStream = NULL;
        }
    }

    CFReadStreamSetProperty(stream, kCFStreamPropertyHTTPAttemptPersistentConnection, kCFBooleanTrue);
    CFReadStreamOpen(stream);

    if(persistentStream != NULL) {
        CFReadStreamClose(persistentStream);
        CFRelease(persistentStream);
        persistentStream = NULL;
    }

    streamCount++;

    return self;
}

Few notes about initialization part of Fetch instance:

1. It forces using 30 seconds keep-alive trough CFHTTPMessageSetHeaderFieldValue
2. It retains itself using CFReadStreamSetClient
3. It uses main thread (current) runloop with CFReadStreamScheduleWithRunLoop
4. It maintains persistentStream global reference to last used stream, and replaces it by its own connection (so persistentStream always points to the last one)
5. Finally it forces persistent connections, even they may be default (or not?) using CFReadStreamSetProperty(stream, kCFStreamPropertyHTTPAttemptPersistentConnection, kCFBooleanTrue);

So this is all folks. Waiting for your comments. I hope you will find this post useful.

I am proud to announce my company was hired to create Mac version of LiveChat operator software. The application just entered alpha-phase and today closed tests were started. I hope too that the new refreshing LiveChat icon (on the right) designed by me will be the cherry on the project’s pie.

LiveChat provides innovative web based customer support solutions including live web statistics and live customer chat. The company has great potential and impressive customer base, so you may be interested to follow their Twitter feed too here.

Checkout new L&F from just released alpha and tell me what do you think:

Now I am heading seaside to get some rest, because upcoming September will be busy for sure.

I should say it first – mostly Polish gossips, in Polish language. But anyway Kozaczek.pl is another nanoANT’s piece of craft (mind the spelling). After one week of its premier it topped 2nd in Polish AppStore. We had greater expectations, but some iPhone users here in Poland are really great bigots. I have seen many comments accusing some iPhone news editors that they have put a little news about this app, because this app ill befits there. Come on!

Anyway doing this app was a great fun and I believe using it is a great fun too, especially as an alternative to those grave TV news everyday. Checkout official release news here.

DrawIt was created and is maintained by its author Pieter Omvlee. While doing initial design of this application Pieter asked for help French designer Laurent Baumann (working now for Apple). Pieter’s skills and Laurent’s talent joint together created something extraordinary, the great UI of DrawIt made from scratch to give you an ability to quickly create web/bitmap designs with vector tools and stack of effects. I will not get into details here, as you can find few good articles about DrawIt over the Internet, but I will rather describe little experiment of mine I have made today and try to answer the question if DrawIt can be good Photoshop replacement for icon and web design.

Since lately I was forced to use Photoshop, I decided to give DrawIt a try and recreate one of outstanding Photoshop tutorial icons using DrawIt. My choice went for Basic House Icon from PSDTuts+ site. You can see the result of my work above and you can download the DrawIt source file here.

First of all DrawIt is non-destructive vector based program. Which means you can always revise any step and decision you have made during design process. The idea is based on shapes and effects applied onto them, something you could find in Macromedia Fireworks, Freehand (RiP) or Adobe Photoshop‘s layer’s effects.

Photoshop Layer With Effects

As seen on many Photoshop icon design tutorials, the starting point is a path filled with some gradient or simply filled with black color.  Then most of the folks apply effects created out of the path’s filling. The effects panel used all over again unfortunately is buried in Layers panel and requires extra interaction to pop it up.

In my opinion this really makes me wonder what made Photoshop to be considered better than Macromedia Fireworks or Illustrator for icon design when you are working constantly applying effect, closing and opening Effects window which is simply uncomfortable.

DrawIt Effect Stack

Here in DrawIt it is much easier to set effects for particular shape. First of all you are working only shapes, so you can always touch and redefine the shape’s shape using vector tools, while Photoshop it takes a bit more to redefine layer’s path, also when you did some manual touch to the layer then redefining its path will kill your modifications.

Also DrawIt effects may be applied in random user’s defined order. You can also double same effect, disable and reenable them on fly.

Photoshop’s touch to the image

There’s one thing that you can do in Photoshop but you can’t in vector based programs. It is some human touch to the color or shade using tools like burn, dodge. Such a “touch” can sometimes drastically improve  overall effect. Unfortunately this is impossible simply using DrawIt, as everything is an object here, so dodging particular area of an object is simply impossible.

Nevertheless there is always alternative ways to achieve same effect as you would get using hand drawing Photoshop tools in DrawIt. You just need “think vector”. Sometimes experimenting with various settings can result with amazing overall look of an object.

DrawIt’s perfection killed by some flaws

Unfortunately some minor but longstanding bugs are flies in the DrawIt’s ointment. Undo/redo is the basic thing you expect to work well in any program. It does work well in Photoshop, TextMate, iWork, but NOT in DrawIt, that tends to forget some actions in its undo chain, which makes unpleasant surprise when playing with effects.

Another thing that makes you suffer it a way you change colors of gradients and other various objects, sometimes you need to click few times to make DrawIt change the color of selected property. Again, color panel tends to forget what it was attached to, especially when you change switch objects Color panel is still on screen but attached to nothing.

Resizing objects can be very painful too. First, changing objects height makes it change its vertical position, this isn’t right! Second, trying to resize the document with all objects usually leads to misplacement of those objects.

Finally vector (shape) editing mode deserves more polish, as sometimes you may get crazy if you want to delete several points (no way to drag/select few points), or if you move the point out of the canvas you cannot control it anymore its handle disappears (clipped by canvas rectangle), while you expect shape’s vector handles should be visible outside of the canvas too.

Is it worth a price?

DrawIt is absolutely worth its price and I would glad pay for it again if those few annoying bugs were removed. The author is a very kind nice young fellow willing to listen for the new ideas for his project. One of such ideas is slicing functionality that is probably a result IM chat I did with the author while ago.

However peeking recently into author’s blog it seems he is more focused on his other applications – too bad, but that’s life – you are working on something that gives you best revenue, which may be not DrawIt in this case.

What about Photoshop? In my opinion it is definitely NOT worth a price if you want just an icon design software. I really regret all competing software producers such as Corel, ACD, Xara dropped support for Mac OS X, leaving us in hands of Adobe. Thank God there is DrawIt (and maybe Vectordesigner ;P).

This is the official method, and since SDK 4 does NOT come with 3.x headers, the only method to make your app run on 3.x. But it is not so simple, because now in your Xcode you are using iOS 4 API. So how do you know you are not using classes or methods that do not exist in 3.x and putting them into your code will crash your app on 3.x device? You don’t!

Unfortunately Xcode will warn you about deprecated API, but will NOT warn you about API that does not exist on your deployment target. I buy you a beer if you can find such warning option in Xcode project configuration.

This would be acceptable if you could test your application on iPhone 3.x OS Simulator, but there is no any in SDK 4 (neither as an option), hence you can’t absolutely tell your app won’t gonna blow on iPhone OS 3.x if you upgraded your TESTING devices to iOS 4.

I have spent a while trying to figure our what was Apple’s engineers official statement about that on devforums. And they say if you want to test 3.x compatibility you need get a device with iPhone OS 3.x. Huh? So I shall buy an new iPhone expecting it won’t have iOS 4 on board, because there is no (legal) way to downgrade existing device to 3.x.

Trying to find out a more reasonable way I have ended up with installing an OLD SDK 3.2 on /Developer-3.2. Finally tested my application… but fiddling with SDK 4 was not over. (NOTE: Obviously this method isn’t really free as you gonna lost 4GB for old SDK installation and 2.5GB for download, but it far less expensive than getting a new old 3.x device.)

Still there are few gotchas with this method

And here is one of them. If you happen to use iOS4 API in your code, Apple says that your shall check functions (and class) pointers against nil.

One of the new classes introduced by iOS4 API is UITapGestureRecognizer. I happened to know that because 3.x SDK complained about unknown UITapGestureRecognizer class. So I tried in my code:

UITapGestureRecognizer *singleTap = [[UITapGestureRecognizerClass alloc]
    initWithTarget:self action:@selector(handleSingleTap:)];
if( singleTap != nil ) {
    // do something, we shall be there only on iOS4

Should be enough to be compatible with 3.x device compiling on SDK 4, since UITapGestureRecognizer is introduced by iOS4 API I expected that on 3.x it will be nil so singleTap will be nil too! (BTW. It won’t compile with SDK 3.x I have just installed ;P)

I have sent my app to beta tester with 3.x device, that replied the app is still crashing. So my reasoning about nil was NOT true. Okay, fine, let’s try with:

Class TapGestureRecognizerClass = NSClassFromString(@"UITapGestureRecognizer");
if( TapGestureRecognizerClass != nil ) {
    // do something, we shall be there only on iOS4

Again crashes on 3.x device.

I have lost one day on communication with beta tester and scratching my head. You know why? Because UITapGestureRecognizer actually do EXIST in iPhone OS 3.x but it is NOT in the public API. Moreover it misses some methods that do exist in iOS 4 API, so finally I ended up with something like this:

Class TapGestureRecognizerClass = NSClassFromString(@"UITapGestureRecognizer");
if( TapGestureRecognizerClass != nil ) {
    UITapGestureRecognizer *singleTap = [[TapGestureRecognizerClass alloc] initWithTarget:self action:@selector(handleSingleTap:)];
    if( singleTap != nil ) {
        if( [singleTap respondsToSelector:@selector(setNumberOfTapsRequired:)] ) {
            [singleTap setNumberOfTapsRequired:1];
        }
        // .. and checking other selectors

And this was my WORKING method to be compatible with 3.x and using some of iOS 4 API. Crazy enough?

If you have one, check out http://developer.apple.com/iphone/library/ on it.

Do you like my iPad stand? It is a table easel, paid 25zł (about $10) and it is far more flexible and sexy than all those overpriced dedicated stands. By the way, iPad screen seems to be more blueish than MacBook’s. Both are led backlit, so I wonder why?

I have just learned that AppStore is amazing phenomenon. It is quite impossible to predict impact of an application before it gets released. Some “silly” apps stay on top for weeks, while some real gems are quickly forgotten. So it is worth to test even most crazy wicked ideas against iPhone users putting them into life as AppStore app.