After my last post some have asked for my home screens, so here they are.
Tag Archives: iPad
Extra space/row in UIPopoverController content?
If you’re using UISplitViewController in your iPad/Universal apps, you probably implemented the UISplitViewControllerDelegate to add a UIBarButtonItem to the detail view controller’s toolbar to display a popover. The popover might have some extra space before the first row after you rotate the simulator or the iPad from landscape to portrait, took me a few hours to figure this out, it is because the navigation bar’s translucent property is set to YES, set it to NO before you add the button and you won’t see the extra space. Also, if you instantiate the nav bar in your NIB, leave its style asdefault in Interface Builder, otherwise the popover will be messed up on load when you launch the app in portrait orientation. Set them in code instead.
- (void)viewWillAppear:(BOOL)animated { [super viewWillAppear:animated]; self.navigationController.navigationBar.barStyle = UIBarStyleBlack; self.navigationController.navigationBar.translucent = YES; } #pragma mark - #pragma mark UISplitViewControllerDelegate methods - (void)splitViewController:(UISplitViewController *)svc willHideViewController:(UIViewController *)aViewController withBarButtonItem:(UIBarButtonItem *)barButtonItem forPopoverController:(UIPopoverController *)pc { self.navigationController.navigationBar.translucent = NO; //if I don't do this we get extra space in popover barButtonItem.title = @"Some Title"; // Keep references to the popover controller and the popover button, and tell the detail view controller to show the button. self.popoverController = pc; self.rootPopoverButtonItem = barButtonItem; UIViewController <SubstitutableDetailViewController> *detailViewController = [splitViewController.viewControllers objectAtIndex:1]; [detailViewController showRootPopoverButtonItem:rootPopoverButtonItem]; } - (void)splitViewController:(UISplitViewController *)svc willShowViewController:(UIViewController *)aViewController invalidatingBarButtonItem:(UIBarButtonItem *)barButtonItem { //setting it back to black translucent self.navigationController.navigationBar.barStyle = UIBarStyleBlack; self.navigationController.navigationBar.translucent = YES; // Nil out references to the popover controller and the popover button, and tell the detail view controller to hide the button. UIViewController <SubstitutableDetailViewController> *detailViewController = [splitViewController.viewControllers objectAtIndex:1]; [detailViewController invalidateRootPopoverButtonItem:rootPopoverButtonItem]; self.popoverController = nil; self.rootPopoverButtonItem = nil; }
Speeding up Core Data-based UITableViewController
It is pretty common for an iPhone/iPad app to make an API call to a server, get the JSON response data back, parse that data, and display it in a table view. The usual way to do this looks like this:
- (void)apiCall { NSString *urlString = [[NSString alloc] initWithFormat:@"%@/some_models/some_action.json", apiEndpoint]; NSURL *url = [[NSURL alloc] initWithString:urlString]; NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url]; [request setHTTPMethod:@"GET"]; [NSURLConnection connectionWithRequest:request delegate:self]; [url release]; [urlString release]; }
This fires off the API call asynchronously, and then you implement some delegate methods like this:
- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response { responseData = [[NSMutableData alloc] initWithCapacity:[response expectedContentLength]+100]; } - (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data { [responseData appendData:data]; } - (void)connectionDidFinishLoading:(NSURLConnection *)connection { NSString *jsonString = [[NSString alloc] initWithData:responseData encoding:NSUTF8StringEncoding]; [self dictionaryToCoreData:[jsonString JSONValue]]; //this parses the JSON data and persists into Core Data [jsonString release]; [responseData release]; }
This approach works fine, but when you run it on the real devices, you might notice that the table view locks up when you go between the navigation flow. Basically the table view ignores user inputs until everything above is finished. This is because everything is performed on the main thread and it locks up the UI. The asynchronous NSURLConnection method used above doesn’t like to be used in a background thread, and there is really no reason to do things asynchronously if you’re working in the background, conveniently, there is a +sendSynchronousRequest method that waits until we get the response and data in NSURLConnection. To perform the above API call in a background thread, the code is actually much simpler:
- (void)apiCall { [self performSelectorInBackground:@selector(backgroundApiCall) withObject:nil]; } - (void)backgorundApiCall { @synchronized(self) { NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; // Top-level pool NSString *urlString = [[NSString alloc] initWithFormat:@"%@/some_models/some_action.json", apiEndpoint]; NSURL *url = [[NSURL alloc] initWithString:urlString]; NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url]; [request setHTTPMethod:@"GET"]; NSURLResponse *resp; NSError *error; NSData *responseData = [NSURLConnection sendSynchronousRequest:request returningResponse:&resp error:&error]; // you should probably do some error handling here NSString *jsonString = [[NSString alloc] initWithData:responseData encoding:NSUTF8StringEncoding]; [self dictionaryToCoreData:[jsonString JSONValue]]; [jsonString release]; [url release]; [urlString release]; [pool release]; } }
Now, when the table view is first loaded, it displays the stale data in Core Data, the API call is fired off in the background, and when we get data back from the call the table view is updated with the new data. Stale data is better than locked up UI.
Notice the very first time you run the app the table view will be empty until the background thread finishes, if this bothers you, you can preload the database with sample data. In our app we can’t really do this as the data is unique to the user, but it might make sense for you to ship your apps with pre-loaded data.
re: section 3.3.1
In developing an iPhone app for Pullfolio, we initially went with Titanium as Ray had used it before at Intridea, and we are familiar with web technologies. With that we were able to almost finish the app within a week. However, we quickly found limitations of the framework, more specifically, it was non-trivial to make a Photos.app-like thumbnails view without using webview, and to make a single photo view with slideshow that supports pinch/zoom gestures, lazy-loading different versions of images off the Internet on-demand, proved to be close to impossible without us implementing more native UIKit components for the framework.
So we learned and switched to Objective-C, and will never look at a cross-compile option for iPhone and iPad apps again. I agree with @gruber and Jobs, cross-compile solutions mostly yield low quality apps. Also, it always takes a short while for 3rd party solutions to catch up with the latest SDK features, so you will be a step behind your competitors. I think cross-compiling is okay if you’re a consultant building apps for clients who wanted iPhone apps. But if you’re a app developer who wants to write something original and something that provides rich UX, going native the the only way to go. Learning new languages, tools, and frameworks is part of the business of being developers. (we all did switch from php to rails/django, or vb to c#, cvs to svn and then to git).
Also, if you don’t like the app store limitations, you can always develop for the web. With the exception of Flash, Safari on iPhone and iPad works great, instead of using Facebook.app I just hit it in Safari, it works much better than their app IMO. A ton of sites have already made themselves iPad-friendly.
iPad apps
I spent the most of the past 2 days playing with my iPad. The apps I’ve tried so far are pretty amazing. Other than the obvious apps such as Netflix and ABC Player, here are some apps that I find really useful:
GoodReader for iPad ($0.99 limited time intro price, iPad-only). This app lets you move and read large PDF documents on the iPad, it has an iPad-optimized reader. You can search, there is even a button to dim the brightness of the display. To transfer files into GoodReader all you have to do is to go into the app and switch on WiFi transfer, and then you can connect to it in Finder on a Mac. You can also transfer files in iTunes, or link up your Google Docs, Box.net, Dropbox (I’m a huge user of Dropbox!) accounts and download from them. You can also get to any WebDAV servers inside the app. You can even connect to your Gmail or other email accounts and download your attachments into GoodReader!
You get this under the Apps tab in iTunes:
Kindle (free, universal version for both iPhone/Touch and iPad) and iBooks (free, iPad-only). Books in iBooks look cool, the Delicious Library look-alike bookshelf is a nice touch. But Amazon has a much larger selection of books available for the Kindle. I’d held out not to buy a Kindle for so long, so it’s great to have ebooks options on the iPad. The Kindle iPad app dims the background and the book lids up the kid’s face when you use it at night.
NewsRack ($4.99, universal version). On the iPhone I use Google Reader in Safari and it works okay, but it doesn’t work as well on an iPad, and an RSS reader with offline sync is important especially because this iPad is wifi-only. NewsRack can sync with my Google Reader account, and by that I mean it can grab my subscriptions, maintain read/unread data, and even share articles back at Google Reader. It also has sharing features to email article, add to Instapaper, Readitlater, Twitter, Delicious, etc. It’s a universal app so I get to use it on my iPhone as well, great deal for $4.99 IMO.
Instapaper Pro ($4.99, universal). I am a long time user of Instapaper, Tweetie has Instapaper support so I save a ton of links in tweets that I want to read later. The Instapaper Free app worked fine for me on the iPhone, but the Pro version is universal and is iPad-optimized. If you don’t use Instapaper you really should.
1Password Pro ($14.99, universal), or 1Password for iPad ($6.99, iPad-only). If you use a Mac, you have to use 1Password. I bought a family pack of the desktop version, and the Pro version after iPhone 3.0 to get the ability to copy password into clipboard easily. I think I paid a lot less than $15, and at some point it was even free for a short while. I am glad Agile Web Solutions did the right thing and made the Pro version universal (unlike Cultered Code with Things, which I’ll talk about later).
Photo Pad: Flickr ($3.99, iPad only). If you use Flickr heavily for photo sharing and storage, you will like this app. It basically helps you sync your photosets on Flickr onto the iPad and displays them in amazing resolutions on the iPad’s gorgeous IPS display. There is no slideshow feature, so you can’t use it as a digital photo frame, and you can’t search photos on Flickr by tags (you can search the photos already downloaded by tags though).
Bloomberg for iPad (free, iPad-only, but there is an iPhone version too). This app pretty much turns your iPad into a Bloomberg terminal, well, there is no Bloomberg IM and it’s not really the real thing, but it’s pretty damn close, and it’s free!
SketchBook Pro ($7.99, iPad-only). This is the best sketching/drawing app on the iPad at the time of this writing. Really amazing app, definitely worth the $7, considering a comparable desktop sketching app will no doubt cost a lot more. I wish iPad was pressure sensitive though, it still can’t replace a Wacom tablet for serious illustrating or photo retouching work.
There is one app that pisses me off – Things for iPad. Things is my GTD app and I use it heavily. I bought a family pack ($75) for the desktop version , as well as the iPhone version ($10). Now instead of releasing a universal version upgrade, they wanted $20 for Things for iPad. $20 is just a bit much even though the app looks gorgeous and I’m sure it works really damn well. For now I’m going to run the iPhone version on the iPad until I can’t stand it anymore.