Its basically a category on UIView so you can call:

[self.view findFirstResponder];

Imagine you wanted to make sure the keyboard (or any other editor view) was closed you could:

UIView *firstResponder = [self.view findFirstResponder];
[firstResponder resignFirstResponder];

The code is stupid simple:

UIView+AblebotsAdditions.h

#import 
 
@interface UIView (Ablebots)
 
- (UIView *)findFirstResponder;
 
@end

UIView+AblebotsAdditions.m

#import "UIView+AblebotsAdditions.h"
@implementation UIView (Ablebots)
 
- (UIView *)findFirstResponder
{
    if (self.isFirstResponder) {
        return self;
    }
    for (UIView *subView in self.subviews) {
        if ([subView isFirstResponder]){
            return subView;
        }
        if ([subView findFirstResponder]){
            return [subView findFirstResponder];
        }
    }
    return nil;
}
 
@end

In my .gitinore I have:

.DS_Store
*.swp
*~.nib
build/
*.pbxuser
*.perspective
*.perspectivev3
xcuserdata/

Seems to work pretty well.

The brief was simple enough, two type of growl notification were required, a simple digest of all discussions when you first logged in and then a specific “New Discussion” notification when a new discussion came in.

Adding the Growl SDK to your project

The growl SDK is a simple Cocoa framework that you can drop in to your xCode project, download the SDK from http://growl.info/downloads (its at the bottom of the page).

Once downloaded locate and unzip, the unzipped folder will contain a number of things but we are looking for the Growl.framework folder:

Simply drag this folder in to your Frameworks group in your xCode project:

xCode will ask you how you want to copy the framework in, check the copy to destination box so the framework is saved in to your project folder.

You now need to configure xCode to link the Growl framework in to your project and copy the relevent files in to the application bundle, open up the build phase section and make sure that the “Link Binary With Libraries” includes the Growl.framework, xCode should have done this bit for you when you dragged the framework in, but its worth checking just in case, if its not there click the “+” and select it from the list.

Next we want to tell xCode to copy the framework into our bundle, to do this you need to locate the “Copy Files” section in the Build Phases section, if you don’t yet have a “Copy Files” section simply click the “Add Build Phase” button (bottom right) and select “Add Copy Files”. Once you have located the “Copy Files” section change the destination to “Frameworks” and drag in your Growl.framework:

Hit cmd-B to build your project and thats Growl ready to use in your application.

Using the Growl SDK in your application

The basics of using growl are as simple as, impementing a protocol in your app delegate and telling growl to display something, its really that easy, so lets set up our app delegate.

open up your AppDelegate.h (mine is called ABAppDelegate.h, your might have another name), add an import to the growl header file and implement the GrowlApplicationBridgeDelegate on your app delegate class:

Open up your AppDelegate.m file and implement the following method (see the Growl Docs for more info):

#pragma mark - Growl 1.3.1 SDK -
 
-(NSDictionary *)registrationDictionaryForGrowl{
    NSArray *notifications;
    notifications = [NSArray arrayWithObjects: C_COLLABABLE_GROWL_NOTIFICATION, C_COLLABABLE_GROWL_NOTIFICATION_DIGEST, nil];
 
    NSDictionary *dict;
 
    dict = [NSDictionary dictionaryWithObjectsAndKeys:
            notifications, GROWL_NOTIFICATIONS_ALL,
            notifications, GROWL_NOTIFICATIONS_DEFAULT, nil];
 
    return (dict);
}

registrationDictionaryForGrowl is the only Required method in the GrowlApplicationBridgeDelegate protocol and its simply a way of telling growl about the types of notifications your going to be sending. I’m using two constants because i want to use them later when i finally dispatch a notification.

Next up we need to tell Growl that we are going to be its delegate by sending a message to setGrowlDelegate:

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
    [GrowlApplicationBridge setGrowlDelegate:self];
}

Thats all the Growl plumbing done, your now free to stat sending notifications.

Dispatching a Growl Notification

Once you app delegate is set up to act as the Delegate for Growl by implementing the GrowlApplicationBridgeDelegate you can dispact notifications from anywhere in your application, for this project I have a separate controller that receives messages whenever a new discussion comes in, however you can dispatch the notifications from any class that suites your needs.

To send a growl notification you simply need to call :

+ (void) notifyWithTitle:(NSString *)title
			      description:(NSString *)description
		         notificationName:(NSString *)notifName
				 iconData:(NSData *)iconData
				 priority:(signed int)priority
				 isSticky:(BOOL)isSticky
			     clickContext:(id)clickContext;

For my project I had the following in my DisucssionController:

 [GrowlApplicationBridge notifyWithTitle:@"Collabable"
                                        description:[NSString stringWithFormat:@"%d Discussions, %d Unread", data.count, unreadCount]
                                   notificationName:C_COLLABABLE_GROWL_NOTIFICATION_DIGEST
                                           iconData:[[NSImage imageNamed:@"CollabableGrowl.png"] TIFFRepresentation]
                                           priority:0
                                           isSticky:NO
                                       clickContext:@"DIGEST"];

Most of that message is obvious however you will notice that i have supplied an image to iconData, this can me nil which will tell growl to use your application icon, however i felt that the growl icon needed a but more work to make it pleasing on the eye in the context of a growl notification, so i specified my own Growl specific image. I also pass an NSString in to clickContext of @”Digest” this is my payload that when clicked will get passed in to the click handler if you choose to implement one, again you can send nil to this if you not implementing the Click handler.

And thats it, sending that message to the GrowlApplicationBridge will dispatch a notification:

