I'm working on building a universal iOS configuration application for the iPhone/iPad. But the layouts ('views') for the iPad are considerably different from that of the iPhone. Considering that only the appearance of the application ('views') change w.r.t the device, what is the most efficient design approach i could follow?
Things I've already looked at
I've looked at one strategy where different View controllers are loaded depending on the device in use. But this might be an overkill considering that the 'controls' are the same across devices and only the appearance of the application changes.
The use of functions to resize the view frames to layout views as needed automatically. This does not help me much because there is a need to not only change the size of the views but load different views altogether depending on the device.
To keep the viewController unchanged but configure the views inside the viewController differently. Right now this seems like the best way to do it, but the application is kinda heavy and it might become very messy in the long run. Or is there a very efficient way to do this?
Is there a design strategy for this?
Or is there any way i can accomplish this efficiently while optimizing effort?
The standard approach is to have different XIB files for iPhone and iPad, which the platform will select automatically if you name them right, e.g. myview~iPhone.xib and myview~iPad.xib.
You are concerned about inefficiency: I wouldn't worry about the file size as compiled XIB is quite compact.
In my apps I mostly use this approach, with some fragments of code to add or remove buttons for each platform. Simple views can just be set up to resize automatically using the standard struts-and-glue techniques.
Related
I'm working on an iOS app in Swift. The other app I created was one I did in Objective C and release around this time in 2014. Storyboards seem to have made UI stuff both easier and more complicated at the same time, so I'm trying to figure out current best practice in terms of view development.
Size classes and constraints seem like almost a necessary timesaver at this point for multiple screen sizes. Back in 2014, this was less the case, and programmatically keeping track of UI layouts as CGRect code made programmatically mucking with UI layout much simpler and better for code reuse vs creating a whole new view controller for just adding new UI elements to much the same view. Doing the same thing with constraint code seems less appealing, but also necessary if I want more code reuse there.
So I'm wondering what the current practice is here as I'm just thinking in terms of code reuse. Programmatic constraints just seem less elegant than storyboard defined ones, but I'm not sure they're the end all be all for UI code since they seem problematic for programmatically updating the UI on the fly.
Is the best strategy at this point to enclose everything in layout preserving superviews and keep most of this storyboard centric or would it still make sense to do swift programmatic code for these layouts since I'd have to for iPad and iPhone specific changes anyway? On that subject would it still make sense to split drastically different UIs into multiple storyboards (e.g. 2 different iPad and iPhone storyboards as that was a default at one point)?
Thanks in advance for answers to this. Device specific stuff just seems to not always be code reuse, but I just want reuse to be relatively simple I guess. Otherwise I'm just creating more swift classes than I strictly need.
This is inherently opinion based. Everything from no Interface Builder to only StoryBoards is likely being used in production applications, and you can make just about anything work.
My personal tendency is to use Storyboards for everything other than TableView/CollectionView cells. I find it removes almost all interface boilerplate code from my classes and makes it so I only need to handle the interface between my ViewControllers. Here are the guidelines I generally try and follow: (again...opinion)
Use multiple storyboards organized in a useful way:
Large storyboard become hard to maintain and performance while editing suffers noticeably. We have the option to use StoryboardReferences, so might as well use them.
The more Scenes and ViewControllers, the better. (within reason)
This makes things more maintainable and re-usable. E.g. a header that could be used in multiple Scenes. It can be a bit annoying to have to use containerVCs and deal with segues everywhere, but I rarely regret separating something into it's own ViewController.
Don't use separate interface files for different sizes.
It's more code to maintain and will force you to swap ViewControllers in-out if you want to support resizing on iPad (or any future devices). Not to mention going forward it's clear Apple is assuming you're using size classes rather than swapping ViewControllers and is clearly where the future is headed in Apple platforms development
When you need animations, try and narrow it down to changing a single constraint.constant
This greatly simplifies your code and usually avoids having to deal with size-classes anywhere other than the storyboards. It's not always possible for complicated animations, but you can do a surprising amount if you're willing to mess around. It makes it possible to narrow down a toggling action to 2 lines of code, which is quite nice. Using StackViews can also help with this a lot.
The other thing to focus on is avoiding as much of the stringly-typed nature of IB as possible. This is much easier in Swift and there are some decent solutions using string-backed enums and extensions, but specifics are probably out of the scope of this question.
I'm learning many features of ios programming, but since I'm a beginner I don't know if it's better to design my appearance programmatically or graphically.
For example, should I make a view in code or should I drag it to my storyboard?
Should I set its size and position programmatically or graphically?
Which one is actually used in projects?
Specially considering the new Auto Layout and Size Classes feature in Xcode6
For auto layout and layout constraints it is best you use graphical tools because it is definitely future proof. You can do the same thing with code but it takes a whole lot of time to do things when compared to the graphical way of doing it. At the end of the day it all comes to the developer's comfort zone and the app's requirements.
A Small Point About Universal Apps:
Universal app building is very comfortable when you choose graphical storyboarding and have separate stuff for iPhone and iPad (also there are bigger screen iPhones and iPads coming). If you choose to do all the UI stuff with code for an universal app you would end up writing a lot of if-else statements, like below
if ([[UIDevice currentDevice] userInterfaceIdiom] == UIUserInterfaceIdiomPhone) {
//Do iPhone stuff.
} else {
//Do iPad stuff.
}
Help from Interface Builder for Autolayouting
The easiest way to add, edit, or remove constraints is to use the
visual layout tools in Interface Builder. Creating a constraint is as
simple as Control-dragging between two views, or to add multiple
constraints at once, you simply use the various pop-up windows.
Quote from -https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/WorkingwithConstraints/WorkingwithConstraints.html
You always have tools to save you even when you have messed up a lot with the constraints.
Some real good stuff,
http://carpeaqua.com/2014/05/09/why-you-should-use-interface-builder-with-auto-layout/
http://www.raywenderlich.com/51992/storyboards-vs-nibs-vs-code-the-great-debate
If you're looking into iOS development as a bit of a hobby then I'd recommend sticking to the graphical tools. These are faster to learn and will let you build your app in a shorter time if you are just beginning.
If you want to work on a large project in a professional environment or in a large team, then a 100% code project is usually desired.
If you pull apart some of the largest apps on the AppStore from huge companies, you'll see they don't use interface builder (IB) files. Take a look at Facebook, Spotify, Dropbox etc etc.
Some reasons include (but not limited to):
Ease of flow: A complicated app UI in interface builder can seem like a blackbox sometimes, whereas code is usually easier to follow
Simpler merging: If you have multiple developers working on the same UI file, merges can be a nightmare and more difficult compared to a source file
Finding problems: If a problem exists in a pure code project then the problem is right there in the code. Locating problems in an IB file can be tough, depending on how buried it is. Also Xcode's 'find' tool doesn't search through IB files
Code runs faster: You probably wont notice the speed but it is an advantage
Some boast the speed of coding using the graphical tools, and it's true that initially it will take you much longer than the code you're not yet familiar with. If you stick with it then you'll be able to write apps just as fast.
I've read around that Apple is hinting to developers at a larger-screen iPhone by pushing developers to use Storyboard and auto-layout. I understand why auto-layout would be useful, to organise items according to screen size, but what do Storyboards have to do with anything?
I may be missing an obvious advantage (in relation to larger screens), so any help would be much appreciated. :)
A. You say that there are some notice from Apple about the larger screen of the iPhone6: This is impossible because Apple doesn't release any information until the date of Keynotes and WWDC.
B. You can or not use Storyboard, and you can or not use AutoLayout: the 2 things are separate because you can also use AutoLayout in nib or programmatically.
C. What developers don't know, is that Storyboard are just a market move. I spoken directly with a my friend engineer in Apple about this and the information is real. The reason is also obvious. Is not the topic to speak about this but you can search on google and you will find a lot of information about the advantages to don't use storyboard.
Yes, storyboard are easy, but are not developer friendly if you think to work in a serious project with a big team. In a team you can use GIT, you can use shared repositories, you can export a part of code with the interface...in all this thing, Storyboard are BAD!
So i encourage developers to DON'T USE storyboard and use at max NIB file, or write the UI directly by code.
There currently doesn't appear to be any advantage to using storyboards versus XIBs or programmatic layout as far as multiple screen sizes are concerned. Auto-layout is definitely advantageous as it allows you to define your interface elements in relation to each other (and the screen), as opposed to using fixed numerical values for location and size. This would allow the UI to then easily adapt to varying screen sizes and aspect ratios.
The only potential reason storyboards could become useful for multiple screen sizes in the future is if Apple adds functionality to them to allow you to define entirely separate views based on device/screen size. So for example, they might make it easy to show a view with an extra sidebar on a larger screen, but show a separate view without the sidebar on a smaller screen (they might make it possible to configure this easily in a storyboard, versus writing a bunch of code to detect the screen size and load the appropriate view programmatically). As of now, though, no such functionality exists, but that could be a potential source of the rumors regarding storyboards being useful for multiple screen sizes.
I'm working on 2 iOS apps using the "multiple nib files method".
I came across storyboards not long ago and this seems really great in terms of efficiency.
Any reason not to switch to storyboards (for quite simple applications) ?
Are there any stuff that were possible in the old methods that are not more possible now ?
The answer is... it depends. Storyboards are all fine and dandy, but there are circumstances where multiple nibs are still beneficial. For example, if you are using a scroll view to swap multiple subviews on and off screen then it's far easier to design each subview in its own NIB, then load and add them programatically.
I have found a comfortable compromise: I use a storyboard for the main app screen and any major state transitions (e.g. a 'main' mode to a 'config' mode), but I still use separate NIBs for subviews which are off-screen to start with (e.g. dynamically created popovers not tied to a fixed UI element.) I get the ease and efficiency of storyboards for big stuff which could be a bit tricky in the past, but I get full flexibility for designing very dynamic UIs using separate NIBs.
Anecdotally, I have heard that storyboards are a particular pain for people developing in teams of any significant size. They are extremely hard to share, and they make dividing up responsibilities for separate areas almost impossible. Separate NIBs work perfectly in those cases.
They're another tool, nothing more. They're certainly not a complete replacement (at least, not yet.)
The main reason you might stick with NIBs and programmatic transitions rather than a storyboard is to retain compatibility with iOS 4 and below. Once you're supporting iOS 5 only there's going to be very little reason for using NIBs, however they'll still be useful for any occasion when you want to be able to load a resource on demand, possibly several times.
So, off the top of my head, I'd still expect to use NIBs to design UITableViewCells and other similar content, and as a way to store graphical-type data in a way that's visually editable.
I'm not sure how common a practice it is, but often when I want, say, for the palette used by a program to vary from target to target or by locale, I find it more manageable to create a NIB with a bunch of views set to the relevant palette colours and to programmatically load the NIB and pull the colours out. I find that to be a good solution because you set the visual properties of the thing through a visual editor, built right into the IDE.
I like storyboards over "multiple nib files method". Only difficult part i encounter in storyboards is Control object. Messaging between two views are little difficult but once you understand it will be very easy. All the stuff is possible which you can achieve by multiple nib files method. I will recommend you to use storyboards over multiple nib files.
New to iOS, coming from the Java / Swing world, where I'm used to creating UIs programmatically, letting components size themselves and using various clever layout managers to arrange things.
It already seems clear that the iOS way is to make heavy use of Interface Builder, with a lot of fixed sizing and positioning. I'm not sure IB is ever going to come naturally, but I guess fixed layouts make sense given that you're working with limited space and a fixed window size.
It still seems like I'm writing a lot of boilerplate, though, and violating DRY, and so on.
Can somebody point me to a good primer on laying out iOS UIs, particularly programmatic UIs?
You don't really need to use IB to write MonoTouch apps. I almost never do. The CocoaTouch API is fairly simple and straightforward to develop on.
I haven't really found any writeup on UI development other than the apple documentation (which is really good, by the way, worthy reading), so here goes a couple of tips, based on my experience:
Inheritance is key to maintaining the code clean. You can inherit from basically any class in the API, like buttons, controllers, views, etc. Inherit and add your customizations in those classes. Don't shove everything in the AppDelegate like many examples show. You'll thank me later on.
Have I mentioned inheritance already?
The one thing iOS doesn't have is a layout manager, so if you're used to Java like you mentioned, this will sound a little strange. Different from what Java people think, this is not a big deal. UITableViews help tremendously with this (vide next point).
A lot of iphone apps are built on top of the UITableViewController, even apps that don't look like tables. It's a great framework to do anything related to scrolling. Learn to use it well. Almost anything that scrolls vertically is a UITVC. Follow the guidelines that define when you create and when you dispose cells and objects.
Be careful every time you add a Frame location in your control. Instead of setting hardcoded values, try using offsets from other locations (x+40, for example) whenever possible.
Make sure you add your views to the proper container as necessary. For example, if you're adding a global "Loading" view, add it to the Window object, while if you're adding a image on the left side of a table cell, use the ContentView. iOS changes those special views automatically all the time (resizing screen to fit "on call" bar at top, or rotating phone).
Miguel de Icaza has created a great framework for managing forms and tables, called MonoTouch Dialog. Take a look, and enjoy.