At ELC we are proud of more than 100 years of combined application development experience including dynamic languages like Ruby, JRuby, Python, as well as strongly typed languages such as C and Java. Our knowledge of the Cloud lets us build true scalability into products. This experience, coupled with our creativity, has led us to build some of the largest, most used apps out there. We are experts in AGILE development, delivering working software in weeks, not months or years.

Our customer list includes Fortune 500 companies, major professional sports leagues, and universal media conglomerates. We have successfully completed sophisticated Ruby on Rails solutions, innovative interactive tools, trend setting mobile technologies as well as business critical applications. This has earned us the trust of some of the world’s largest companies.

We offer all the usual benefits… and if you’re located in Portland, an office with the world’s greatest espresso machine, a team of Kung Fu masters, Eight Ball champions, Nerf Gun Assassins, and world authorities on Dungeons and Dragons.

We’re passionate about many things here at ELC, such as:

• Creating cross-platform, enterprise level mobile applications with awesome UI/UX.
• Building software, mainly in Ruby on Rails but have been known to find the right tool for the right job (Scala, Erlang, and Clojure come to mind).
• Having fun, we believe that going to work should carry the same anticipation as that 10 minutes leading up to elementary school recess.
• Being Agile, we don’t force-feed one specific process, but pick and choose what is going to work on a per team/per project basis.
• Solving real world problems without compromising creativity.

Here’s what we look for in our hires:

• Strong problem solving skills.
• Have at least 1 year experience building iPhone/iPad applications.
• Proficiency in Objective-C.
• Understand when something should be extracted to an API, and how to leverage existing ones to make your life easier.
• Not afraid of trial by fire.
• Interest in learning and using new languages in real world situations
• Up to date on the latest Internet Memes and Animated GIFs or it didn’t happen.

Contact
Please send the following to:   jobs@elctech.com

1.  Links to sites you’ve worked on including a brief description of your contributions.
2.  Code samples. Anything you feel like best represents your capabilities / strengths.

Company Website URL
http://elctech.com/

Cloning UIImagePickerController using the Assets Library Framework
Update: ELCImagePickerController

A lot has happened in the iOS world since the creation of this code. With the advent of every new version of iOS there are always exciting new features and bug fixes. Sometimes subtle code changes sneak into classes we’ve been using for a while though. These changes might create bugs that can be hard to find. Whenever I am debugging code on a new release, especially if it’s a beta release, I try to remember to consult the docs sooner than later. When we started to get reports of ELCImagePickerController not working in iOS 5, it was time to do some homework.

The problem seemed to be that the albums were coming up as empty, even when people had plenty of pictures to display. Someone in the community found a quick work around that if you don’t release the library object, then the code starts working again! Leaking memory like this is never the right answer, but it was a great starting spot to figure out the real problem.

The problem seemed to be arising here:

Commenting out the release fixed the problem? Very odd. I floundered around the code a bit before remembering to go to the documentation for this new (beta, at the time) version of iOS. Lo and behold!

The last sentence is key, “The lifetimes of objects you get back from a library instance are tied to the life of the library instance.” If we release our library instance right there we aren’t going to have access to any of the objects we get back from it anymore! This is new behavior in iOS 5. To adapt to it I just moved the library variable out to be an instance variable of the class and didn’t release it until dealloc is called.

Not such a hard fix once I knew what to look for, just have to remember that the documentation is there for a reason! Thanks to the community for the feedback that made tracking down this bug much easier.

We’re back in action!

As I was troubleshooting this control I kept running into the problem that my simulator didn’t have any pictures in it. If only there was a utility to populate the photo album for me. Maybe it could grab images of cute little kittens from the internet or something? Hmm. Stay tuned to iCodeBlog for more on this!

In today’s post, we are going to be discussing view controllers. Let’s start by talking about what a view controller is and it’s role in your iOS projects.

What is a View Controller?

View Controllers are at the core of every application. They act as sort of the glue between your models and your views. View controllers are both responsible for fetching/initializing your models as well as loading up your views to display the information within them.

Basic View Controllers

Every view controller that Apple provides extends from the base UIViewController subclass. This gives them a few basic properties that you will find handy. The most important of course is the view property. This is a reference to the view that the controller is managing.

Along with some default properties, you also get some powerful methods that allow each UIViewController subclass to easily interact with all of the common view controllers.

Here are some of the basic view controllers to be discussed in this post:

• UINavigationController
• UITableViewController
• UITabBarController

I picked these 3 controllers since they are the most common and are automatically created in the main project templates when creating a new XCode project.

UINavigationController

Basic Navigation Interface

Generally we don’t talk about UINavigationControllers outside of the context of a UITableViewController, however we need to discuss them prior in order to see what’s going on under the hood.

