Can any one suggest how I can build Universal app for iPad as well iPhone. What all things I should take care of ? How to take care of resource images used ? Is it possible to have same code base should work for iPad as well iPhone.
In the Target->Project->getInfo->Build->target family-> select iPhone/iPad
And make the conditions everywhere whereever you set frame and also the resolution of the image required by iPAD is high.. so as per condition check whether its running on iPad or iPhone and based on that set your frame and image.
hAPPY cODING...
After creating your universal app (see #Suriya's post above) you should figure out in the app delegate whether you have an iPad or iPhone. Here is a simple tutorial to do just that.
Yes, you will need separate nibs and images for an iPad app. But, no, not all the code has to change. You can simply use class inheritance.
Example:
You have a MyTableViewController.h and .m file that work on the iPhone. This table has a custom cell, MyTableViewCell. Now you want your iPad app to get the same information, but display a larger table and a larger table cell. You then subclass your iPhone classes like so: MyiPadTableViewController : MyTableViewController and MyiPadTableViewCell : MyTableViewCell . This way you have access to all of your created functions in the parent class, but you can override how the information is displayed.
If you have a function - (void)doSomething:(id)foo; in your MyTableViewController class, you can use it in your MyiPadTableViewController class without writing any extra code, or override it if necessary. The point is you don't have to change code in two places, so it makes life a lot easier.
Related
i am totally new to iphone and i am trying to create a universal app.
Now I am creating an empty application. According to all tutorials , by checking universal option it should auto create appdelegates for both iphone and ipad.
But all i can see is only one appdelegate . Kindly tell me how can i create both.
Best Regards
Brayden is correct in answering that you almost never need multiple app delegates. All the delegate usually does is handle the moments when the application launches, suspends or terminates. Back in the days when iPhones ran iOS 4.0, and iPads ran iOS 3.2, you might need very different code in the delegate because only iOS 4.0 supported multitasking. Those days are long gone, and your delegate should probably act the same on all devices.
Yes, you sometimes do reach a point where your program must behave differently on iPhone and iPad. Check the idiom at that time and no earlier. Otherwise you're just duplicating code to no purpose.
My most recent app contains almost no special checks for iPhone or iPad. It doesn't even use different XIBs. Instead, my custom views implement layoutSubviews to fill the space available.
That said, once you understand app delegates, maybe you will find a situation where you need them to be different. If you are absolutely certain that your iPhone and iPad behavior will be so wildly divergent, you will need to:
Manually create a new class (preferably inheriting from the existing AppDelegate class)
In your main.m, send the class name of your new delegate to UIApplicationMain depending on the idiom.
See this answer to "Can I create App Delegate file in my project?" to see the changes to main.m.
You really should only be using one AppDelegate for a Universal application. You can use this to share common things that you'll do in there. What exactly do you need multiple AppDelegates for? If you need to do something specific to a device type (i.e. - iPhone or iPad) then you can do a ternary expression like below:
(UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) ? NSLog(#"iPad") : NSLog(#"iPhone");
I currently have an iOS application that was originally developer for the iPhone; it was then decided that it was going to be required for the iPad as well. However, there are not many changes to cater for this (only things such as layout, text size and a few others) - the app is just a bigger version for iPad in reality.
One of the things my app makes use of is a UITableView (with a custom UITableCellView). Each one of these then moves onto a UIView. In order to make it a bit more unique to the iPad, I would like to implement a UISplitView to combine these two, to make better use of the larger screen!
This application was handed to me from a previous developer. A large part (95%) of the UI was coded (and not done in Interface Builder). While I am picking up objective-c, there are still some things which throw me. Therefore, my question to you guys is: would this require a huge change in code if I was to combine my UITableView and UIView into a UISplitView? From what I have seen from playing around with the UISplitView, it doesn't seem so. However, because of all the rest being coded, I think the UISplitView will have to be, is that right? Or can I dump in an xib and string up the coded UITableView and UIView?
Final question, is there a tutorial anyone knows about where they have coded a UISplitView? All of them appear to be using Interface Builder.
I hope that is not too much information!
I have an iPad app that I would like to make Universal, however this seems alarmingly difficult. I've changed things around so that I support both builds, but when building, I get lots of errors about using UIPopOvers. Here're my questions:
Why does UI_USER_INTERFACE_IDIOM() not compile or register on 3.1.3?
Can I conditionally have variables in a class definition based on UI_USER_INTERFACE_IDIOM()?
If not, should I make two different view controllers?
Thanks!
Why does UI_USER_INTERFACE_IDIOM() not
compile or register on 3.1.3?
The UI_USER_INTERFACE_IDIOM macro is only available starting with 3.2. Same restrictions for the userInterfaceIdiom property of UIDevice. This means that you can only get universal application starting with SDK 3.2.
Can I conditionally have variables in
a class definition based on
UI_USER_INTERFACE_IDIOM()?
No. The UI_USER_INTERFACE_IDIOM macro is only a runtime shortcut to get the current UI idiom of the device.
If not, should I make two different
view controllers?
If you have very different UI between the two devices, it is wiser to use two different view controllers, and to create the right one at runtime (in the application controller for example) by using the UI_USER_INTERFACE_IDIOM macro.
I had pretty good luck with just selecting the target then going to Project->Upgrade current target for iPad.
My app is pretty simple, consisting mostly of table views and webviews, but it's worth making a backup and trying...
And yes, you have to submit it as a 3.2 app that can target 3.1.*
There are also a lot of other stuff that you have to do:
Make sure that it can be viewed at any orientation (got rejected the first time for this).
Make sure that you have all the new images created. you have to have 3 or 4 icons, instead of just one like an iPhone app needed. (iPad icon, iPhone icon, small icon for spotlight, etc).
And of course iPad sized screenshots for the store.
A really nice way that I use to test if it's an iPad or iPhone is to check if the device can use a split view controller, since for the forseeable future no device with a screen as small as an iPhone will be able to use the split view controller. I just created a function to do this for me:
+(BOOL)isIpad{ return NSClassFromString(#"UISplitViewController") != nil; }
Then anywhere in my app that I want to display something different depending on device, I just do a check for it:
int width = 150;
if([NabAppDelegate isIpad]){
width = 350;
} else {
width = 150;
}
UILabel *label = [[UILabel alloc] initWithFrame:CGRectMake(5,10,width,25)];
This is a lot better than checking against OS version like I've seen some suggest.
I am about to create a Cocoa app and I want to ensure that one day I can easily port it to the iPad or even the iPhone. How can I plan for this in advance?
I know I will have to redo all NIBs and probably design a different workflow.
But what about the code? Just replacing every NSsomething with UIsomething won't cut it, right? Any tips on how to make sure now that I won't shoot myself in the foot later?
Thank you!
(The iPad-SDK is under NDA. For the sake of this question just assume i asked about the iPhone, OK? Or think iPhone with a bigger screen.)
Make sure you strictly uphold the Model-View-Controller separation in your app. The model, especially, should never depend on any controller or view.
In porting to the iPhone/iPod touch/iPad, you'll need to replace most or all of the controllers and all of the NSViews and NSCells. You should be able to keep your CALayer subclasses, if you have any. You may be able to reuse one or two controllers with conditional compilation, if most of a controller will work on both but some parts only work on the Mac or work on both but with completely different APIs. And you should be able to keep the entire model unchanged.
There are probably some more specific pitfalls that an iPhone developer can warn you about, but this is the general rule that holds for any transition from one environment to another. (An example of another environment transition would be making one or more command-line tool equivalents or complements to your app, like xcodebuild, packagemaker, or ibtool.)
Also, look at the Introduction to the Foundation framework reference for figures showing which Foundation classes are Mac- and iPhone-only.
A lot of libraries aren't even supported in Cocoa Touch versus the desktop Cocoa libraries. You need to consider the differences in AppKit versus UIKit. Also, Objective-C does not allow garbage collection on the iPhone. There are many touch events that only exist on the iPhone but not on a desktop. iPhone development is much more restrictive due to the fact that a phone is a very personal device tied to very personal data.
Check out these slides for a better comparison: http://www.slideshare.net/lukhnos/between-cocoa-and-cocoa-touch-a-comparative-introduction
As with any good project layout, you should separate out your UI from your non-UI components. That doesn't just mean on disk layout (though that makes sense as well) but rather using a MVC approach, whereby your controllers (C) know about the Models (M) and the UI (V) is rendered separately.
You can use Key-Value Observing (aka KVO) to set up your models, such that when they fire, it sends around a notification to any registered listeners to update. If you are using XIB to generate your user interfaces, then this is what happens when you bind an object to your display widget(s).
So you can end up with separate XIBs for your iPhone, Mac OS and (later) iPad - though if you resize things correctly, you can have the same XIB for the iPhone and iPad.
Lastly, there are often some cases where you need to inject logic into your models (for example, adding an image to return from a method). In this case, the iPhone and Mac OS have different Image classes. To do this, you can create the following:
MyModel.m // contains the data, no UI
MyModel+UIImage.m // contains a category for adding the UIImage
MyModel+NSImage.m // contains a category for adding the NSImage
The category looks like this:
#interface Host(UIImage)
-(UIImage *)badge;
#end
#implementation MyModel(UIImage)
-(UIImage *)badge
{
if (green)
return [UIImage imageNamed:#"green.png"];
if (red)
return [UIImage imageNamed:#"red.png"];
}
#end
---
#interface Host(NSImage)
-(NSImage *)badge;
#end
#implementation MyModel(NSImage)
-(NSImage *)badge
{
if (green)
return [[NSImage alloc] initWithContentsOfFile: #"green.png"];
if (red)
return [[NSImage alloc] initWithContentsOfFile: #"red.png"];
}
#end
This has the added advantage that your unit tests can just load the model (without any image categories being loaded) whereas at runtime your code that needs to process the images (say, in a view controller) can load the model-with-category and load the badge with [model badge] in a transparent way, regardless of which platform it's compiled for.
First of all, the question is very simple, but I have tried to look around on the Internet and I couldn't find a name for this. Several applications such as "Ping Lite" have used this view in their application. It allows you to have submodules/applications as icons and you can scroll the page around just like when you are at "home" screen.
Can somebody tells me what is the name of the class that is used there?
This kind of view is not available in the iPhone SDK. It is written by Apple and it's not included in the UIKit framework. It's only available in SpringBoard.app, the application responsible for many features of the OS (kind of Finder.app).
However, you can write it yourself of course, using a UIScrollView. This will take some time but luckily we have the Three20 project, which implements the TTLauncherView class
AFAIK the standard sdk has no such a class. You can check third-party libraries(three20, for example) or customize UIScrollView behaviour
The UIView used at the “home” screen of iPhone is a UIScrollView alongwith UIPageControl.
Check the PageControl sample code from Apple and you will learn how it works.