This is what my TV remote control looks like (with an Apple keyboard for scale).

It’s horrible. It’s covered with buttons that never get used, and so many are crammed onto the device that they’re too small to use easily. The whole thing is just the right size and shape to fall down between the sofa cushions, too.

The things I use the remote for (in order of priority) are:

• power on and off
• channel selection
• volume adjustment
• mute on/off
• changing aspect ratio

The other frustration is that I’m driving an interface that’s 3 metres away – and every onscreen interface I’ve ever seen is butt-ugly.

My iPad, on the other hand, spends a lot of time sat on the sofa next to me. And its interface is anything but butt-ugly.   So this is what I want my TV remote to look like. ]

No on-screen controls on the TV itself – all five functions are put front and centre on the iPad.

There are four main areas:

the basic controls

Power, volume, mute and aspect.

the channel area

This shows the channel logo and the current programme being shown. It’s a scrollable list – tapping and holding the channel logo will switch channels. The current channel is highlighted.

the schedule area

This scrolls around in tandem with the channel view. Tapping on the programme reveals a pop-up with programme details pulled from the channel guide.

the PVR area

This is a scrollable ribbon of programmes that have been recorded – tapping on the programme will reveal a pop-up with player controls. Tapping play will fire up the programme.

The second screen

The “second screen” view is for combining things like the red button functions (although I hardly ever use these) and online activity like Twitter, or Wikipedia or even the broadcaster’s site, if any of them ever got around to doing second screen activities “properly”.

Things that I’m not entirely sure about:

• how switching between the main view and “second screen” view would work.
• how and where the “red button” functions would best live.

All of this is predicated on the TV being completely slaved to the remote, of course. So it could happen one of two ways – either a TV manufacturer comes up with a model that has a corresponding app; or some other device sits in between and mediates between the iPad and the TV.

Presumably that would translate commands over wifi from the iPad into IR commands to the TV.

I’d buy something like this. Is anyone going to make it?

[Caveat - this is based on half-an-hour of sketching, and some hacking around with Omnigraffle.  No, it's not polished, or the product of extensive UX workshops. But it's still better than that lump of gray plastic crap that came with my TV.]

The new Path app has hit the App Store, and the updated UI is GORGEOUS.   I was quite intrigued by the little touches, particularly the little clock icon that slides up and down the right-hand side of the screen as you scroll down the timeline. It looks really neat, and it got me wondering how it was done.

Turns out, it’s actually not that difficult (although it’s still a lovely UI touch even so).

The main view in Path is a heavily-customised UITableView sat inside a UINavigationController (although the UINavigationController bit is irrelevant at the moment). UITableViews are themselves heavily-customised subclasses of UIScrollView, which means that all the goodies that a UIScrollView provides are available to instances of UITableView.

There’s one particular goodie that’s relevant here. This is UIScrollView's contentOffset property, which shows how far from the origin the scrollView – or in this case, our tableView – has been scrolled. When the table’s at the top, the contentOffset's y value will be zero – but if you had a table that was (say) 1000 pixels high, that contentOffset would gradually increase until at the very bottom of the table it had a y value of 1000 pixels.

Another property that’s relevant here is the tableView’s contentSize property. If you access that after the table has finished loading – ie in the viewDidAppear method – then this will return the total height of the table with all rows fully-populated.

- (void)viewDidAppear:(BOOL)animated
{
[super viewDidAppear:animated];
 
maxTableHeight = self.tableView.contentSize.height;
frameTableHeight = self.tableView.frame.size.height;
workingTableHeight = maxTableHeight - frameTableHeight - 64;
 
NSLog(@"TableView maxTableHeight = %f", maxTableHeight);
NSLog(@"TableView frameTableHeight = %f", frameTableHeight);
NSLog(@"TableView workingTableHeight = %f", workingTableHeight);
 
}

Dividing the contentOffset.y value by the contentSize.height will give you how far down the tableView things have scrolled as a percentage value. When the table first loads, the contentOffset.y value will be zero, therefore we’d be 0% down the table. At the bottom, we’d be 100% of the way – and obviously varying percentages along the way.