UINavigationController are used when you want to have some sort of hierarchal representation of your data (ie drill down). They work using a stack of UIViewController subclasses. Every time you “drill down”, you simply add another view controller to the stack. Then, the “back” logic is simply a matter of popping view controllers off of a stack.

At the bottom of the stack, there is the rootViewController which get set during initialization and can never be popped off. At the top of the stack, is the current view controller who’s view is being displayed to the user.

Here is a code sample demonstrating how to push a view controller on to the navigation stack.

// Initialize MyViewController object
MyViewController *controller = [[MyViewController alloc] initWithNibName:@"MyViewController" 
                                                                   bundle:[NSBundle mainBundle]];
// Pushes MyViewController object on the navigation stack
[self.navigationController pushViewController:controller animated:YES];
[controller release];

In this example, we instantiate a new UIViewController subclass called MyViewController and push it on to the view controller stack. One very important detail to point out is, you must do this from inside of a view controller that is contained inside of a navigation controller, otherwise the “self.navigationController” property will be nil. navigationController is a property of every UIViewController subclass that gets set whenever it has been inserted into a UINavigationController.

Another thing to note is, we release the controller after pushing it on to the stack (prior to iOS5 with ARC). This is because the navigation controller will retain your view controller therefore preventing it from being released from memory.

The following code will pop the view controller off of the view stack with an animation.

[self.navigationController popViewControllerAnimated:YES];

Now we are going to see how UINavigationControllers are used in conjunction with UITableViewControllers.

UITableViewController

UITableViewController

UITableViewControllers are quite possibly the most popular/common view controllers used in iOS. They are perfect for displaying large amounts of data or any sort of form entry.

By default, a UITableViewController has a UITableView as it’s main view and serves as both the delegate and data source for this view. What this means is, it is responsible for populating the table with data, configuring how the data is displayed, and determining what to do when the user interacts with the table (swipes, touches, etc…).

Let’s take a look at a simple UITableViewController. Here is an init method initializing the data array to be displayed in the table view as well as the primary 3 data source methods.

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil {
    self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
    if (self) {
        self.title = NSLocalizedString(@"Sites", @"Sites");
        // #1
        _dataArray = [[NSArray alloc] initWithObjects:@"Reddit",
                                                        @"XKCD",
                                                        @"The Oatmeal",
                                                        @"Hacker News",
                                                        @"iCodeBlog", nil];
    }
    return self;
}
 
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
    // #2
    return 1;
}
 
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    // #3
    return [_dataArray count];
}
 
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    static NSString *CellIdentifier = @"Cell";
 
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
        cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;
    }
 
    // #4
    cell.textLabel.text = [_dataArray objectAtIndex:indexPath.row];
    return cell;
}

As mentioned before, we are displaying a simple array of NSString objects in the table view. This array gets initialized in #1 before the tableview is even displayed. The next method in #2 returns the number of sections for the table. In our case, we only need one section so we hard code the number 1 as the return value.

The code in #3 returns the number of cells in a given section. Generally, this will mean the number of objects in your array. So, we just return the count property of our dataArray.

Finally, the method in #4 builds the cell for a given row in a section, configures that cell, and returns it. In our case, the only configuration we need to do is set the text property of the cell’s UITextLabel to the string in our array at the corresponding index.

These 3 methods are the absolute minimum required to use a UITableViewController and display its table. There are quite a few more methods that you can implement related to the cell height, titles for sections, and more. The last thing I want to show you is how to support basic user interaction.

There is only one method you need to implement to support taps on the cells. Here is the sample code from above inside of didSelectRowAtIndexPath.

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    // Initialize MyViewController object
    MyViewController *controller = [[MyViewController alloc] initWithNibName:@"MyViewController" 
                                                                       bundle:[NSBundle mainBundle]];
    // Forward some data
    controller.site = [_dataArray objectAtIndex:indexPath.row];
    // Pushes MyViewController object on the navigation stack
    [self.navigationController pushViewController:controller animated:YES];
    [controller release];
}

Now when the user taps a row, it will loading up a MyViewController object, pass along the information about the cell tapped and push it on to the view stack. One thing to note here is, this code assumes that the UITableViewController class presented above is inside of a UINavigationController.

UITabBarController

UITabBarController

The last controller we are going to discuss in this post is the UITabBarController. As you may have seen in many applications, a tab bar separates out view logic into multiple “tabs” and switches between them when the user taps on each one. Each tab represents a different view controller that could be any of the types above. As a newer developer, TabBarControllers are a little tricky to implement manually, so I’d suggest starting your project using “Apple’s Tab Bar Application” template file. This will provide you with a simple tab bar application with two sample tabs.

