After talking to a few staff members, I think we have come up with a very good solution to this problem. We will now be accepting user submissions to I Love Code! Readers of the site can now submit tutorials that they have written on HTML, CSS, PHP, Javascript, and cocoa! To reward users for posting great tutorials, we will be giving away 3 prizes at the end of each month! One prize will be for the best tutorial (chosen by the staff), another prize will be for the most popular tutorial, and the final prize will go to the user that published the most tutorials in a month. The prizes will be announced at the beginning of each month!

Thank you,

-The I Love Code team

To submit an article, click the handy “Submit an Article” link at the top of the page, or click here.

Related posts:

1. Donations I Love Code is supported solely on donations. Not only...
2. Temporary slow-down Hello! As you may have noticed, the number of tutorials...
3. Hello world! Welcome to I Love Code. I Love Code is a...

There are many kinds of alert views that you can utilise within Apple’s UIKit, the most obvious being UIAlertView. However there are also UIActionSheets and the undocumented UIProgressHUD, the pretty Volume like HUD that you see on mac that apple use within their own iPhone applications. It’s there for you to use, however do be warned if not used correctly apple WILL not let your app onto the AppStore as this is a Private API.

UIAlertView, iPhones typical alert view.
UIAlertView is used throughout the iPhone OS for things such as text messages (SMS) and Push Notifications.

Implementing UIAlertView is extremely simple and handling button taps is done through a delegate method. For more information on handling button taps with the UIAlertView delegate method please refer to the demonstration project attached to this article.

Firstly we allocate and initialise a UIAlertView object.

The method used for initialisation in most cases is - (id)initWithTitle:(NSString *)title message:(NSString *)message delegate:(id)delegate cancelButtonTitle:(NSString *)cancelButtonTitle otherButtonTitles:(NSString *)otherButtonTitles, … This method will create the UIAlertView with the given parameters and allocate the object memory until it’s released.

To display the UIAlertView we simply call the show method, once this method has been called you can go ahead and release the UIAlertView object.

This UIAlertView object will display the UIAlertView buttons in a typical fashion, one beside the other.

However there is a private method, setNumberOfRows:(int)n that will allow you to set a maximum number of rows to display the buttons in. To use this method we need to add our own additions to the UIAlertView class. We do this by adding an @interface for UIAlertView in our .m file.

// extend the UIAlertView class to remove the warning caused
// by calling setNumberOfRows.

@interface UIAlertView (extended)

- (void) setNumberOfRows:(int)num;

@end

This will allow us to call the method without the compiler throwing us a warning.

[myAlert setNumberOfRows:2];

This method call will result in the UIAlertView displaying the buttons on separate rows, the following image depicts the result.

Just like any UIView subclass this object will also respond to you adding subviews, this will allow you to implement UIProgressView’s and other objects such as switches

UIActionSheet, you know, the one that slides up…
UIActionSheet objects are also used throughout the iPhone OS. Apple applications use these to present the user with contextual options, much like a contextual menu on a desktop platform. An example within of a UIActionSheet within an Apple application would be Mail.app When you select the actions button when reading an email you are presented with a UIActionSheet.

Similar to the UIAlertView the action sheet view is allocated and then initialised with parameters such as a title string and an array of buttons. Remember that the list of other button titles must always end with a nil parameter.

UIActionSheet *sheet = [[UIActionSheet alloc] initWithTitle:@"Pick an action, any action!"
delegate:self
cancelButtonTitle:@"Dismiss"
destructiveButtonTitle:@"Delete SMS"
otherButtonTitles:@"Forward SMS", @"Copy SMS", nil];

Again this method will allocate and initialise a UIActionSheet object. Displaying the action sheet requires the showIinView method and it requires a single parameter, the UIView (or subclass) you wish to display the action sheet in. Most of the time, and in this example I will be using the applications key window ([[UIApplication sharedApplication] keyWindow]).

[sheet showInView:[[UIApplication sharedApplication] keyWindow]];
[sheet release];

As soon as you have displayed the view you can release it.

UIProgressHUD, the one they hid from you!
The UIProgressHUD is an alert that isn’t discussed within the API documentation, to use UIProgressHUD we need to create an @interface for it. This ones long. The comment in the code below explains why.

// Create the UIProgressHUD class
// THIS IS A COPY FROM UIProgressHUD.h from UIKit’s private
// frameworks and should be used with the under standing
// that Apple may wish to deny your app to the App Store

@interface UIProgressHUD : UIView
{
UIProgressView *_progressIndicator;
UILabel *_progressMessage;
UIImageView *_doneView;
UIWindow *_parentWindow;
struct {
unsigned int isShowing:1;
unsigned int isShowingText:1;
unsigned int fixedFrame:1;
unsigned int reserved:30;
} _progressHUDFlags;
}

