Brainbow Apps blog

Automatic creation and modification dates in Core Data models

2011-02-07T00:00:00+01:00

I came to iOS from a Rails background so I was used to having automatic timestamps on most, if not all, of my database models, and as I'm slowly coming up to speed on my Core Data skills, here's one way to bring these magic attributes to Core Data.

We'll create a parent class and inherit it's functionality to the NSManagedObjects we want to have the timestamps. Here's the parent class.

// NSManagedObjectWithTimestamps.h

#import <Foundation/Foundation.h>

@interface NSManagedObjectWithTimestamps : NSManagedObject {
  NSDate *createdAt;
  NSDate *modifiedAt;
}

@property (assign) NSDate *createdAt;
@property (assign) NSDate *modifiedAt;

@end

// NSManagedObjectWithTimestamps.m

#import "NSManagedObjectWithTimestamps.h"

@implementation NSManagedObjectWithTimestamps

@dynamic modifiedAt, createdAt;

- (void)willSave {
  [self setPrimitiveValue:[NSDate date] forKey:@"modifiedAt"];
  if (![self primitiveValueForKey:@"createdAt"])
    [self setPrimitiveValue:[NSDate date] forKey:@"createdAt"];
  [super willSave];
}

@end

Download source code NSManagedObjectWithTimestamps.tar.gz

We have to use setPrimitiveValue to avoid setting off loops of willSave calls. As I found out after an hour or two of googling around. Nice.

Lastly, change your models in your *.xcdatamodel to have the modifiedAt and createdAt attributes as NSDates. You can optionally set default value to now, but it's not nescessary. Make the timestamp-hungry models inherit from NSManagedObjectWithTimestamps instead of just plain old, boring NSManagedObject and go get yourself a little more of ActiveRecord in iOS.

Never-ending paging UIScrollView

2011-01-19T00:00:00+01:00

Paging through views on the iPhone feels great. Flicking your way through the photos app feels easy and natural. And like most iPhone UI controls it's available to developers through UIKit. It's a UIScrollView with paging enabled.

This paging control is obviously made for content divided into pages, and most stuff with pages has both a beginning and an end. But in an app I made (which is waiting for approval), I wanted the pages to continue forever — so as to have a beginning but no end. Here's how I did it. Copying a lot from Apple's own paging scroll view PDF example.

I've made a sample project for you to play with. Here are some of the workings explained — the basic parts.

- (void)viewDidLoad {
  [super viewDidLoad];

  pagingView = [[UIScrollView alloc] initWithFrame:self.view.bounds];
  pagingView.pagingEnabled = YES;
  pagingView.showsHorizontalScrollIndicator = NO;
  pagingView.delegate = self;
  [self.view addSubview:pagingView];

  visiblePages = [[NSMutableSet alloc] init];
  recycledPages = [[NSMutableSet alloc] init];

  [self tilePages];
}

- (void)scrollViewDidScroll:(UIScrollView *)scrollView {
  [self tilePages];
}

First we set up a full-screen scroll view with paging enabled. Also we'll have two sets of views - the one's we're currently rendering and some for recycling. Our scroll view has no end but the phone's RAM have. Finally we call tilePages to set up the content of the scroll view. This method is also called when the scroll view is moving to make the next pages line up and the previous ones eventually go away.

- (void)tilePages {
  CGRect visibleBounds = pagingView.bounds;
  int firstNeededPageIndex = floorf(CGRectGetMinX(visibleBounds) / CGRectGetWidth(visibleBounds));
  int lastNeededPageIndex  = floorf((CGRectGetMaxX(visibleBounds)-1) / CGRectGetWidth(visibleBounds));
  int historyCount = 5;
  firstNeededPageIndex = MAX(firstNeededPageIndex-historyCount, 0);
  lastNeededPageIndex  = MAX(lastNeededPageIndex+1, 1);

  // Recycle unneeded controllers
  for (PageViewController *vc in visiblePages) {
    if (vc.index < firstNeededPageIndex || vc.index > lastNeededPageIndex) {
      [recycledPages addObject:vc];
      [vc.view removeFromSuperview];
    }
  }
  [visiblePages minusSet:recycledPages];

  // Add missing pages
  for (int i = firstNeededPageIndex; i <= lastNeededPageIndex; i++) {
    if (![self isDisplayingPageForIndex:i])
      [self addPageWithIndex: i];
  }

  [self resizePagingViewContentSize];
}

The support methods are have pretty explanatory names, addPageWithIndex and resizePagingViewContentSize, and they do just that. Take a look in the example project for code.

Download example source code
NeverEndingPagingUIScrollView.zip

If you see ways to improve this or use it for anything, I'd love to hear from you.