We are going to walk through the code generated from the iOS 5 template that details how a tab bar is constructed.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    self.window = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease];
    // #1
    UIViewController *viewController1 = [[[FirstViewController alloc] initWithNibName:@"FirstViewController" bundle:nil] autorelease];
    UIViewController *viewController2 = [[[SecondViewController alloc] initWithNibName:@"SecondViewController" bundle:nil] autorelease];
    // #2
    self.tabBarController = [[[UITabBarController alloc] init] autorelease];
    // #3
    self.tabBarController.viewControllers = [NSArray arrayWithObjects:viewController1, viewController2, nil];
    // #4
    self.window.rootViewController = self.tabBarController;
    [self.window makeKeyAndVisible];
    return YES;
}

The code here is actually pretty straight forward. #1 initializes both of the view controllers we want to display in 2 separate tabs. Don’t worry about setting their title and tab bar icon now, I will get to that in a moment.

Now, in #2 we initialize the tab bar controller. Unlike the UITableViewController, we don’t need to make our own subclass. It is fine to just let the app delegate manage an instance of the tab bar controller.

The code in #3 is where we set the view controllers of the tab bar controller. It should be clear now how easy it is to add more “tabs” to you your application.

Finally, #4 adds the tab bar controller to the window displaying it to the user.

Let’s take a quick look at the code in the initWithNibName method of FirstViewController in order to see how the title and image are set for that controller.

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
{
    self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
    if (self) {
        self.title = NSLocalizedString(@"First", @"First");
        self.tabBarItem.image = [UIImage imageNamed:@"first"];
    }
    return self;
}

Pretty simple right? Every UIViewController subclass has a title and tabBarItem property. That way, it knows what to display if you place it inside of a UITabBarController.

Conclusion

This wraps up our very surface level introduction to UIViewControllers. I have zipped both of the sample projects used here and you can download them here.

If you have any questions or comments, please feel free to leave them here or write them to me on Twitter.

Happy iCoding!

This post is part of an iOS development series called Back To Basics. You can keep up with this series through the table of contents, RSS feed, or Twitter.

For certain Objective-C objects such as NSString, NSNumber, NSArray, NSData, NSDictionary a design pattern called Class Clustering is utilized to present a public facing class to represent a collection of classes used behind the scenes. While this ends up creating some really powerful objects in the default Objective-C API, it presents some challenges to subclassing. Apple speaks to the challenges in subclassing the abstract class superclass representing a class cluster. When doing this a class must:

This list of tasks can seem a little overwhelming at first but it is pretty simple once you get into it. Today we are going to subclass NSString. The example we will make will encrypt a string upon initialization, the reason we want this to be a subclass rather than a category is that we want to be able to distinguish encrypted NSString object types from non encrypted object types.

ICBEncryptedString.h

Below is the our encrypted string object header. As you can see we are indeed subclassing the cluster’s abstract super class, in the case NSString. We are also declaring our own storage there with out NSString backing store instance variable. The great thing about this abstract parent class subclassing is that you can still use the type you are most used to as your backing store. If speed or memory was important to you here, you could also implement it with more lightweight C based structures as well. With that done we declare a new special class level initializer and override initWithString:

#import <Foundation/Foundation.h>
 
@interface ICBEncryptedString : NSString {
 
    NSString *_backingStore;
}
 
+(id)encryptedStringWithString:(NSString *)string;
-(id)initWithString:(NSString*)string;
 
@end

ICBEncryptedString.m

According to our to do list the next thing we need to do is override all initializer methods of the super. This would be very annoying to do for NSString so I have done it with 2 specific methods that I will always use when initializing ICBEncryptedString’s. So in our initializer here we simply take he string provided to us, SHA1 it, and then set our _backingStore NSString instance variable to the now encryptedString. The only remaining thing to do is override the superclass’s primitive method. NSString’s documentation tells us that the required primitive methods to override are length and characterAtIndex:, essentially, every other instance method for NSString relies on these methods as their backing. With this done we now have a distinguishable Encrypted String class that has all of the abilities of NSString but does encrypting for us on initialization. Check out the class implementation below.

You can find the NSString category for SHA1 at the awesome new site iOS Boiler Blate

#import "ICBEncryptedString"
#import "NSString+Helper.h"
 
@implementation ICBEncryptedString
 