- (id)_progressIndicator;
- (id) initWithWindow:(UIWindow *)window;
- (id)initWithFrame:(struct CGRect)fp8;
- (void)setText:(id)fp8;
- (void)setShowsText:(BOOL)fp8;
- (void)setFontSize:(int)fp8;
- (void)drawRect:(struct CGRect)fp8;
- (void)layoutSubviews;
- (void)showInView:(id)fp8;
- (void)hide;
- (void)done;
- (void)dealloc;
- (void) show:(BOOL)aShow;

@end

Being a private API UIKit will parse any calls we make or objects we initialise however the compiler will not build our application without an @interface for the UIProgressHUD object so here I simply copied the UIProgressHUD.h from the UIKit Private Headers.

Creating a UIProgressHUD is now as simple as creating and other UI object and control.

// create the HUD using the methods we defined for it in the @interface above
UIProgressHUD *HUD = [[UIProgressHUD alloc] initWithWindow:[[UIApplication sharedApplication] keyWindow]];

This object is now allocated, initialised and ready to display. We can set some text for the view, and then display it with the following.

[HUD setText:@"Doing Something…"];
[HUD show:YES];

This will display the alert onscreen see the output below.

This alert can then be told the intermediate action had completed and display a tick in place of a progress indicator, the methods to do this and then remove the alert from superView are show in the interface declaration but for the sake of this tutorial I shall post some code below using timed method calls to change the alert’s state. This code comes directly from the example project so do check it out!

// simulate the different statuses using a timer, normaly you would set these
// in different methods.
[HUD performSelector:@selector(done) withObject:nil afterDelay:1.2];
[HUD performSelector:@selector(setText:) withObject:@"Done Somthing!" afterDelay:1.2];
[HUD performSelector:@selector(hide) withObject:nil afterDelay:2.0];

//release the object, save on memory!
[HUD release];

This concludes my article on types of alerts found within iPhones UIKit framework. For information on delegate methods for handling button clicks within the UIAlertView and UIActionSheet please refer to the sample project where its all quite clear and commented. For further information search the class names in the Cocoa Touch documentation either online at developer.apple.com or from within xcode.

The source code contains a copy of the tutorial for use offline as well as the xcode project for you to read through

No related posts.

To enable the following code to work you’ll need to link the VoiceServices.framework (from the PrivateFrameworks folder of the SDK) in your app.

Apologies for my lazy ‘NSObject’ define above, but you get the idea

With that, you have simple speech synthesis for your application (obviously you cannot include this when you submit to the App Store as it links to a private framework, but you can use it in your internal applications). It requires the 3GS because the Speech stuff just isn’t in the firmware for the older devices.

Obligatory video below:

Reblogged from my blog.

No related posts.

In this tutorial, you will learn how to make this bit:

Ok, so, there is a couple problems we will run into during this tutorial. Problems like not being able to move the window with the bottom bar since the split view will be intercepting the mouse events and making the separator move with the split view. This tutorial assumes only that you know your way around XCode/Interface Builder, and know to subclass things. So let’s get started.

Part 1

First, we need to make our project, so go ahead and make a Cocoa Application (File->New Project in XCode)

The first thing you need to do is design an interface. So, just expand the resources folder in XCode, and open up MainMenu.xib.

Next, we need to do is make our split view. Drag a vertical NSSplitView from the Library, onto the window.

Customize the settings in inspector until you get a desired result. Here is mine:

Make sure your split view resizes with the window in the size panel of inspector:

I’ve just added some elements to my window to make it look more like an application (Make sure to import the appropriate frameworks if you do this).

The reason I’ve left space at the bottom is to make room for the bottom bar. Which we will add soon. You now need to add your resize handle image into the project resources folder, here is one for you:

When you have it in your project, you need to drag it in from the media tab in the library. Just vertically center it with the space you left for the bottom bar. Make sure to put it inside the the subview you want it to resize. Go to the size panel and set these settings for you handle image so it moves with the view.

What you need to do now is make a Controller class. And set it as the delegate of the split view. You also need to make outlets to the window, and the handle image.

Write the class files for this class. (File->Write Class Files) Make sure to specify a superclass (NSObject) in the header file. In the .m file, you need to add a new method, it will be “awakeFromNib” We will use this to create a bottom bar on the window.

So now you have your bottom bar. But we have a problem here. The first is that the line that goes on the bottom bar isn’t dark enough, and the second is that the bottom bar won’t move the window when you try to drag it. Both of these fixed when we subclass the NSSplitView. But for now, we will set the handle as the divider. To do this, we need to use our delegate and a delegate method. So, make sure you have your controller set as the split view’s delegate. After the awakeFromNib method, add this one:

If you had a different handle outlet name, you will need to change that, but this line is self explanatory, it says, “Add another divider around the bounds (edges) of our handle.”
So if you were to build and go right now, you can resize the split view with the handle. It is now time to subclass the NSSplitView to get the bottom bar to be able to move the window, and change the divider line color.

Part 2

This tutorial assumes you know how to subclass objects, so go ahead and write the class files for your NSSplitView subclass. Don’t forget to specify a superclass.

To get the bottom border working, you need to have it so the SplitView can move the window because the splitview is overlapping the bottom bar, thus; intercepting it’s mouse events. So to make the split view able to move the window, add this method to your subclass’ “.m” file.

That’s it! So now to edit the line color that was bothering us, and to fix that, we use our subclass to return a dividerColor. Add this after your “mouseDownCanMoveWindow” method.

If you followed my instructions perfectly or similarly, you should have something close to this:



I hope you enjoyed this tutorial and find all information you learned in here useful and execute it wisely.

Related posts:

1. Adding a Titlebar Accessory View to a Window We’ve all seen it done before: some applications make...
2. Relaunching your application Whether you’re applying new preferences, installing a new version...

Before we go on, I’d like to note that this simple usage of a menubar icon severely violates the Apple Human Interface Guidelines. The menubar of the system should not ever be used like the system tray is in Windows. A menubar icon should perform more actions than simply showing/hiding an app’s window, and cluttering up the menubar with an icon for every application makes no sense whatsoever. Notice the dock at the bottom of your screen:  that’s why it is there.

Step 1. Open XCode.app and create a new project. For now, let’s stick with simplicity and choose “Cocoa Application.” Name the project “AwesomeMenubarButton,” and go on to the next step.

Step 2. We’re going to need to set up the project with a controller. Create a new Objective-C class and call it “AppController.”

Step 3. Next we’ll need to add outlets for all of the needed UI components. In the case of this project, we’re only going to need on outlet:  the main window that we’re going to be hiding and showing. Add the following code in the @interface section of AppController.h:

Step 4. There are two different actions that the menubar button will be performing:  showing the window, and hiding it. For simplicity, we can simplify these two actions into one method that “toggles” the visibility of the window. Directly under the @interface section in AppController.h, add the following code:

And let’s add the window toggling code in AppController.m:

Save both files and lets move on.

Step 5. Open MainMenu.xib in Interface Builder and select File: Read Class Files. Browse to the AppController.h file that we created, and open it. Add a new blank NSObject from the library into your document, and go into the Identity tab of the inspector. Set the object’s Class to “AppController.” The name of the object should now change in the document window.

Step 6. Make sure you still have the App Controller object selected, and go into the Connections inspector. Drag a connection from the mainWindow outlet to the only window in the xib file. Save and close!

Step 7. Here is where it starts to get tricky. NSStatusItem, the class that we’re going to use to make the menubar icon/button cannot be added in Interface Builder:  we have to create it via code. Go back to AppController.m and add the following method implementation:

You’re all done! Build and Go, and the menu item will appear and when pressed, it will toggle the visibility of the main window.

Related posts:

1. Understanding Object-Oriented Programming and the MVC System Introduction Before you begin to learn the basic syntax...
2. Basic C Programming In This tutorial, we will look at the basic principles...

Whenever we Cocoa devs think of NSBox, we usually think of a nice, basic container for other views, that comes with a title, right? Something that looks like this, maybe:

Well, this is only the beginning of NSBox’s flexibility. When we set Box Type to Custom, this opens up 6 properties of NSBox that we can now make use of for our custom layouts: border and background colors, horizontal and vertical margins, and probably the most unexpected properties, the border width and radius.

This gives us a ton of flexibility to do all sorts of sexy basic layout shapes. Combined with the fact that you can very easily change out the content view of an NSBox (via -setContentView:), this little control becomes a very powerful UI element. And when applying a little imagination, we can make our interfaces look much nicer with much fewer custom NSView subclasses.

For instance, the setup window for Adium (very similar looking to Installer.app) could make use of NSBox (if it doesn’t already) for its main “content” view, which gives a basic and nice looking layout.

Normally this would be done with an NSView that draws the translucently-colored border and background itself, and when we want to swap views out, we would have to make sure to set their frame size appropriately, so that they appear where we expect them to. With NSBox, setting the content view does this resizing and repositioning for us for free, plus we don’t even need to touch any code to get the box to appear like it does in this Adium screenshot.

Here are just some of the things you can do with an NSBox in Interface Builder by itself, without even writing a line of code:

