Create, Read and Delete a file in your iPhone App

I recently had to add some functionality to the app I’m working on in which an email would be sent by the app with an attachment that contained data collected by the app. Well I already had the email portion working but wasn’t sure how I wanted to do the attachment. It needed to be an html document and my first thought was to create an html file, attach it to the email and then delete the file. As it turned out I decided not to create the file and just created the attachment on the fly. But since I had already written a small app to test creating, reading and deleting a file I figured I would go ahead and turn it into a tutorial. Because honestly when I was first figuring out how to do the file stuff I couldn’t find a very simple tutorial on the subject. So here it is.

1.) Create a new View-based application and name it FileTutorial.

2.) The first thing we are going to do is set up our view. So double click FileTutorialViewController.xib to open it up in File Builder.

3.) We’re going to add three buttons and a UIWebView. If you need help doing this refer back to the Interface Builder Tutorial. After you add these user elements it should/could look something like this.

4.) Save your work in Interface Builder and go back to Xcode. Open up FileTutorialViewController.h. We are going to add an NSFileManager, an NSArray and 2 NSStrings. We also need to add an IBOutlet for the UIWebView we added in Interface Builder. We’ll set the properties for all of these and define three actions that will be called from our buttons.

5.) Next we open up FileTutorialViewController.m. and synthesize our variables we defined in the header file.

6.) Now we need to implement our variables, we’ll do this in the viewDidLoad method

7.) We need to implement our three IBActions that will get called when a user selects one of the buttons. First we’ll do createFileAction. This method creates a very basic html file using an NSMutableString, then it checks to see if the file already exists and if it doesn’t it creates a file at the defined path and then writes our string to the file.

8.) The second method is deleteFileAction. This method simply checks to see if the file exists and if it does it removes it from the path.

10.) Before any of this will work we need to go back into Interface Builder and connect out IBActions and the UIWebView. Connect each action to appropriate button and the webView to the UIWebView.

11.) You can now save everything, go into Xcode, click Build and Run and test it out. If you make the console visible you can follow along with what is happening.

That’s it, pretty simple stuff. I didn’t explain things in much detail because the naming of the variable and methods really identified what was happening pretty well.

iHope this helped you.

You Can DOWNLOAD complete CODE HERE.

Core Data Tutorial: How To Use NSFetchedResultsController

This is the third and final part of a series to help get you up to speed with the basics of Core Data quickly.

In the first part of the series, we created a visual data model for our objects, ran a quick and dirty test to make sure it works, and hooked it up to a table view so we could see a list of our objects.

In the second part of the series, we discussed how to import or preload existing data into Core Data so that we have some good default data when our app starts up.

In this part of the series, we’re going to discuss how we can optimize our app by using NSFetchedResultsController, to reduce memory overhead and improve response time.

Why Use NSFetchedResultsController?

So far, we’re at exactly the same point we were using the SQLite3 method. However, we didn’t have to write nearly as much code (notice the absence of a FailedBankDatabase class constructing raw SQL statements), and adding other functionality such as insert/delete operations would be much simpler.

However, there’s one notable thing that we could add pretty easily with Core Data that could give us huge benefits to performance: use NSFetchedResultsController.

Right now we’re loading all of the FailedBankInfo objects from the database into memory at once. That might be fine for this app, but the more data we have the slower this will be, and could have a detrimental impact to the user.

Ideally we’d like to load only a subset of the rows, based on what the user is currently looking at in the table view. Luckily, Apple has made this easy for us by providing a great utility class called NSFetchedResultsController.

So, start by opening up FailedBanksListViewController.h, removing out our old NSArray of failedBankInfos, and adding a new NSFetchedResultsController instead:

@interface FailedBanksListViewController : UITableViewController <NSFetchedResultsControllerDelegate> { NSFetchedResultsController *_fetchedResultsController; NSManagedObjectContext *_context; }   @property (nonatomic, retain) NSFetchedResultsController *fetchedResultsController; @property (nonatomic, retain) NSManagedObjectContext *context;   @end

In the synthesize section, remove old failedBankInfos synthesize statement and add:

