I have an iPhone app in the store that I used xCode 4.2 and Storyboards to create. I now wish for iOS 4.3, and prior, users to be able to use the app... they currently cannot due to the storyboard.
How do I proceed to eliminate the storyboard to gain a wider audience?
Thanks.
There is no easy way to do this, unfortunately. What I would suggest is to manually copy the elements of each segue in your storyboard and paste them each one at a time to a newly created nib file...
Also, dont forget if you go the multiple nibs way, you'll need to edit a bit your AppDelegate and create a MainWindow.nib file. Create a new project using nib files to have a perfect exemple of what to do!
Related
I am in the process of localizing a mac application and wondering the approach I should take to localize the nib files. I used to localize the xib files by creating IBOutlets for every property in the xib such as labels. However I feel this is not the correct approach and should use the ibtool instead.
I have refered to this http://developer.casgrain.com/?p=94 as start point. But feels like creating IBoutlets is much easier and I can have the programmatically added strings and strings related to nibs at one place.
Can someone enlighten me about the downside of localizing xibs using IBOutlets?
I am planning to learn to develop applications using Story Boards. Can anyone please post some advantages and disadvantages while using StoryBoards?
When to use Storyboard and when to use XIBs
What are the benefits of using Storyboards instead of xib files in iOS programming?
iphone-sdk-development
I think these links are helpful and related to your question. Personally, I believe storyboards are better then nibs because they eliminate the need to code your transitions between views (unless you use custom transition with CA), and they have all the capabilities of nib files too.
Hope this helped.
-----------EDIT-----------
Here are some more links I found:
This one speaks about some of the cons of using storyboards.
UIStoryboard on iOS 5: The Good, The Bad, and the 'This Plain Sucks'
This one is mostly about the benefits.
What are the advantages of iOS 5.0 storyboarding over traditional UI layout?
It's mostly cons. Don't use Storyboards. Here's is a list of their problems, copied from iraycd:
Storyboards fail at runtime, not at compile time: You have a typo in a segue name or connected it wrong in your storyboard? It will blow up at runtime. You use a custom UIViewController subclass that doesn't exist anymore in your storyboard? It will blow up at runtime. If you do such things in code, you will catch them early on, during compile time. Update: My new tool StoryboardLint mostly solves this problem.
Storyboards get confusing fast: As your project grows, your storyboard gets increasingly more difficult to navigate. Also, if multiple view controllers have multiple segues to multiple other view controllers, your storyboard quickly starts to look like a bowl of spaghetti and you'll find yourself zooming in and out and scrolling all over the place to find the view controller you are looking for and to find out what segue points where. Update: This problem can mostly be solved by splitting your Storyboard up into multiple Storyboards, as described in this article by Pilky and this article by Robert Brown.
Storyboards make working in a team harder: Because you usually only have one huge storyboard file for your project, having multiple developers regularly making changes to that one file can be a headache: Changes need to be merged and conflicts resolved. When a conflict occurs, it is hard to tell how to resolve it: Xcode generates the storyboard XML file and it was not really designed with the goal in mind that a human would have to read, let alone edit it.
Storyboards make code reviews hard or nearly impossible: Peer code reviews are a great thing to do on your team. However, when you make changes to a storyboard, it is almost impossible to review these changes with a different developer. All you can pull up is a diff of a huge XML file. Deciphering what really changed and if those changes are correct or if they broke something is really hard.
Storyboards hinder code reuse: In my iOS projects, I usually create a class that contains all the colors and fonts and margins and insets that I use throughout the app to give it a consistent look and feel: It's a one line change if I have to adjust any of those values for the whole app. If you set such values in the storyboard, you duplicate them and will need to find every single occurrence when you want to change them. Chances are high that you miss one, because there's no search and replace in storyboards.
Storyboards make you do everything twice: Are you building a universal app that runs both on iPad and on iPhone? When you use storyboards, you will usually have one storyboard for the iPad version and one for the iPhone version. Keeping both in sync requires you to do every UI or app-workflow change in two places. Yay. Update: In iOS 8 and Xcode 6, you can use a single Storyboard for iPhone and iPad.
Storyboards require constant context switches: I find myself working and navigating much faster in code than in storyboards. When your app uses storyboards, you constantly switch your context: "Oh, I want a tap on this table view cell to load a different view controller. I now have to open up the storyboard, find the right view controller, create a new segue to the other view controller (that I also have to find), give the segue a name, remember that name (I can't use constants or variables in storyboards), switch back to code and hope I don't mistype the name of that segue for my prepareForSegue method. How I wish I could just type those 3 lines of code right here where I am!" No, it's not fun. Switching between code and storyboard (and between keyboard and mouse) gets old fast and slows you down.
Storyboards are hard to refactor: When you refactor your code, you have to make sure it still matches what your storyboard expects. When you move things around in your storyboard, you will only find out at runtime if it still works with your code. It feels to me as if I have to keep two worlds in sync. It feels brittle and discourages change in my humble opinion.
Storyboards are not searchable: A project-wide search in Xcode is not really a project-wide search when you use storyboards. They are not included in the search. So when you remove a custom class from your code or rename it, you will have to manually go through the storyboard or look at its raw XML to make sure it is on par with your code changes. No sir, I don't like it. Update: Storyboards are searchable in Xcode 6.
Storyboards are less flexible: In code, you can basically do anything you want! With storyboards you are limited to a subset of what you can do in code. Especially when you want to do some advanced things with animations and transitions you will find yourself "fighting the storyboard" to get it to work.
Storyboards don't let you change the type of special view controllers: You want to change a UITableViewController into a UICollectionViewController? Or into a plain UIViewController? Not possible in a Storyboard. You have to delete the old view controller and create a new one and re-connect all the segues. It's much easier to do such a change in code.
Storyboards add two extra liabilities to your project: (1) The Storyboard Editor tool that generates the storyboard XML and (2) the runtime component that parses the XML and creates UI and controller objects from it. Both parts can have bugs that you can't fix.
Storyboards don't allow you to add a subview to a UIImageView: Who knows why.
Storyboards don't allow you to enable Auto Layout for individual View(-Controller)s: By checking/unchecking the Auto Layout option in a Storyboard, the change is applied to ALL controllers in the Storyboard. (Thanks to Sava Mazăre for this point!)
Storyboards have a higher risk of breaking backwards compatibility: Xcode sometimes changes the Storyboard file format and doesn't guarantee in any way that you will be able to open Storyboard files that you create today a few years or even months from now. (Thanks to thoughtadvances for this point. See the original comment)
It's McDonald's: To say it in Steve Jobs' words about Microsoft: It's McDonald's (video)!
Can someone explain in simple words the difference between .xib and .storyboard?
Apple introduced the concept of "storyboarding" in iOS5 SDK to simplify and better manage screens in your app. You can still use the .xib way of development.
Pre-storyboard, each UIViewController had an associated .xib with it. Storyboard achieves two things:
.storyboard is essentially one single file for all your screens in the app and it shows the flow of the screens. You can add segues/transitions between screens, this way. So, this minimizes the boilerplate code required to manage multiple screens.
Minimizes the overall number of files in an app.
You can avoid using Storyboard while creating a new project by leaving the "Use Storyboard" option unchecked.
You could refer this tutorial to get started.
Yes, you can still create a Window-based application for iOS 5. If you use the "empty project" template, you will see that a window is created for you in the app delegate. From there you can add XIB files as normal, or a new storyboard.
I'm assuming you mean "storyboards" rather than "timeline". Storyboards allow you to map out, visually, all of the views in your applications and how they interrelate. If you are just starting out with storyboards, there's an introduction to storyboards in the WWDC 2011 videos here. The 2011 Stanford iOS course on iTunes-U is also iOS 5-specific and covers storyboards and more.
A storyboard is like a canvas where you put all your .xib files. You no longer have any .xibs, you just have View Controllers directly on your canvas.
storyboard is a new feature available since the release of Xcode 4.2.
It offers a complete new way for iOS developer to create and design
user interface. Before the introduction of Storyboard, it’s especially
hard for beginner to create navigation (and tab) interface. Every
interface is stored in a separate xib file. On top of it, you have to
write code to link all interfaces together and describe how the
navigation works.
With Storyboards, all screens are stored in a single file. This gives
you a conceptual overview of the visual representation for the app and
shows you how the screens are connected. Xcode provides a built-in
editor to layout the Storyboards. You can define the transition (known
as segues) between various screens simply using point and click. This
doesn’t mean you do not need to write code for the user interface. But
Storyboards significantly reduce the amount of code you need to write.
Source: http://www.appcoda.com/use-storyboards-to-build-navigation-controller-and-table-view/
XIB:
Xib files are used with a single UIView.
2)It's very difficult to implement complex auto-layouts in xib.
3)It's utilizes more memory as compared to storyboard and quiet slow.
It is compatible from iOS5 and onwards
You can do localizations for different languages and countries using
different XIBs .
It's difficult to use same Xib to support multiple devices.
Storyboard
1)You can layout all your Scenes like View Controllers, Nav Controllers, TabBar Controllers, etc in a single storyboard.
2)You can use Auto Layout easily that defines mathematical relationships between elements defining their position and sizing.
3)Usually fast and allocates less memory.
4)It's not compatible prior to iOS 5 .
5)"Dynamic" and "Prototype" cells can be used easily.
6)Storyboards best to use for the apps with a small to medium amount of screens.
The best Answer I have seen : Xib Vs Storyboard in iOS
XIB and Storyboard are used for creating interfaces for users.
One important point is,xibs are used for creating a single view(it has single file owner at the top of the xib file), but in-case for viewcontroller, multiple screens can be added and its flow can also be monitored(it has separate file owners).
I have a universal app.
I wrote all the iPhone code. Noe, rather than rewrite the code exactly the same, I would like to just have specialized xib files. How do I set up this new xib files. How to I create them and how do I link them to my iPhone classes. then how do I load them, meaning make the app pick the iphone xib or the ipad xib
thanks in advace
Note, I'm using Xcode 3
when you instantiate you controller using alloc init , Use initWithNibName and use the nib or .xib name you to associate with project.
hmm, you say "I have a universal app", but sounds like you mean "I have an iPhone app and want to create a Universal App". If so, here is some info I used the first time I did this:
http://iphonedevelopment.blogspot.com/2010/04/converting-iphone-apps-to-universal.html
Jeff Lamarches stuff is pretty reliable I think.
I have a game on the App Store, and for the next version I am working on having an option in the settings to use different skin. So for example, lets say I choose the basketball option. I would want the app to show the basketball .xib instead of the default view controller.
How would I do that? There would be about 4-5 different skins. Thanks.
I would suggest doing your UI programmatically and not using a xib file as I believe it is impossible to accomplish what you are after with a xib.
If you are deadset on using a xib, create 5 identical sets of subviews and name them accordingly, then programmatically hide/unhide them when necessary.
This seems much more cumbersome and hard to manage when faced with an option of just creating the elements yourself in code.