The third value that will help out here is the height of the table’s frame – in other words, how much of the overall screen the tableView occupies. If you’ve got a status bar and a navigation bar, that’s the full height of an iPhone screen – 480 pixels – less 20 pixels for the status bar and 44 pixels for the navigation bar – a total frame height of 416 pixels.

Now imagine that you created a UIView of some description, and “floated” it as the front-most view so that it appeared on the right-hand edge of the screen. (If it’s a subView of the main window, then the origin remains constant and doesn’t move with the table itself.) It’ll have an origin with an Y position and a Y position – x will be somewhere between 0 and 320, depending on how far right it needs to be placed. And the Y position will control how far up or down the screen it appears.

If we calculate the Y position by taking the height of the tableView's frame and multiplying it by the percentage that the table has been scrolled, the UIView will appear to move up and down the screen in proportion to how fat the tableView has scrolled. It’ll start at the top of the screen when the tableView is at the top, and slide down towards the bottom as the tableView is scrolled. It won’t leave the visible screen regardless of how long the tableView actually is, because we’re calculating the percentage of the tableView's frame rather than its content size.

Because UITableView inherits from UIScrollView, it means we can use the scrollViewDidScroll: method of UIScrollViewDelegate as the “trigger” for calculating how far things have scrolled, and adjusting the position of the UIView with the little clock icon.

-(void)scrollViewDidScroll:(UIScrollView *)scrollView {
 
// Work out positions
currentTablePosition = scrollView.contentOffset.y;
currentTablePositionPercentage = (currentTablePosition / workingTableHeight);
 
// Work out position of "block"
float blockOffset = (frameTableHeight * currentTablePositionPercentage);
 
float newYpos = 64 + blockOffset;
 
NSLog(@"tableView's scroll position = %f", currentTablePosition);
NSLog(@"blockOffset position = %f", blockOffset);
NSLog(@"current table position %%age = %f", currentTablePositionPercentage);
 
NSLog(@"New xpos = %f", newYpos);
 
theBlockView = theAppDelegate.theBlockView;
theBlockView.frame = CGRectMake(theBlockView.frame.origin.x, newYpos, theBlockView.frame.size.width, theBlockView.frame.size.height);
 
}

This is all *very* crude, not least because the calculations don’t take into account the size of the UIView that you’re moving around. Nor do they account for the fact that you can scroll a tableView or scrollView *beyond* 0% and 100% as it bounces at the top and bottom extents.

Path also takes things one stage further by figuring out which row the little icon thing is hovering over, and changing the value of the clock to reflect when the contents of that row were updated. There’s also some very neat animation as the clock times change by spinning the hands. But the basic principles of figuring out where the icon slider should be still hold.

Update – Florian Mielke has produced a much better explanation (and a library on Github) here

The project I’m working on at the moment is Core Data-based, and I’m (attempting) to built it using a test-driven approach. In practice, there’s at least as much development-driven testing as there is test-driven development, but I’m using the fact that I’m on a learning curve as my get-out-of-jail-free card.

I’m using GHUnit and OCMock as my test frameworks. Testing the view controllers and so on is fairly straight-forward so far, but I hit a major bump in the road when I started to try and test the Core Data related parts.

While the app itself was working fine, the tests steadfastly refused to return any data. No errors, just empty result sets.

What I’d omitted to do in my testing frenzy was set up the Core Data environment correctly in my tests. You can’t, as it turns out, rely on the app code creating it – you have to do so explicitly within your test suite.

For the benefit of my outsourced memory and any subsequent Google hits, this is how I got it to work.

Firstly, you need to import the CoreData headers:

#import <CoreData/CoreData.h>

and the headers for your NSManagedObject classes:

#import "Trial.h"

Then, add and synthesise a property to hold the Managed Object Context when it’s created:

@property (nonatomic, retain) NSManagedObjectContext *moc;
@synthesize moc;

Because I’m using GHUnit, the methods in my test templete looks like this:

-(void)testSomething {
  // This test should do something eventually
}
 
#pragma mark - Housekeeping
 
- (BOOL)shouldRunOnMainThread {
    // By default NO, but if you have a UI test or test dependent on running on the main thread return YES.
    // Also an async test that calls back on the main thread, you'll probably want to return YES.
    return NO;
}
 
