Most of the tutorials I saw had code that looked something like this:

NSString* unsafeSqlString = [NSString stringWithFormat:
     @"UPDATE record SET name=\"%@\" WHERE id=%@", record.name, record.id];

What’s the problem here? Good ol’ Bobby Tables. Depending on what record.name is, your SQL statement may do something that you weren’t expecting (you didn’t want to delete all the records in your table? Should’ve thought of that before writing such unsafe code!).

The correct way to do this is with parameterized queries. In sqlite3, you use parameterized queries by replacing your values with ?’s in your SQL statement. So the above unsafe SQL statement becomes this:

NSString* safeSqlString = @"UPDATE record SET name=? where id=?";

You then prepare a SQL statement with your query:

sqlite3_stmt* statement;
if(sqlite3_prepare(database, [safeSqlString UTF8String], -1, &statement, NULL) != SQLITE_OK)
{
  // Add your error handling code here
}

Finally, you bind all of your parameters to set the actual values that will be used when your query is executed:

if(sqlite3_bind_text(statement, 1, [record.name UTF8String], -1, SQLITE_TRANSIENT) != SQLITE_OK)
{
  // Add your error handling code here
}
if(sqlite3_bind_int(statement, 2, record.key != SQLITE_OK)
{
  // Add your error handling code here
}

For more details on all the different sqlite3_bind functions, see the SQLite documentation.

Finally, you execute your safe, injection-free SQL statement:

if (sqlite3_step(statement) != SQLITE_DONE)
{
  // Add your error handling code here
}

Sure, avoiding SQL injection attacks in a small iOS app is probably less of an issue than avoiding them in a mission-critical website, but that’s no excuse to do it wrong. And here’s another, even more obvious reason to do it right: If any of your fields have a ” in them, your unsafe SQL statement will fail. The parameterized statement handles quotes correctly.

Development Time: ~15 Hours. This is a pretty rough estimate as I wasn’t keeping track of time. I have since started using Thyme to track my hours.

Review Time (time spent in the iOS app submission queue): 7 days

New technologies used: Everything! As this was my first app, everything was new, from UITableViews to Xcode to distribution and deployment.

Challenges: Aside from getting acclimated to an entirely new set of development tools, the hardest part was figuring out where to draw a line in terms of features. It’s a delicate balance between the desire for more features, and the desire for a simple, easy to use application.

Future plans: There are a number of bug fixes coming in the immediate future, and possibly some new features and a prettier UI shortly thereafter. If you have any feedback regarding BBQ Menu, please drop me a line!

The trick is to remove the following row, cell, and section methods from your UITableViewController subclass. They are automatically added by Xcode, but if you are using static cells, you don’t want them in your class.

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

Once you have removed these methods, your cells will show up correctly.

I submitted January’s app to the app store on the 30th, but it’s still waiting for review. So although it’s not technically in the app store yet, I consider this a pretty successful month. And I’m already hard at work on February’s app – this time using Thyme to keep track of exactly how long it takes to build.

I’ll put up more info on each of the apps as they are released

Oh, and don’t even think about renaming your project. That would just be stupid.

What purpose does this fee serve, aside from turning away potential developers?

It’s certainly not making Apple rich. According to Apple, there are over 500,000 apps on the app store. If we make the tenuous assumption that there’s a 1 to 1 ratio of apps to app developers, we can guess that there are around 500,000 registered iOS developers, who altogether make Apple a tidy sum of $49.5 million dollars per year. Sounds great, right? Well, not when you consider that took in $28 billion in revenue in the last quarter alone. That 49.5 million dollars in annual developer program fees is approximately 0.017 % of Apple’s quarterly revenue. Less than a drop in the bucket.

No, the real reason, as I see it, is to intentionally raise the bar to attract only the developers who are serious about the platform. Were there no annual fee, the app store would likely be (even more) deluged with lower quality apps, and the approvals team would be even more swamped than they already are. This is certainly a valid point, but it hurts small developers, as even the simplest apps now have to sell approximately 142 copies per year just to cover the developer program fees (and that’s not even considering the other fees associated with iOS development). As a newcomer to iOS development, this is a somewhat scary number.

Since the motivation for the annual fee is quality, not direct financial gain, I have an idea to ease this pain: refund some or all of the fee for each app that is successfully submitted to the App store. By doing this, Apple would still create its desired barrier to entry, but it would be less of a burden on small-time developers. And as the money would not be refunded until an app successfully passed the submission process, developers would have just as much incentive – if not more – to release high-quality apps.

Of course, none of this matters, because Apple would never do such a thing. But I can dream.

This is a few steps above and beyond the likes of what Visual Studio can do. Instead of seeing a single control or a single window at a time, you can see all of them, plus the way they relate to each other.

Some of the features of storyboards are not particularly discoverable, though, such as the Ctrl-clicking and dragging to create a segue (or an outlet, but I believe that’s just part of Interface Builder that’s been there for a while, not a feature specific to storyboards). There are also some fairly unintuitive behaviors with regards to zooming and selecting. It appears that there are only four zoom levels – you can’t zoom in or zoom out arbitrarily. And selection works differently at the different zoom levels. For example, if you aren’t zoomed in all the way, you can’t select individual controls; you can only select entire views. But if you click on a control in the document outline, you are suddenly zoomed in to it. Not deal breakers, of course; just things that might initially surprise you.

Minor quibbles aside, storyboards are a terrific step forward in the realm of visual designers, and one that I would love to see in Visual Studio.

By the way, if you’re looking for a great storyboard tutorial, check out Ray Wenderlich’s Beginning Storyboards Tutorial.

Multiselect in a UI designer is a pretty standard operation. If I want to change a property on a number of controls at once, I should be able to simply ctrl-click them (or command-click, or option-click, and so on) to select them all, and change the property.

Unfortunately Interface Builder doesn’t seem to support multiple selection on controls in different UITableViewCells. Attempting to do so always results in the first control being deselected.

However, there is a workaround, which is why this entry is really half ‘iOS Pain Points’, and half ‘iOS Quick Tips’. It turns out you can multiselect across table cels by command-clicking in the Document Outline window on the left.

Not entirely intuitive, but it does the trick!

This is somewhat bizzare as it means setting a property on one view controller can affect other view controllers, but nevertheless, it’s quite simple. Here’s what you need to do:

• Open your storyboard
• Click on the view controller corresponding to the view that you want to be the default view
• Open the Attributes Inspector
• Check the Is Initial View Controller check box in the View Controller section

Voila! Your view controller is now the default view controller for this storyboard.

Step 2: Add properties for the array of all the table data, and the array of filtered table data.

@property (strong, nonatomic) NSMutableArray* allTableData;
@property (strong, nonatomic) NSMutableArray* filteredTableData;

Step 3: Assign your search bar’s delegate to your controller class.

-(void)viewDidLoad
{
    // ...Do initialization stuff here...
 
    searchBar.delegate = (id)self;
}

Step 4: Implement the searchBar:textDidChange: method from the UISearchBarDelegate protocol. This will let you filter your list as you type. If you want to filter when the search button is clicked, use the searchBarSearchButtonClicked: method instead.

In this example, we are searching through a list of foods with names and descriptions to see if the match the search text. If they do, we add them to our NSMutableArray containing our filtered foods. We also set a flag that indicates whether or not we are currently filtering the list.

-(void)searchBar:(UISearchBar*)searchBar textDidChange:(NSString*)text
{
    if(text.length == 0)
    {
        isFiltered = FALSE;
    }
    else
    {
        isFiltered = true;
        filteredTableData = [[NSMutableArray alloc] init];
 
        for (Food* food in allTableData)
        {
            NSRange nameRange = [food.name rangeOfString:text options:NSCaseInsensitiveSearch];
            NSRange descriptionRange = [food.description rangeOfString:text options:NSCaseInsensitiveSearch];
            if(nameRange.location != NSNotFound || descriptionRange.location != NSNotFound)
            {
                [filteredTableData addObject:food];
            }
        }
    }
 
    [self.tableView reloadData];
}

Step 5: Modify our other UITableViewController methods to make them aware of the isFiltering flag, and to use the correct list depending on whether or not we are filtering.

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    int rowCount;
    if(self.isFiltered)
        rowCount = filteredTableData.count;
    else
        rowCount = allTableData.count;
 
    return rowCount;
}
 
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    static NSString *CellIdentifier = @"Cell";
 
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil)
        cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:CellIdentifier];
 
    Food* food;
    if(isFiltered)
        food = [filteredTableData objectAtIndex:indexPath.row];
    else
        food = [allTableData objectAtIndex:indexPath.row];
 
    // ... Set up the cell here...;
 
    return cell;
}

Voila! You now have a UITableView that can be filtered using a UISearchBar.