+(NSString*)encryptedString:(NSString*)string {
 
    return [[NSString stringWithFormat:@"%@", [string SHA1]];
}
 
+(id)encryptedStringWithString:(NSString *)string {
 
    return [[[ICBEncryptedString alloc] initWithString:string] autorelease];
}
 
-(id)initWithString:(NSString*)string {
 
    if(self = [self init]) {
 
        _backingStore = [[ICBEncryptedString encryptedString:string] copy];
    }
 
    return self;
}
 
-(void)dealloc {
 
    [_backingStore release];
    [super dealloc];
}
 
-(NSUInteger)length {
 
    return [_backingStore length];
}
 
-(unichar)characterAtIndex:(NSUInteger)index {
 
    return [_backingStore characterAtIndex:index];
}
 
@end

Follow me on Twitter @cruffenach

In this tutorial, I will show you how to use ASIHTTPRequest along with JSONKIT to fetch, parse, and interpret remote JSON that will ultimately change how our application behaves. For this example, we are going to make a simple “nag” popup that will nag the user to download your latest application. When you set a remote flag to true, all users will see the popup every time they launch the application. The popup will also display a dynamic message from the web and link to a location specified in the JSON.

1. The JSON

First, let’s chat a little bit about the JSON we will be using. Here’s what it will look like:

{
    "nag": true,
    "message": "Check out Smart Lockscreen Creator!",
    "url": "http://itunes.apple.com/us/app/smart-lockscreen-creator/id419890996?mt=8"
}

The field names should be pretty self explanatory. We will use JSON kit to parse these fields into an NSDictionary.

2. The Libraries

As mentioned before, we will be using 2 libraries to get the job done.

• ASIHTTPRequest ASIHTTPRequest is an easy to use wrapper around the CFNetwork API that makes some of the more tedious aspects of communicating with web servers easier.
• JSONKit – A JSON Parser written in C with an Objective-C wrapper.

Make sure you download their source and follow each of their instructions for setting up your project to use them. JSONKit is pretty much drag in the source and you are good to go. ASI has a few framework dependancies that you are going to have to work out. The instructions for setting it up are here.

3. The Code – Download And Parse

You can add the code to fetch and control your application wherever you see fit, however I have added mine to the application’s delegate method.

    // 1. Fetch out to the web
    NSURL *url = [NSURL URLWithString:@"http://f.cl.ly/items/2y141v3O0G2e2Y2W3P24/alert.json"];
    ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url];
 
    // 2. Completion block
    [request setCompletionBlock:^(void) {
        NSString *responseString = [request responseString];
        // 3. parse the response
        NSDictionary *responseDict = [responseString objectFromJSONString];
 
        // 4. pull out data
        BOOL nag = [[responseDict objectForKey:@"nag"] boolValue];
        NSString *message = [responseDict objectForKey:@"message"];
        self.nagURL = [NSURL URLWithString:[responseDict objectForKey:@"url"]];
 
        // 5. If nag is true, then show the alert
        if(nag) {
            UIAlertView *alert = [[[UIAlertView alloc] initWithTitle:@"Message" 
                                                             message:message 
                                                            delegate:self 
                                                   cancelButtonTitle:@"Cancel" 
                                                   otherButtonTitles:@"Go",nil] autorelease];
            [alert show];
        }
    }];
    // 6. Start the request
    [request startAsynchronous];

In #1, we fetch out to the web and pull down the json string that contains our configuration settings. #2 sets the completion block for the request. If you are unfamiliar with this pattern, the request fires off in a new thread and the block gets executed AFTER the request completes. That way, we can keep all of our code in line rather than messing around with target and selector callbacks.

For #3, we are using JSONKit’s category on NSString that returns an NSDictionary representation of the JSON string. It couldn’t be easier.

Line #4 is where we extract the info from the dictionary and assign it to local variables. We set the nagURL global property here as well. The reason we must create a property for nagURL is we need to use it again in the delegate method for the UIAlertView in order to send the user to the url specified from the web.

Line #5 is where we check if nag is true and then show the alert. Make sure to set the delegate to our calling class so that we can respond accordingly.

Finally, in #6, we start the request asynchronously.

The last thing to do is implement the delegate method for the alert view. It’s pretty straight forward:

- (void) alertView:(UIAlertView *)alertView didDismissWithButtonIndex:(NSInteger)buttonIndex {
    if(buttonIndex == 1) {
        [[UIApplication sharedApplication] openURL:self.nagURL];
    }
}

We simply check to see if the user pressed the “Go” button, if so, we send them to the URL specified by the nagURL property.

Conclusion

And there you have it. A very simple example of how you can control some portion of your applicaiton’s functionality based on remote web data. You could expand upon this in a number of ways including:

• Enabling/Disabling parts of the app
• Loading “News” in some sort of ticker
• Daily promotions
• Promote new apps
• Daily content (jokes, words, inspiration, scripture, etc…)

If you have any questions or comments, you can leave the here or write me on Twitter.

The source project for this post is available here.

Happy iCoding!