@synthesize fetchedResultsController = _fetchedResultsController;

Then before we forget, set fetchedResultsController to nil inside the dealloc method:

self.fetchedResultsController.delegate = nil; self.fetchedResultsController = nil;

Another awesome thing about NSFetchedResultsController is you an set it to nil upon viewDidUnload, which means that all of the data that is in memory can be freed up in low memory conditions (and the view is offscreen). All you have to do is set it to null in viewDidUnload (and make sure it’s re-initialized in viewDidLaod):

- (void)viewDidUnload { self.fetchedResultsController = nil; }

Ok, now onto the fun part – creating our fetched results controller! We are going to override the get method for our property so that it checks to see if the fetched results controller exists first. If it does exist, it will return it, otherwise it will create it.

Add the following function toward the top of the file:

- (NSFetchedResultsController *)fetchedResultsController {   if (_fetchedResultsController != nil) { return _fetchedResultsController; }   NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init]; NSEntityDescription *entity = [NSEntityDescription entityForName:@"FailedBankInfo" inManagedObjectContext:_context]; [fetchRequest setEntity:entity];   NSSortDescriptor *sort = [[NSSortDescriptor alloc] initWithKey:@"details.closeDate" ascending:NO]; [fetchRequest setSortDescriptors:[NSArray arrayWithObject:sort]];   [fetchRequest setFetchBatchSize:20];   NSFetchedResultsController *theFetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:_context sectionNameKeyPath:nil cacheName:@"Root"]; self.fetchedResultsController = theFetchedResultsController; _fetchedResultsController.delegate = self;   [sort release]; [fetchRequest release]; [theFetchedResultsController release];   return _fetchedResultsController;   }

This should look pretty familiar to the code that we used to have in viewDidLoad, to create a fetch request to pull out the FailedBankInfo objects. However, there’s a lot of new stuff here so let’s discuss…

First, any time we use an NSFetchedResultsController, we need to set a sort descriptor on the fetch request. A sort descriptor is just a fancy term for an object we set up to tell Core Data how we want our results sorted.

The cool thing about sort descriptors is they are very powerful. Not only can you sort on any property of the object you are returning, but you can sort on properties of related objects – just like we see here! We want to sort the objects based on the close date in the FailedBankDetails, but still only receive the data in FailedBankInfo – and Core Data can do this!

A very important part is the next statement – to set the batch size on the fetch request to some small size. In fact, this is the very reason we want to use the fetched results controller in this case. This way, the fetched results controller will only retrieve a subset of objects at a time from the underlying database, and automatically fetch mroe as we scroll.

So once we finish tweaking the fetch request with the sort descriptor and batch size, we just create a NSFetchedRequestController and pass in the fetch request. Note it takes a few other parameters too:

• For the managed object context, we just pass in our context.
• The section name key path lets us sort the data into sections in our table view. We could sort the banks by State if we wanted to, for example, here.
• The cacheName the name of the file the fetched results controller should use to cache any repeat work such as setting up sections and ordering contents.

So now that we have a method to return a fetched results controller, let’s modify our class to use it rather than our old array method. First, update viewDidLoad as follows:

- (void)viewDidLoad { [super viewDidLoad];   NSError *error; if (![[self fetchedResultsController] performFetch:&error]) { // Update to handle the error appropriately. NSLog(@"Unresolved error %@, %@", error, [error userInfo]); exit(-1); // Fail }   self.title = @"Failed Banks";   }

All we do here is get a handle to our fetchedResultsController (which implicitly creates it as well) and call performFetch to retrieve the first batch of data.

Then, update numberOfRowsInSection:

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section { id <NSFetchedResultsSectionInfo> sectionInfo = [[_fetchedResultsController sections] objectAtIndex:section]; return [sectionInfo numberOfObjects]; }

And update cellForRowAtIndexPath like the following:

- (void)configureCell:(UITableViewCell *)cell atIndexPath:(NSIndexPath *)indexPath { FailedBankInfo *info = [_fetchedResultsController objectAtIndexPath:indexPath]; cell.textLabel.text = info.name; cell.detailTextLabel.text = [NSString stringWithFormat:@"%@, %@", info.city, info.state]; }   - (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] autorelease]; }   // Set up the cell... [self configureCell:cell atIndexPath:indexPath];   return cell; }