Uploading images from an iPhone app to Rails

2010-12-16T00:00:00+01:00

Just to get it out of the way here's this articles longer, more buzzword heavy title. How to upload files from an iPhone app with HTTPRiot to a Rails app on Heroku with Paperclip and S3 storage. But that's too much right?

Though it's a great library HTTPRiot doesn't support file uploading. Not directly that is. It's great for talking to a Rails app using for example JSON strings. So what we'll do is convert the image to a Base64 encoded data string and send that along to Rails. Then in Rails we rebuild the image for Paperclip and everything works! Yes, it does! So let's go!

First off we need a way to convert the image data to Base64. The iOS SDK doesn't do this out of the box, but a quick google search will find you some hits including this brilliant solution. Now we can convert the image and make a request using HTTPRiot something like this:

NSData *coverImageData = [NSData dataWithContentsOfFile:PATH_TO_FILE];
NSDictionary *attrs = [NSDictionary dictionaryWithObject:[coverImageData newStringInBase64FromData] forKey:@"cover_image_data"];
NSDictionary *album = [NSDictionary dictionaryWithObject:attrs forKey:@"album"];
NSDictionary *opts = [NSDictionary dictionaryWithObject:[opts JSONRepresentation] forKey:@"body"];
[HRRestModel postPath:@"/albums.json" withOptions:opts object:self];

Up and away it goes! Next up let's update our Rails model to understand what we just sent.

class Album

  has_attached_file :cover_image, :storage => :s3
  attr_accessor :cover_image_data
  before_validation :decode_cover_image_data,
    :if => :cover_image_data_provided?

  private

  def cover_image_data_provided?
    !self.cover_image_data.blank?
  end

  def decode_cover_image_data
    # If cover_image_data is set, decode it and hand it over to Paperclip
    data = StringIO.new(Base64.decode64(self.cover_image_data))
    data.class.class_eval { attr_accessor :original_filename, :content_type }
    data.original_filename = "cover.png"
    data.content_type = "image/png"
    self.cover_image = data
  end

end

That's it for Rails. Now if everything goes right, then back at our iOS app (void)restConnection:(NSURLConnection *)connection didReturnResource:(id)resource object:(id)object will get called and resource will be our album object. HTTPRiot even already parsed the JSON. How's that for a 2010 approach?

Using ImageMagick to create animated GIFs on the iPhone

2010-11-25T00:00:00+01:00

While developing 3 frames of me I had a hard time finding any information on how to generate animated GIFs using Objective-C. After some days of trial and error of just getting any image generation going I found this guy's succesful attempt at building ImageMagick as a static library for the iPhone with support for jpeg, png and tiff. Those are fine, not what we needed, but luckily for us, ImageMagick itself supports GIF out of the box. Yay!

I'm no C-expert, but using ImageMagick's MagickWand API I was able to little by little put something together. In this example we take it that frames is an NSArray with instances of UIImage and then we can do something like this:

MagickWand *mw = NewMagickWand();
MagickSetFormat(mw, "gif");

for (UIImage *img in frames) {
  MagickWand *localWand = NewMagickWand();
  NSData *dataObj = UIImagePNGRepresentation(img);
  MagickReadImageBlob(localWand, [dataObj bytes], [dataObj length]);
  MagickSetImageDelay(localWand, 500);
  MagickAddImage(mw, localWand);
  DestroyMagickWand(localWand);
}

size_t my_size;
unsigned char * my_image = MagickGetImagesBlob(mw, &my_size);
NSData *data = [[[NSData alloc] initWithBytes:my_image length:my_size] autorelease];
free(my_image);
DestroyMagickWand(mw);

Now data is some NSData of our animated GIF. Great! But iOS doesn't support animated gifs. Neither making nor showing them, so well have to write this data to a file, and then show that.

Writing NSData to a file is easy, but finding a correct and writable absolute path can be tricky. This will write the animated GIF to a file in the app's documents directory (which can be setup to be available in iTunes).

NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSMutableString *path = [paths objectAtIndex:0];
[path appendString:@"/animation.gif"];
[data writeToFile:path];

As mentioned, showing animated GIFs is also a problem. My first attempt was to show them using a UIWebView but though this was working on my 3Gs, it turned out to be slow on the iPhone 4 (!) so another solution was to be found.

A great solution for showing animated GIFs is this dutch guy's class that takes a url pointing at an animated GIF and spits out an animated, optimized UIImageView. As easy as this. It even supports remote files out of the box.

NSURL *url = [NSURL fileURLWithPath:path];
UIImageView *imgView = [AnimatedGif  getAnimationForGifAtUrl:url];

BOOM! Success.