The app I'm currently working on has a huge number of views. Some are webviews and some normal UIViews, with a ton of subviews. Now that the iPhone 5 has come out, how can I most efficiently change the frame size of the entire app to support both 4-inch and 3.5 inch devices? I certainly could use a whole bunch of if-else statements and layout several frame sizes for each view, but what's the best, most efficient way this could be done?
Most efficient way is to use one of the provided layouting mechanisms:
Autoresizing – Each UIView has property autoresizingMask and by setting it to one or many values (using | operator) you tell the view how to behave when the size of its superview changes. Elementary options:
UIViewAutoresizingFlexible...
...Width
...Height
...LeftMargin
...RightMargin
...TopMargin
...BottomMargin
Auto Layout – New in iOS 6, it provides more complex (very complicated) mechanism of relations between view attributes. Basicaly it is a superset of autoresizing and there are some long docs for it. I don't recommend it to you.
Related
I'm not very good with Constraints, so basically, my idea is to place all the objects on the View Controller manually for every screen size (iPhone 4, 5, 6, iPad, etc).
Is it possible?
Can I place all of them in one View Controller, or will I have to create a new View Controller for each screen size?
It is possible and you can do it in a single ViewController for each screen size. In Interface Builder if you open a ViewController or any other UI element, on the Attributes Inspector you can see small + signs next to most properties, using which you can add screen size specific properties. Using this approach you can manually create different sizings/font sizes/label texts, etc. for each screen size.
However, I would really recommend learning how to use Autolayout. It is one of the most powerful features of iOSs UI design and working on a large project with a complex UI you will pretty soon regret not learning how to use it. In the long-term it definitely saves you a lot of time and effort. With all the different screen sizes Apple has introduced in the past years, handling them manually is a real pain.
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).
I've got a fairly intricate IOS application with icons, tables, text fields, etc spanning across over 20 different view controllers. I built the entire application in portrait mode, and have of course realized that things look screwy when in landscape.
For the really simple screens I've had little issues using autolayout's constraints to accommodate any orientation changes. However, when there are multiple (5+) items on the screen I've found it incredibly hard to use constraints to manage everything. In fact some views look like they need the entire layout transformed to flow well.
Is there a better alternative to constraints? My only other thought is to make duplicate views, one for portrait and one for landscape. Then I can just switch on the deviceOrientationChange listener.
You can always switch off constraints by selecting the xib/storyboard file and unchecking Use Autolayout. To do this only for the more complicated views, I think breaking out into separate xibs is feasible.
Also, sometimes landscape really calls for a complete rearrangement of the view (or even adding / hiding certain elements). You should not shy away from defining separate views for this, with or without xib documents.
What is Auto Layout - what does it do, and is it an iOS 5 feature?
Since the new iPhone 5 has a bigger screen, all the options on how to optimize your applications for it come down to Auto Layout.
Can you point me to some article about Auto Layout, and how I can adapt it with my project?
I recommend watching the WWDC 2012 session Introduction to Auto Layout for iOS and OS X.
Auto Layout is a new way to define dynamic GUIs. Before, we had autoresizing masks, that described how a subview will resize or move when its superview is resized. With Auto Layout you can do the same and also a lot more complicated GUIs quite easily.
https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AutolayoutPG/Articles/Introduction.html
"If Auto Layout in iOS 6 turns out to be anything like Cocoa Auto Layout in Mac OSX 10.7, the Cocoa Auto Layout Guide, a publicly available document, may give you an idea of how it would work in Cocoa Touch.
The underlying engine used by Cocoa Touch is Cassowary, and it's also used in other toolkits, such as enaml. I recently wrote a brief overview of Cassowary, with a comparison between Cocoa Touch and enaml wherein I port a Cocoa Auto Layout example to Python and enaml."
From: https://stackoverflow.com/a/11129597/1648976
And the WWDC Session: https://developer.apple.com/videos/wwdc/2012/?id=202
iOS 6 is still under NDA. Hold out for a few more days. It is an iOS 6> feature. In case you have a developer account, you must be already able to learn about Auto Layout from the documentation or from the WWDC 2012 session videos.
"Autolayout" is used to adapt layout to different screen size,orientation and localisation.
In Autolayout we don't give input based on "x" and "y" coordinate (old style). Instead we define the layout using mathematical relationship between the elements in our view. We can define this relationship using constraints or individual elements or constraint between a set of elements. Once we redefine the layout using this relationship .Our app can adapt to different layout based not only on device size like 5 inch or 5.5 inch in iPhone, but orientation and localisation as well.
For further understanding you can visit:http://www.raywenderlich.com/83129/beginning-auto-layout-tutorial-swift-part-1
What is Auto Layout?
Auto Layout is a constraint-based layout system. It allows developers to create an adaptive interface that responds appropriately to changes in screen size and device orientation. Without using Auto Layout, it would be very hard for you to build an app that supports all screen sizes.
Why Auto Layout?
Auto Layout is a way that lets developers create user interface by defining relationships between elements. It provides a flexible and powerful system that describes how views and the UI controls relate to each other. By using Auto Layout, you can get an incredible control over layout, with a wide range of customization, and yield the perfect interface.
Auto Layout is compatible with many of Apple’s most exciting application programming interfaces (APIs), including animations, motion effects, and sprites.
Reference:
https://www.appcoda.com/introduction-auto-layout/
UIView Autolayout is a very interesting concept in iOS App development. Autolayout takes care of responsive design. iPhone comes with different screen sizes every time. With the help of Autolayouts, you do not have to create your App design each time. Autolayout takes care of responsive design.
This article on "Introduction to Autolayouts" will give you enough understanding about it.
best tutorial link for autolayout:
https://www.youtube.com/watch?v=ugqFWPsY_A0
https://www.youtube.com/watch?v=vzyd33Pv9kg
https://www.youtube.com/watch?v=Nl2iMF0yKW8
https://www.youtube.com/watch?v=Gl6DibzPYa4
https://www.youtube.com/watch?v=J10vzrTcswI
https://www.youtube.com/watch?v=izES1zQjRUU
I released the first beta version of my iPhone app on TestFlightApp today. Everything is going really well until I notice that the responsiveness of the application is pretty cruddy. Certainly doesn't have a "nice" native feel that I'm going for.
I've been particularly fastidious concerning my memory allocation/deallocation, so I don't think this is the issue. Basically, I don't know where to turn to next in order to improve the performance of my app.
Here's where I think some of my slowdown can be attributed to:
Using UIAppearance to customize the looks of most (if not all) UI elements. I use a brand new font, lots of CAGradientLayers, and lots of edits to CALayer in order to draw nice Shadows.
Grouped UITableViewCells that display pictures of a map and itemized lists.
UITableViewCells whose layouts are updated every time I call layoutSubviews.
UITableViewCells with customized heights. For each call of heightForRowAtIndexPath, I need to reconstruct and re-layout the view, returning the exact height each time.
Because I programmatically created views, controllers with longer viewDidLoad calls tend to load slower. What code can I offset in the init call?
Does anyone have any hints or tips for dealing with these problems? Or perhaps people have stories about how they dealt with a slowdown in performance when they released their first app?
My answer won't address all of your points, but here are a couple:
1) Make sure you are using Shadow Paths. Paths are much, much more performant.
2) Are you using transparency or corner rounding? If so, try and reduce transparency as much as possible and do not round corners using CALayer cornerRadius. Instead, use a clipping mask in the drawRect of the view that needs to be rounded.
4) Perhaps you can cache the height in an array and not have to repeat the calculation, each and every time. This may/may not scale well depending on the potential number of items, but may be acceptable depending on the use case.
5) Are there views you can reuse? For example, when I have a custom selection view on a UITableViewCell, I only create a single instance held by the controller and reference it in all the cells.
Did you run Instruments (or other profiling methodology) to determine where you app is spending most of it's time. It would be a good idea to do this before optimizing the wrong thing.