Note we split out part of the logic into a separate configureCell method – this is because we’ll need it later.

Ok one more thing – we need to implement the delegate methods for the NSFetchedResultsController. The good news is these are mostly boilerplate – I literally copied and pasted these from an Apple sample. So just add these methods to the bottom of your file:

- (void)controllerWillChangeContent:(NSFetchedResultsController *)controller { // The fetch controller is about to start sending change notifications, so prepare the table view for updates. [self.tableView beginUpdates]; }     - (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type newIndexPath:(NSIndexPath *)newIndexPath {   UITableView *tableView = self.tableView;   switch(type) {   case NSFetchedResultsChangeInsert: [tableView insertRowsAtIndexPaths:[NSArray arrayWithObject:newIndexPath] withRowAnimation:UITableViewRowAnimationFade]; break;   case NSFetchedResultsChangeDelete: [tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade]; break;   case NSFetchedResultsChangeUpdate: [self configureCell:[tableView cellForRowAtIndexPath:indexPath] atIndexPath:indexPath]; break;   case NSFetchedResultsChangeMove: [tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade]; [tableView insertRowsAtIndexPaths:[NSArray arrayWithObject:newIndexPath] withRowAnimation:UITableViewRowAnimationFade]; break; } }     - (void)controller:(NSFetchedResultsController *)controller didChangeSection:(id <NSFetchedResultsSectionInfo>)sectionInfo atIndex:(NSUInteger)sectionIndex forChangeType:(NSFetchedResultsChangeType)type {   switch(type) {   case NSFetchedResultsChangeInsert: [self.tableView insertSections:[NSIndexSet indexSetWithIndex:sectionIndex] withRowAnimation:UITableViewRowAnimationFade]; break;   case NSFetchedResultsChangeDelete: [self.tableView deleteSections:[NSIndexSet indexSetWithIndex:sectionIndex] withRowAnimation:UITableViewRowAnimationFade]; break; } }     - (void)controllerDidChangeContent:(NSFetchedResultsController *)controller { // The fetch controller has sent all current change notifications, so tell the table view to process all updates. [self.tableView endUpdates]; }

Compile and run your project, and it should look the same. However, if you examine the debug output you will see something very amazing…

SELECT 0, t0.Z_PK FROM ZFAILEDBANKINFO t0 LEFT OUTER JOIN
    ZFAILEDBANKDETAILS t1 ON t0.ZDETAILS = t1.Z_PK
    ORDER BY t1.ZCLOSEDATE DESC
total fetch execution time: 0.0033s for 234 rows.

SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZNAME, t0.ZSTATE, t0.ZCITY,
    t0.ZDETAILS FROM ZFAILEDBANKINFO t0 LEFT OUTER JOIN
    ZFAILEDBANKDETAILS t1 ON t0.ZDETAILS = t1.Z_PK WHERE
    t0.Z_PK IN  (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
    ORDER BY t1.ZCLOSEDATE DESC LIMIT 20
total fetch execution time: 0.0022s for 20 rows.

SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZNAME, t0.ZSTATE, t0.ZCITY,
    t0.ZDETAILS FROM ZFAILEDBANKINFO t0 LEFT OUTER JOIN
    ZFAILEDBANKDETAILS t1 ON t0.ZDETAILS = t1.Z_PK WHERE
    t0.Z_PK IN  (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
    ORDER BY t1.ZCLOSEDATE DESC LIMIT 20
total fetch execution time: 0.0017s for 20 rows.

You can see here that behind the scenes, the NSFetchedResultsController is getting a list of IDs from FailedBankInfo, in the proper sort order. Then, as the user pages through the table, it loads one batch at a time – rather than loading all of the objects into memory at once!

This would have been a lot more code to do with raw SQLite – and is just one of the many reasons why using Core Data can save time and increase performance.

Show Me The Code!

Here is a sample project with all of the code we have developed in the above tutorial.