- (void)setUpClass {
    // Run at start of all tests in the class
}
 
- (void)tearDownClass {
    // Run at end of all tests in the class
}
 
- (void)setUp {
    // Run before each test method
}
 
- (void)tearDown {
    // Run after each test method
}

The key methods are setupClass and tearDownClass, which get run at the start and end of the test suite. These is where you create and destroy the Managed Object Context:

- (void)setUpClass {
    // Run at start of all tests in the class
    NSManagedObjectModel *mom = [NSManagedObjectModel mergedModelFromBundles:[NSBundle allBundles]];
    NSPersistentStoreCoordinator *psc = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:mom];
 
    GHAssertTrue((int)[psc addPersistentStoreWithType:NSInMemoryStoreType configuration:nil URL:nil options:nil error:NULL], @"Should be able to add in-memory store");
 
    self.moc = [[NSManagedObjectContext alloc] init];
    self.moc.persistentStoreCoordinator = psc;
 
    [self createSeedData];
}

There’s a subtlety when creating the managed object model – this needs to load all bundles, hence the [NSBundle allBundles] parameter.

- (void)tearDownClass {
    // Run at end of all tests in the class
    self.moc = nil;
}

This creates a sandbox MOC which you can mess about with to your heart’s content – doing things like seeding a data set:

-(void)createSeedData {
 
    NSArray *dataArray = [NSArray arrayWithObjects:@"One", @"Two", @"Three", @"Four", @"Five", @"Six", @"Seven", @"Eight", nil];
 
    for (int i=0; i < [dataArray count]; i++) {
 
		Trial = [Trial alloc] initWithData:[dataArray objectAtIndex:i];
 
		// Set up each trial - 4 get "inprogress" status
                // and 3 get "completed" status
 
	}
 
}

What I’m doing here is creating 8 Trial objects, and setting 4 of them as in progress and 3 as completed (the detail isn’t that relevant for this example). This gets used later to test that the predicates selecting the Trials is working correctly.

From here, it’s simple enough to start testing (because I’m paranoid, I added a test to check that the seed data was created correctly):

-(void)testSeedDataIsCreatedCorrectly {
 
    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
    NSEntityDescription *entity = [NSEntityDescription entityForName:@"Trial" inManagedObjectContext:self.moc];
    [fetchRequest setEntity:entity];
 
    NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"id" ascending:NO];
    NSArray *sortDescriptors = [[NSArray alloc] initWithObjects:sortDescriptor, nil];
 
    [fetchRequest setSortDescriptors:sortDescriptors];
 
    NSError *error = nil;
    NSMutableArray *mutableFetchResults = [[self.moc executeFetchRequest:fetchRequest error:&error] mutableCopy];
    if (mutableFetchResults == nil) {
        NSLog(@"TrialSelectionVC: executeFetchRequest error: %@", [error localizedDescription]);
    }
 
    int resultsCount = [mutableFetchResults count];
    GHAssertEquals(resultsCount, 8, @"should be 8 objects in the test data, found %d", [mutableFetchResults count]);
}

Testing the relevant bit of the view controller means injecting the test MOC into the class. In the production code, the MOC that’s assigned to the view controller’s managedObjectContext is the one that gets created in the AppDelegate – which obviously I don’t have here:

-(void)testTrialsVCretrievesData {
    // Create and fetch trials
    TrialSelectionVC *trialVC = [[TrialSelectionVC alloc] init];
 
    trialVC.managedObjectContext = self.moc;
 
    NSMutableArray *results = [trialVC fetchTrials];
 
    // Assert results are returned
    GHAssertNotNil(results, @"results array is nil");
 
    // Assert that there should be three results
    GHAssertEquals((int)[results count], 3, @"there should be 3 results, %d were returned", [results count]);
 
}

On the face of it, this seems like an awful lot of code just for testing purposes – but it’s paid back as far as I’m concerned. By being able to extract and test the data selection elements of the application in isolation, I’m not having to do that by running the app itself.

It also means that I can afford to bugger about with my data schema, and be able to get an instant check on whether I’ve broken things downstream. In an ideal world that wouldn’t happen anyway, but at least now I’ve got some assurance that the app is somewhat less brittle than it might otherwise be.