Handling Clicks

The final piece of the puzzle is handling what happens when your user clicks on the notification, again this is super simple and is done back in your AppDelegate by implementing the following method from the GrowlApplicationBridgeDelegate protocol:

- (void) growlNotificationWasClicked:(id)clickContext;

My implementation is like this:

-(void)growlNotificationWasClicked:(id)clickContext{
    if ([(NSString *)clickContext isEqualToString:@"DIGEST"] ){
        self.popoutViewcontroller.popupVisible = true;
    }else{
        [[NSNotificationCenter defaultCenter] postNotificationName:COLLAB_SHOULD_OPEN_URL object: self userInfo:[NSDictionary dictionaryWithObject:clickContext forKey:@"discussionId"]];
    }
}

I’m basically using the clickContext to determine which type of notification was clicked (remember my brief was for two types of notification) and acting accordingly, if its a Digest I open up the Collabable popout window otherwise i know its a discussion so i send a notification that my app will collect and process.

Thats it we have implemented Growl notifications in to our OSX application, and it was seriously east, in fact this blog article took longer to write than the actual implementation… Enjoy

I while back i wrote this post on the ablebots.com blog, its a pretty interesting piece even if i do say so myself, and as time has past since i wrote the post, the message has matured like a good wine.

I really encourage you take a moment to read:
http://www.ablebots.com/2011/04/24/choosing-a-business-partner/

Check out:

CodeSpaces.com 

Ablebots.com

Love It!

Published via TweetPress

About 10 minutes in it occured to me that this must have been done before and while i like hacking with touch events, I did a quick Google and found the exact script i was about to write.

If your looking to add  touch support to jQueryUI components look no further than this Google Code project

I recently came across a nice article/experiment from Matt Gemmell (@mattgemmell) where he decided to test how many simultaneous touches the iPad Multi Touch display would register, it turns out its 11 and he put together a pretty impressive demo app to prove it (see the Screen Shot).

At first sight you would think its a pretty complex application to achieve this, i mean all the multi touch stuff and the animation seems quite complex, however anybody who knows the iOS SDK will tell you that this stuff is trivial at best, and while Matt has done a great job of pulling it all together its far from complex.

The SDK that wasn’t mean’t to be

This application got me thinking about the iOS SDK and the fact that Apple originally didn’t want us writing native applications and in fact they wanted us to write Browser based applications in Javascript, HTML5 and CSS3.

Now its pretty clear to me that the native apps we see (in abundance) on the app store like Angry Birds, Twitterific, Pulse, Things, Pages, etc… could be written using JS, HTML5 and CSS3 but they would most definitely be poorer for it, come on, the runtime performance, the slick User Experience, simply can’t be replecated to the same level with an app running inside a Browser! (let the flame war begin)

So on that note i decided to replicate Matt’s Multi Touch application in Javascript, HTML5 and CSS3, so with a little digging around in Apples documentation I found all the Javascript events that expose touches (touchstart, touchend and touchmove) and began hacking!

Now let me say right now that this is one hours worth of hacking and the end goal was to build an application that was comparable to Matt’s, I suspect some of the code could be optimised, in fact I really hope that is the case when it comes to the Canvas drawing methods (but that is another story for another post).

Now for some reason I fully expected the JS version to respond to less touches than the native version but in fact its 11 just like Matt’s Version, I also expected the animation to be less “smooth” and jerky when I was moving my fingers around, and I was spot on. The iPad benefits from multithreading and a graphics rendering pipeline, where the Browser that my app is running in does not so any processing I do to draw, calculate or respond to touch events all happens in the same thread as well as the browsers rendering code, this in a nut shell is the reason why these apps will not compete with Naive apps, I may in the near future re visit this topic and look at using HTML5 Web-Workers which in theory would give me the ability to run background threads, but i suspect that even that wouldn’t help too much for applications that are so closely coupled to the rendering engine.

Anyway, here is the application I wrote (visit it on an iOS device) it works almost exactly like the Original albeit its not as smooth. The source code is all inline (for your convenience) so feel free to take a look (lift, steal, optimise, laugh at, etc…) and let me know what you think.

My Conclusion

The iPad really is a “Magical” device, and with Great tools like Sencha Touch web developers are better placed than ever before when it comes to building native-ish applications, but I really believe that these apps will be the poorer relations to their native cousins. So keep learning Obj-C folks!

Anyway this is my Open Source answer to that statement, so please if anybody asks you “can rails scale” or makes the statement “Rails can’t scale!” please feel free to use this answer…

Applications built in rails are actually as capable of scaling as apps built in any other language (or on top of any other framework), in fact rails out-of-the-box is good enough for 99.9% of the applications you will ever write, and that tiny amount of apps that will have problems would have the same problems in ANY other language or framework. The benefits of Rails as a framework and Ruby as a language (Like Productivity, Maintainability, Developer Engagement, Mapping to an Agile Process) should in every case be considered over any notion of scaling issues. In fact if your app doesn’t have 8 million concurrent users right now, don’t worry about scaling at all, your wasting time that could be better spent getting 8 million users.

Now this answer doesn’t touch the real issue with this question but in my experience it is good enough to satisfy the type of people who ask this question.

The only exception where i wouldn’t use this answer is if the question (or statement) comes from a “Technical Architect” in a large corperate who is paid 6 figures a year to keep a development team of 100+ moving forward, if he says “Rails can’t scale” Punch him between the fucking eyes, because he should know better.

The truth, is of course that, anybody who says this knows f-all about software architecture and in fact shouldn’t be in a position where they have an audience to spout their nonsense.