I’m not claiming those sample boxes in that last screenshot look good or should even be used in an app, but there’s plenty of ways you could use this flexibility to get rid of some custom NSView subclasses.

No related posts.

When using a WebView object inside a Cocoa application, one might think they are limited to only displaying web pages. However, using custom CSS and JavaScript, a WebView object can become a very powerful and flexible part of a Cocoa app, while looking and working natively.

The first thing you should know is that there is plenty of WebKit-specific CSS. Because you’re writing for a WebView object only, you can (thankfully) ignore all other browsers, and thus you get to use all of this WebKit goodness without any worry. For example, your ‘background-color’ can now be set to ‘window’ which is a handy constant telling the browser to render the color the same as the background of a Cocoa window. There’s also -webkit-appearance, which, while a little lacking at the moment, is a great way to make your element look like native Cocoa search fields, buttons, and text fields, among other controls. Another great feature of WebKit is the “webkit-gradient” function, which essentially allows developers and designers to replace custom gradient graphics with brief, flexible, and most importantly, editable, CSS code.

Now that we can utilize WebKit’s specific CSS to get a nice native-looking user interface, we need to make it do something! Enter WebScriptObject. This is a class brought in by WebKit.framework, and is used in Cocoa. Normally the only WebScriptObject that Cocoa developers should touch is the one received by calling -[WebView windowScriptObject]. This gives you a handle on your WebView’s scripting object, and once you call this, you can do two very important things:

First of all, you can call JavaScript functions from inside your Cocoa app. You do this by calling -evaluateWebScript or -callWebScriptMethod:withArguments: on your WebView’s -windowScriptObject. This will return a value if your JS function does so, or at the very least, executes a JS function inside your WebView. This is handy for, say, refreshing information inside your WebView.

Secondly, and probably more importantly, you can set new objects that your JavaScript scripts inside your WebView can call functions (methods) on. We do this with basic KVC. For example, calling [scriptObject setValue:self forKey:@"ControllerObject"] will give the JavaScript environment a new top-level object called ControllerObject. Now, you can call Cocoa methods from inside JavaScript. There’s only two gotcha, but they can be a little elusive at first:

The first gotcha is naming conventions. If your Cocoa object implements -method, then method() is the function you can call on it. Pretty simple, right? But what if your method is -method:withObject:? Like in the other scripting bridges, simply replace colons with underscores. This, that method becomes method_withObject_(). Kind of lame, I agree, but if it really bugs you can implement +webScriptNameForSelector: which is found in WebScripting informal protocol.

The second gotcha is related to that protocol I just brought up for the first time. See, any object that lives inside your JavaScript environment, implicitly conforms to WebScripting, except it usually doesn’t implement any of these optional methods. There’s two very important methods you’ll have to implement before your JS code can call any Cocoa:

Implement these and return NO for both, while you’re testing. Otherwise, your Cocoa calls from inside JS will never be executed! I recommend that once you’re out of development phase, you make these methods conditional and only allow methods/keys that you call from inside your JS code, for security purposes.

Yes, it takes a little bit of work, but in the end, you have a WebView that looks beautiful and native, and actually interacts with the rest of your app!

Related posts:

1. Integrating iSight into your cocoa application… Having iSight integrated into you app can be useful in...
2. Bottom Bars in Cocoa Mac OS X 10.5 Leopard introduced a new user...

-Alex Nichols

Related posts:

1. I Love Code now featuring User Content! As you may have noticed, the number of articles on...
2. Hello world! Welcome to I Love Code. I Love Code is a...

Posting a tweet is very simple. First we need to set our username and password as properties. Let’s go ahead and do this.

Now, since we are such nice tidy coders, and we appreciate convenience, we are going to put all of our main code in a method (or subroutine as some call it.) The reason for this is because it’s a chunk of code we could be calling over and over again and we want to make it easy to post the tweet. So, let us first create the methods name and add its parameters.

Cool beans. So now we need to add some content to this method. We are simply going to use a cURL shell script to post our tweet. This will suffice. It sends a cURL call to Twitter’s update.xml file using the given username, password and message.

Now you may have noticed a little method called in that shell script called encodeURL. This is a little method we must make to encode our URL before sending it with cURL. We’re going to call a little python script through a shell script to do this for us. Here’s the method.

Next we need to actually execute the shell script, and throw in a little error handler as well.

And there you have it! Now if you want to post a tweet just call the method!

And that’s it! A simple way to post a tweet using Applescript and a clever little cURL call. Have fun!

No related posts.

This episode is geared towards developers who already have an understanding of Cocoa objects, and are familiar with such basic concepts as NSString and text files.

Files and Collections from I Love Code on Vimeo.

Related posts:

1. Basic C Programming In This tutorial, we will look at the basic principles...