It’s been a while, I know. Most of the tutorials here are dating back to iOS 3/4. Oh boy…
I’ve recently run into yet another feature that required a UITableView to behave as an accordion. In other words, you have a list of items that can be tapped, revealing their associated sub items. This is great for creating UIs that require nested menu items, like category lists.
A common scenario would look like this:
All Collapsed
- Fruits
- Vegetables
- Sweets
- Nuts
Vegetables Expanded
- Fruits
- Vegetables
- Cucumbers
- Tomatos
- Carrots
- Goatsbeard
- Sweets
- Nuts
The idea here is to have a list of parents, which have children. When a parent is expanded, its children are shown and can be interacted with. When another parent is tapped, the previous parent is first collapsed and then the new parent expands revealing its children. A classic accordion UI pattern.
There are several tricky points about writing this type of UI in iOS using UITableView:
- Determine if a cell is a child or a parent
- Determine proper insertion points for all scenarios:
- no cells are expanded when a parent cell is tapped
- currently expanded parent is tapped consecutively
- newly tapped cell is above the currently expanded parent
- newly tapped cell is below the currently expanded parent
- Insertion always happens after deletion. This is important to think about when collapsing cells at the same time you’re expanding them
All those crash reports you can download from the Apple developer portal provide a really nice insight to common and most frequent crashes. However, when you look into them, all you see is a bunch of memory addresses and some nicely formatted, mostly foundation, symbols.
There are a few ways to symbolicate these reports and one of them is a utility called dwarfdump. I’m not going to into what dwarfdump is or how it works but all you need to know is that it can convert those pesky memory addresses using your dSYM package associated with your binary.
Basic usage of dwarfdump is as follows: dwarfdump –lookup {memoryAddress} –arch {architecture type} {path to .app.dSYM}
I’ve been using it to symoblicate crash reports for our CNET app by hand but got tired of it so I just wrote a simple and very primitive PHP script that takes a crash report, a .dSYM file and spits out the same crash report, only lines that pertain to your app are symbolicated.
USAGE
To use the script, you need to have PHP installed on your computer alongside dwarfdump. If you installed command line utilities inside Xcode, you should be all set. If not, there are plenty of tutorials out there that can help you install them.
Basic usage of the script is: php symby.php crashreport.crash My App.app.dSYM
The two arguments there are:
- Your crash report file from iTunes. They arrive to you zipped up so just extract them and use them as they are with their file extension .crash.
- Your .dSYM package that belongs to the binary you uploaded onto the App Store. If your dSYM version mismatches your crash report, none of this will work. To get your .dSYM package, locate your Xcode archive by following these steps:
- In Xcode, open Organizer and choose Archives tab up on top.
- Locate the app and archive you used to upload to the App Store
- Right-click on the archive and choose, Show in Finder
- Right-click on the highlighted archive in Finder and choose, Show Package Contents
- There, you’ll see dSYMs and Products folders alongside Info.plist file. Navigate into the dSYMs folder and grab the .app.dSYM file and copy it to the directory where you downloaded symby.php
Now that you have your .crash file, your .app.dSYM file and symby.php you can run the script. Say your crash report file is called SomeApp_2-1_2012-05-01_iOS-5-1_Top-Crash_2_1.crash, your dSYM file is called SomeApp.app.dSYM, you will run your command as such:
php symby.php SomeApp_2-1_2012-05-01_iOS-5-1_Top-Crash_2_1.crash SomeApp.app.dSYM
If both your files belong together and match, the script should spit out the same crash report you fed it, only lines that correspond to SomeApp will now be symbolicated.
TO-DO
As I’ve mentioned, this is a very quick-and-dirty script that does the job. If you’d like to contribute and make it better, please do! It could definitely be optimized and made better. Some of the items on my wish list are:
- Add automatic unzipping of zipped crash files and batch process them
- Auto detection of Xcode archives and offer suggestions of .app.dSYM package locations
- Add option to isolate symbols from your app only and its related symbols
- Optimize and make better
DOWNLOAD
I have been a bit slow updating this site lately partly because we were trying to launch our new app before the holiday season. It features CNET Reviews and packs a bag of goodies like easy category access, filtering and sorting results, latest pricing comparisons, search, barcode scanning or buying guides. So go check it out, install it, and love it! 
Here is an intro blog post from a CNET executive editor: http://reviews.cnet.com/8301-19512_7-20021529-233.html
You can download the app here: http://reviews.cnet.com/iphoneappdownload or directly from iTunes: http://itunes.apple.com/us/app/cnet-product-reviews/id399322513
Sold out in 8 eight days this year, WWDC will be held at its usual spot in San Francisco from June 7 – 11. This year seems to put focus on the iPhone SDK more so than previous years.
If it’s anything like last year, it’s going to be pretty miserable. 5,000 knowledge-hungry developers from all around the world trying to get to the same sessions as you. There will be lines for everything; bathrooms, presentation rooms, lunch, labs, store, escalators. Pretty much anywhere you want go, there will hundreds of others who want the same thing.
At the end, it’s worth it though. The information presented is very solid. They don’t cover everything but enough to get you started. After you walk out of there, you should be able to build a semi-complex iPhone/iPad app. Not bad for ~4 days of sessions.
For all you first-comers, here are a few words of advice:
- If you want to see the keynote, count on seeing some hardcore fans camped out in front of Moscone as early as 1-2am. Getting there at 6am will put you somewhere at the end of the North-West side of Moscone West. You will still be able to get inside the keynote room at that point. Once people condense, the line isn’t really as long as it seems at first. I’d pack light, bring snacks and something small to sit on. You will get cold after a while no matter what the predictions say so have a jacket ready.
- There will be a bunch of companies going around the long line giving away SWAG. Don’t take anything you don’t want because you’ll have to hold it until you get to a trash can. The cute girls giving it away and trying to sign you up for their newsletter aren’t really interested in you, no matter how convincing they are. So don’t be gullible and be strong!
- Once the line starts moving, don’t get your hopes up just yet. You’ll make several stops inside the building before reaching the presentation room. The good thing is, once you’re deep enough, Apple will provide breakfast pastries, coffee and water. Don’t run to it, there will be plenty of it.
- The session rooms will fill up rather quickly. Always know what session you want to attend next and where it is. If you screw around for too long, you may not get in.
- It’s easy to forget about the lunchtime speakers. Don’t waste your time pretending you’re coding in one of the rest areas and go see the lunchtime speakers. They’re really worth seeing. Their success stories are very inspiring and educational.
- When it’s time for lunch, you don’t have to rush. There is plenty of food and lines are fairly manageable. It’s much better than lines to bathrooms or sessions. The food is made for masses so don’t expect Hubert Keller’s cuisine. A vegetarian dish will always be available so meat-haters need not worry.
- For all of our sake, please do not type during sessions. Both slides and session videos will become available a couple months after the conference so don’t try to copy all the source code you see on the screen. There is a lot of loud typers out there and there really isn’t anything more annoying then listing someone hammering on their keyboard during a presentation. If a session bores you or you just prefer to IM your buddies instead, please leave the room so that someone who is actually interested can attend.
- Evening events are fun. I’m not going to go as far as saying they’re unforgettable but they’re fun. Again, it used to be a lot more intimate a few years back but now that everything is being catered to five thousand people, it’s not the same. Stump the experts is one of those events that is highly hyped. It’s full of inside jokes that date all the way back to when WWDC was still in diapers. You may not laugh at them but it’s very intriguing to learn some of the “behind the scenes” tidbits you wouldn’t hear anywhere else. The prizes have been quite substantial too so if you happen to answer a difficult question, you may walk out of there with a Macbook Pro.
- In general, don’t bring too much with you. You’ll have to carry it around all day long and that’s not fun. The bags and laptop sleeves Apple gives out when you pick up your badge are usually pretty uncomfortable to carry so don’t feel obligated to use them throughout the conference. My bag from last year is still in its plastic cover, untouched. It wanted to be a backpack but it was really a glorified laptop sleeve. Don’t expect to get two free phones like at Google IO.
Among other conferences, like JavaOne, WWDC rates as one of the most exciting ones. The whole thing is designed as any other Apple product – very pretty to look at but it has its share of problems. There was a controversy going on about the cost of admission this year. There was no pre-registration period since Apple knew they would sell out quickly anyway. The price tag of $1,595 is up there but still cheap compared to other conferences. Only, the “other” conferences are usually paid for employers. WWDC attendees are mostly individual contributors who pay for the ticket out of their pockets. Therefore, $1,600 in addition to transportation, room and board for 5 days can be quite an expense.
For those attending, you’re going to have lots of fun and I hope to meet some of you there!
Tackling that handy index on the right side of table views is really not that complicated. In fact, it only requires that you implement two methods. In this tutorial, I’m going to take you step-by-step on how to wire it all together.
FutureTap and Edovia have released an open-source framework that gives developers the ability to offer app settings inside the app as opposed to having it only in Settings.app.
The way settings are used today is by specifying Settings.bundle and Root.plist files in your project. This lets Settings.app know about your app and its settings. The obvious downside of this approach is that app settings are separated from the app itself.
InAppSettingsKit uses a hybrid approach to this problem. It still uses the same resource files to create your settings bundle. However, your settings will be available both within the app and in Settings.app. This is great because you don’t have to create any additional metadata files to support this feature while still maintaining the existing functionality.
I’ll play around with it a bit and post back with a report. For now, head over to FutureTap’s or Edovia’s blogs for release notes and more information.
I will be attending an iPhone Tech Talk this Thursday in San Jose. It’s going to be my third one so I wonder if the structure has changed. These talks are usually like mini-WWDCs – packed with information-rich sessions and a party at the end. Last year’s event was a mixture of different WWDC sessions from that year’s conference so I expect something similar this year as well.
The first one of these back in 2007 was still pre-SDK. It was primarily concentrated around web-based apps. This is when I developed CiUI to serialize production of web-based apps. CNET is still using it (http://reviews.cnet.com/4250-1-0.html) but development of their mobile sites has since been handed over to CBS Mobile.
In any case, if any of you are going to be in attendance this Thursday, hope you come say Hi!
Tab bar based apps are probably as common as table-based apps and it’s even more common to see them combined. That’s what we’re going to do in this tutorial.
There is a very easy way of creating a tab bar application. In fact, it’s so easy it requires no work whatsoever. When you choose to create a new iPhone application in Xcode, one of the options is Tab Bar Application. Just the bare-bones template provided by Apple gives you a fully-functioning app with two tabs. That is not what this tutorial will be about. We are going to create a tab bar controller programatically. It’s really a lot easier than most people think.
Prerequisites
This tutorial is a continuation of my previous tutorials so if you haven’t followed them, it’s a good time to catch up.
We’re going to be starting off from a slightly modified version of the previous source code. You can download the primer code for this tutorial here: MyDVDLibrary04Primer. The only changes made were some name changes (DetailViewController became DvdInfoViewController) and I organized all classes into groups.
Also, I’ve recently upgraded to OS X Snow Leopard + Xcode 3.2 with iPhone SDK 3.0 (not 3.1 yet) so the project was compiled on that platform.
I’m going to build this tutorial on the previous two so if you haven’t checked them out yet, you can see the first one here and the second one here. You can also download the source code on the bottom of each tutorial.
What we’ve done so far
We used UITableViewController to build out our root view controller that lists all the DVDs from our data file. Then we customized each cell by adding a DVD cover and some basic info about each movie. Tapping a row in the table caused the app to go to a detail page which was also a table displaying expanded info about the selected movie. That’s the part we’re going to work on now.
1. Download some source code to get your started
Since we’re going to be completely removing the detail view controller we used in the previous tutorials, let’s just start from there. Instead of walking you through deleting the controller and removing the appropriate functionality, download this source code that will get you started. You’ll get the root view controller with customized cells in it. However, tapping on any of the rows won’t do anything, yet. Download the primer project here: MyDVDLibrary03Primer.
2. Enhance test data file
Since our test data file only contains title, length, image and release date for each movie, that’s not going to cut it when trying to design a detail view page. We’ll at least want to add the description of the movie and maybe also its genre. This can be very tedious to do in a plist like we’re using right now but it will get a lot easier once we start using Core Data that I will cover in later tutorials.
I won’t make you add all the data by hand so for a shortcut, download the completed plist file here and replace your existing one that can be found in Xcode under the Resources folder: TestData.plist.
3. Create new DetailViewController class
In Xcode’s file browser on the left, right-click on the Classes folder and choose Add -> New File… . Under Cocoa Touch Classes group choose UIViewController subclass and make sure to check the With XIB for user interface checkbox. This will not only create our subclass but also the NIB file that we’ll use to layout our UI components.
If you followed my first tutorial on UITableView (link | source code), you now have a very simple app that shows a list of DVD titles and clicking any of the titles shows you a detail view page with more information about the DVD. That’s all nice but we really want to make it a little bit prettier. We could display the length of each movie right on the listing page. Also, we have this coverImage field in our data set, let’s use it.
What we want is for our home screen to look like this:
We can accomplish that by customizing UITableViewCell. There are 2 ways of going about it:
- Using Interface Builder
- Programmatically
In reality, you can also choose a hybrid approach where you create some UI elements in the Interface Builder and some programmatically.
Which option to choose?
The two approaches both bring some advantages and disadvantages with them.
Interface Builder
If you decide to go the Interface Builder route, you’ll find it very easy to create and customize your cells. Any subsequent edits can also be done quite easily since you’re simply rearranging elements visually. The downside is speed and performance since the system needs to render each view in a cell individually. If your table view has thousands of rows in it, this may/may not affect the performance of your app, depending how complicated your cell is.
Programmatically
This one involves a lot more work. You are responsible for creating each UI element by hand in the code. That can be very tedious and any edits you need to make in the future require code changes. Also, you’ll need to set up all the autosizing masks yourself. The upside is performance. Since the system will draw each cell as one view, the performance gain can be very significant.