from: iphone -> ipad; a quick guide.
Posted in All Mac, ipad, iphone, Technology, user experience, whatever on 08/30/2011 03:28 pm by Nir Pengas
it’s time to expand your iphone app and introduce it on the ipad. that is an interesting move for any product as the ipad is not an iphone – it is used for different things at different circumstances. yeah – you are going to practically re-think your app… which is great because you get to revisit your code and make sure your pipeline is tight, secure, fast and reliable. all that with the elegance of the ipads – split view controllers
where do one starts? well, you can start be designing your app for the ipad and take by thinking about the following:
orientation, layout and gestures. all of which vary significantly from the iphone (unfortunately). side note: one thing i really like about webOS is that you develop your mobile app once and the system takes care of adjusting the interface to a slated device.
next thing to learn about the ipad is it’s split views, popovers and specific hardware features – all of which are ipad unique. you will need to use conditional coding to learn if a specific hardware feature you are looking for is available. this is necessary as you will need to load the right resources to handle that hardware. more specifically one should write conditional coding for:
resources: in your code, recognize which platform is running and load the right nib files. you will also need to load the right graphics that match the screen size and resolution.
classes: check for class availability based on the device you are running on as some are iPad/iPhone specific.
methods: weak-link any device specific methods and perform a check at runtime for the availability of that method and wether the object responds to a specific selector.
hardware: test for cmarea/gps/gyro support before utilizing it.
okay – we are done with the overview. let’s roll up our sleeves and dig right into it.
first thing’s first – lets let xcode help us start the process by duplicating the current target (an iphone target) into an ipad one.
right click on your target and choose “duplicate”. two options here – duplicate only and duplicate and transitoin to ipad. let’s go with the later.
what xcode does here is create a new virtual folder (i.e. group) called “Resources-iPad” and copies the main nib file there. xcode really takes care of the main nib file and creates it for us. no other nib files to be touched. why? because the rest of the nib files are usually tied right into apps view controller so xcode leaves it up to us to define both the view and it’s controller. xcode sets the targeted device family (TDF) build settings to iphone/ipad and modify the base SDK of the project which will support both device types. no need to touch nor worry about the deployment target. you will see a new plist for the ipad app with it’s relevant settings.
in order to see it in action – run the app using the ipad simulator. what you will see is the iphone app running inside the ipad simulator and you can x2 time it to fit. boooo. one more step necessary (thanks apple for leaving it up to us) is to update the scheme to use the new and shiny ipad target. so go ahead and duplicate your iphone scheme (or create a new one) and under run - choose the ipad executable. boom. wait – it really looks bad here.
well – as you may know iOS uses the MVC design pattern heavily. you may not know that MVC is actually a compound design pattern which includes 5 patterns. luckily this abstraction makes the process of porting an iphone app to an ipad a bit easier, as potentially one needs to take care of the view – making sure the right outlets are updated based on the design of the UI, and also heavily touch upon the controller to see which device is used and then follow a specific code path to match. the good news is the model can stay untouched 
if you are happy with the IBOutlet you currently have on the iphone and would like to only use those (i cannot image why, but yeah…) all you need to do at this point is adjust the springs and struts in the size inspector when loading up your nib in IB. you should also make sure to support the orientations required for the app. in order to do this you will need to implement shouldAutorotateToInterfaceOrientation: and test for the device running the code and allow rotation. if you have singleton object place this code in it’s header file:
#define IS_IPAD (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) #define IS_IPHONE (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone)
ipod touch returns UIUserInterfaceIdiomPhone. FYI.
or place it wherever works for you, as long as you have access to this macro from wherever. this is useful as you will need to update your controllers to test for the hardware running and follow a specific code path to update your view and outlets.
one example of using this code and auto rotating is this:
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
if (IS_IPHONE)
{
if (interfaceOrientation == UIInterfaceOrientationPortrait ||
interfaceOrientation == UIInterfaceOrientationPortraitUpsideDown)
{
return YES;
}
}
if (IS_IPAD)
{
if (interfaceOrientation == UIInterfaceOrientationLandscapeLeft ||
interfaceOrientation == UIInterfaceOrientationLandscapeRight)
{
return YES;
}
}
return NO;
}
pretty easy and straight forward right? moving along.
cautionary tale:
the app now must be careful with the symbols it uses. if you want to use UISplitViewController while running on iOS 3.1 – your app will crash as there are no split VCs on 3.1.
the way you should be thinking about this is by mentally tuning into the ‘runtime checks’ zone, where you will test if a particular symbol exists. more about that later.
updating VC and views:
this is where the bulk of the work really is – redoing your views and adding code (or creating new) view controllers. what can we do – the view size varies between the iphone and the ipad and that certainly needs to be taken into consideration. so start off by redesigning the views for the ipad. if you plan on scaling the existing view could work okay, but more often than not will not be the result you are hoping for. think of it this way – the new ipad interface should make use of the new available space and the elements which only exist on the ipad (splitVCs and popovers for example). the outcome is good UI and top UX.
also consider the following. for view controllers:
a) create new nib files for each device (if you use nib files that is).
b) if you code your views – make sure you support both devices when you do so.
for views:
a) if you override drawrect: make sure the method can draw to different view sizes.
b) if you implemenet the layoutSubviews method, the code must adapt to different view sizes.
symbol checking during runtime: if deep down inside you had hoped that this step will somehow be avoidable – fear not runtime checks for newer symbols is easy as pie and is the type of topic you can discuss with your boss and sound really clever.
all of this is under the assumption you support different versions of the OS. just like a good soldier – you MUST protect your code from using symbols that do not exist. this happens all the time when you update an app to use new features and want to continue to support previous versions running on older OSs. all you need to do is create different code paths to follow, based on the OS currently running on the device executing your app. if you don’t do that your app is guaranteed to crash and that is not something us pros do, so let us quickly look into an example of how one goes about creating a code path when checking for newer symbols during runtime:
if you are linking against iOS 4.2 you are in luck my friend. that version has a weak linking support built right in, which allows you to check for the existence of a given class object and determine if it’s usable to you. like so:
if ([UIPrintInteractionController class]) {
// Create an instance of the class and use it.
}
else {
// The print interaction controller is not available.
}
seriously now – how simple was that?
bare in mind that if you want to use this feature of the OS you must build your app with LLVM and Clang.
deployment target should be 3.1 or later. sorry.
if your app links against < 4.1, use NSClassFromString to see if a class is defined. if nil is returned – you’re shit out of luck.
for example:
Class splitVCClass = NSClassFromString(@"UISplitViewController");
if (splitVCClass)
{
UISplitViewController* mySplitViewController = [[splitVCClass alloc] init];
// Configure the split view controller.
}
for testing if an object can be sent a specific message (i.e. has implemented that method), use the oh so convenient instancesRespondsToSelector: class method (yes, it is a class method, it’s not a type).
if you are a registered iphone developer and have not done so – check out the SDK compatibility guide by apple.
runtime checks –> conditional code paths:
based on the interface idiom described earlier – let’s start creating cool code paths to support both devices. a simple if-else statement will do just fine thank you very much. moving right along.
This concludes this first steps required to port your app from iphone to an ipad. next is a quick rundown on how to use split view controllers in your ipad app.
AmpliTube iRig is just one of those ideas that can make people buy an iPhone. not often do i get to see apps for mobile that can serve as game changers and this is – in my humble opinion – is. as a life long big fan of music, i both play and compose music, and let me tell you: owning equipment is not something i enjoy. in fact, i do not have an amp for my guitar because i can’t be bothered to carry it around… let alone have multiple effects, pedals and what have you.