As I say in the title, I'm developing an iPhone app. I use nib files, I don't use any storyboard, and I know that for iPad I'll need to replace some of the controls I currently use for iPhone, since, for instance, in iPad is more suitable to use popovers in some places, and some other considerations. But I'm not sure if I'd need to create a separate nib file targeted for iPad per each nib file I have now for iPhone, or it should be just the convenient thing but not needed, or I can keep just one nib file if views are for example scroll views or table views, and just resizing things would be enough...
What I want is some guidelines to avoid redundant files and work when creating an iPad version of an existing iPhone version, and what the best practices are, since I don´t find how to handle this, programmatically speaking, neither in Apple's docs nor in posts...
Thanks in advance
EDIT. A question about dealing with icons and images: let's say I have an image view that is 50x50 in iPhone. I have two .png images for the iPhone version of this image: 50x50 and 100x100 for retina display. Let's say I need this image to be 80x80 in iPad. What should be the best way to deal with this: having 4 versions of the image (50x50, 100x100, 80x80, 160x160)? or just having the greatest versions (the 80x80 and 160x160 for iPad), and just resizing them to be smaller for iPhone? In general, what is the best practice about this, having one image file per each size you need, or just having the greater you need and fitting it to smaller sizes?
At xib files you should use the AutoLayout with constraints. That was introduced in ios6.
The key and the war with patience and time it will be setting up correctly those constraints.
One xib can be used to iPhone and iPad too, not needed 2 separate files in this way. As speed of development the 2 file are faster to develop, at least for me...
You can usually get away with not re-implementing a lot of .nib files to be iPad specific and just reuse your pre-existing ones. I have a lot of projects that do this.
That said... you usually have to reimplement the top level container .nib to be iPad specific and you really need to think about where you can take advantage of the larger screen size on iPad and adapt or create new .nibs as you see fit. While you're in any .nib... consider updating it to use AutoLayout if you can!!!
Using child view controllers (UIViewController has had childViewController since iOS 5.0) and other libs like for example SGBDrillDownController (you can find it in CocoaPods.org) might be things to take a look at.
On your images question... If the images scale well and don't get too anti-aliased looking when you go from largest to smallest rendition then going that route can make your life a lot easier. I have found however that to get a decent looking image it is best to use scalable vector art and then create a separate rendition for each size needed. Getting the best possible graphics possible is certainly a key to success.
Related
I'm starting an investigation into downscaling an iPad application to fit into the form factor of the iPhone. The main problem is that this project does NOT use .storyboards or .xib files with the exception of a custom UIInputView.
My main question revolves around layout (obviously). Since all of the frame values are in the code, what is the best (shortest) way to allow for multiple different frames based on the total frame size?
I know this is very easy in a storyboard, but due to multiple developers and the use of SVN, we had to forgo the use of them during initial development.
I'm not seeing many resources on some google queries on the subject, most developers are going from iPhone -> iPad and not the reverse.
I know about this code:
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone)
But I don't want to have do this for 500+ places in code where we set somethings' frame.
Would it be more efficient to extract all of the frame definitions to a class for retrieving device specific frame sizes?
Some additional notes, We're not using anything iPad specific other than popovers. The entire interface is mostly nested UIViews on one main UIViewController.
This is exactly one of the types of things that Auto Layout was meant to solve. Behind the scences, everything is using Auto Layout now, but if you have a lot of hardcoded constant values for sizes, you're in for a lot of work to actually take advantage of its new features.
If you want to avoid storyboards/xibs, I suggest considering refactoring your code not to use static sizes via frames/bounds (i.e. a lot of initWithFrame calls), but rather use Visual Format Language where ever you can, and dropping down to full on NSLayoutConstraints as needed.
You'll want to read and understand this: Working with Auto Layout Programmatically
With VFL, you can express virtually all of your sizes and positions as relative values. Where you cannot, you can pass in metrics to your VFL calls with the values that need to be explicitly set for iPad v. iPhone (where relative, calculated values do not work).
My dilemma -
I have a universal app that holds a lot of images and icon (about 1,000).
In many cases i use the #2x version as is for the iPad version, in other cases it is to big even for the iPad.
I see 2 options:
Add a unique images for the ipad (large the app size).
Scale the images every time i use them?
Would like to hear notes or ideas.
Thanks
Shani
I think you will here different suggestions here. It really depends on your requirements and whether it is more important (mandatory?) for you to reduce the size of your app or make it more responsive at run-time.
Are you going to scale the images down one-by-one (meaning that in a view you will have only an image)? Or are you going to scale down a whole lot of images to display, e.g., in a table view? This will impact greatly the user experience...
As to the "every time", you could think about using a cache, so that you only resize each image just once. This would be like an intermediate solution, but again, it depends on your app (if very many images will be loaded, the cache will become very large, so in this case it could be suggested to go for option 1).
Also, the iPad 2 is pretty fast; iPad 1 a little less, so you could also take into account that.
In general, I don't think that scaling down will add much overhead, but YMMV...
I used TTTabBar in the Three20 library. It seems to be a good simulator. But its scroll speed is significantly slower in the device (iPhone 4).
All I did was just replacing few names in it. So I was curious if maybe I did something wrong. So I tried the sample project provided by the library. And it's slow too!
How to use it not slowly?
I think the TTTabBar is used in the 'USA TODAY' app. It almost looks the same, but it's not slow. There must be a way.
It can also depend on the content which you are going to load (meaning web content), images from the web service in to the scrollview.
Or maybe you have provided the animation to the component within the scrollview. Check it out.
If it is animation then give minimum animation time as the device can not respond fast to touch or gesture as in the simulator.
Is three20 Library free of cost? I have one for a PDF book to turn the pages like with gesture (how can we know that particular library is free of cost?).
Try to load all your content in the initWithNibName method. (e.g. Parse websites, load images)
That was the solution for me because the content is loaded when the app starts up.
Does anyone know what will happen with existing apps when they run on the iPhone 4.0 in terms of the new screen resolution? I am assuming, just like developing for the iPad that there should be no hard coded screen resolutions in your code.
I'd also like advice on the best way of writing robust code to work well on any device. For instance, detecting the screen resolution is not enough - on the iPad the screen is physically bigger so you can display more items on it. On the new iPhone the screen is the same physical size but higher resolution, so the likely thing is that you wont want to display more items, just higher resolution versions of them.
Any help would be useful,
Regards
Dave
EDIT: I have read the other similar posts, I guess what I really would like to know is what is the recommended way to write code for all App Store devices in a robust way so they a) all work b) make best use of the device.
UIKit has be redesigned so that old apps just work unmodified in the iPhone 4. There are then several things you can do, some programmatic and some by just adding higher resolution images to you app bundle.
Firstly, and most simply you can include new double res images that are used by your app with a suffix of #2x in the name. i.e., Event.png as well as Event#2x.png. [UIImage ImageNamed:] will automatically look for the a file with this suffix if it is running at the higher res.
All the other UIKit stuff now uses points instead of pixels. So for both old and new apps full screen is still 320 x 480 points. This pretty much means everything will work including touches, etc. Although they may now return fractions of a point.
The only real gotcha so far seems to be if you use CGBitmapContextCreate as this uses pixels and requires some jiggery - pokery.
When creating an UIImage file from a .png to be displayed on a button, view/cell background, etc. for a standard Iphone application, should all of them be in powers of 2 for optimization reasons?
As others have said, no - but you should generally use images with even dimensions. This is because when views are positioned with the center property, it'll position an odd-dimensioned image at some half-pixel position. This will cause the image to appear blurry.
As long as you're aware of this it shouldn't really cause you any problems, but it's still a good idea to use even sizes just to be on the safe side.
(This applies for UIKit, not necessarily OpenGL)
Apple uses odd and arbitrary dimensions for all the images it adds to the interface on your behalf, such as system toolbar items. The best optimization you can do is anything that reduces compositing, which basically means setting the opaque property of views and layers whenever possible.
If you have the choice between a transparent png that will be composited over a static background and an opaque png with the background already included, you have a chance to optimize. When the images will be sliding around or the background will change, you have to composite, otherwise choose opaque.
Here is an article on optimization of iPhone images -- basically tells you why to use PNG files. The size shouldn't matter unless you are using OpenGLES.
No, this will have little or no benefit, I usually suffice at doing my own optimization using photoshop "Save for web or devices" option.
Please see http://iphonedevelopment.blogspot.com/2008/10/iphone-optimized-pngs.html for a detailed explanation about the iPhones pre-optimization of pngs.