We are in the process of creating a set of common components and common views that are reusable across several applications we have. In these libraries we have the .xib files and view controllers. We want to be able to use these in storyboards for the specific applications. Is this even possible?
I haven't seen an easy way to share reusable views or components from static libraries in storyboards yet.
Whats the recommended way to do this to keep from having code duplicated in every project?
Thanks..
Typically when making a static library for sharing, you can also include a bundle with resources (xib and image files for instance). Take a look at the FacebookSDK for instance. It contains a bundle with images and strings. Those can be loaded by the SDK code or the client app of the SDK.
For help on making a static lib with resources, see : https://github.com/jverkoey/iOS-Framework (thanks #jnjosh) or https://github.com/kstenerud/iOS-Universal-Framework. I've used the iOS-Universal-Framework on a shipping app recently. Works well.
In order to use xib files with storyboards, you can take one of two approaches:
Load the xib View Controllers in an action or segue called by the VC in the storyboard.
Or use the xib within the storyboard. See: Using XCode storyboard to instantiate view controller that uses XIB for its design
Also if it's just for internal use, I recommend simply making a shared repository of code + resources, rather than making a static library. The main benefit of the static library is ease of distribution outside of your team.
Related
I have a framework which has storyboard and xib files.
How do I make the storyboards within the framework customizable? i.e. people using my framework should be able to modify the storyboards to customize the look & feel.
When I imported my framework in another app project in XCode, I did not see the storyboard files within my framework. How to make them visible & editable?
Is it even advisable to use framework in this case or should I go with static library+resource bundles combination?
I finally did this,
Load custom xibs,storyboards dynamically. i.e. first try loading custom storyboards, if not present load default storyboard(use try catch to check).
Expose all viewcontroller outlets and event handling functions through header files.
Make connections between buttons in your custom framework and these header file outlets,event handlers. Done! Your Viewcontroller.m functions will be called on clicking on those buttons.
When I click new file and go to user interface tab, I don't see the application or window options. The application file description should say "An Interface Builder document suitable for creating an iOS application, including an application delegate and window." I tried searching in the search bar in Xcode but application did not show up for iOS.
Please see screen shots and difference for clarity.
app delegate screenshot 2
my screen
Apple introduced storyboards back in 2011. Before that, developers used a .xib file to specify their user interfaces, and the "main" .xib file, i.e. the first one that the app loaded, included a proxy for the app delegate so that it was easy to connect objects to outlets in the app delegate. As matt has indicated, though, things haven't really worked that way for a while. As he says, it sounds like you're working from an old book or online tutorial, and as a result your expectations don't match the reality of modern iOS development.
These days, apps generally use a storyboard to specify all or part of the user interface. A big problem with .xib files was that you had to load an entire file at once; if you instantiated a view controller with -initWithNibName:bundle:, the entire file was loaded. That meant that you could only specify a single view controller in a given .xib file, and managing the relationships between view controllers was harder than it should be. Storyboards address this problem -- a single storyboard typically contains several view controllers.
I agree with matt that you really shouldn't work from material so old that it expects you to use .xib files to build your application. That story again:
STOP USING THAT INFORMATION
There are plenty of great resources (notably matt's own iOS 9 Programming Fundamentals with Swift) that will teach you how to write modern iOS code. Apple's own documentation is a great place to start.
I started a project using the Storyboard in Xcode 6 and now I think I would like to use XIB files. Are there any risks associated with moving from Storyboard to XIB? I thought I read somewhere that Xcode 6 would prefer developers to use the Storyboard, is this true? Are there benefits of using the Storyboard over XIB files? I feel like you have more control when using XIB files. Is there something I'm missing? Am I able to convert fairly easily or would it make more sense to start my project over?
I'm an Android developer moving into iOS, so please forgive my lack of knowledge on the subject.
UPDATE
I am more interested in knowing if there are any risks or problems in switching from Storyboard to XIB mid project. Currently, I'm using Storyboard, but I am thinking of switching some parts to XIB. Will this cause any problems with my project? Is there anything I need to be aware of in doing this?
Code, storyboard and xibs are all different ways of creating views and layouts.
There is no rule that says you can only use one of them in a project.
In most of my projects I use a combination of all three.
Storyboards give a quick and easy way to create "flow" in the app. I tend to use one storyboard per "workflow" inside the app.
Xibs I tend to use for views that are common in multiple places within the app. In a storyboard I'd have to define them multiple times. Using xibs is a bit like refactoring interface builder files.
I then fall back to using code when necessary. Sometimes it isn't possible to do what I want with interface builder.
To say that you are only going to use xibs is purely denying yourself access to the other tools. Learn when to use each and how to use them together.
There are some things like container views and embed segues that only work with Storyboards.
For the most part, though, it's a question of personal taste.
Apple does seem to be moving in the direction of Storyboards, so as a new developer you may want to put your efforts into Storyboards.
There are a lot of articles on the internet that discuss this topic, example: http://www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code
I would take a look at the answers to this question for some great info.
Here's a quick summary:
Storyboards have some great features such as letting you create segues between views, and design table view cells in-place.
The biggest downside to storyboards is working a project with multiple developers. Dealing with merge conflicts can be a big headache.
I'm discovering storyboards and would like to use them for a new application.
I would like to know if it makes sense to have two separate storyboards, one for the login/signup related views and one for the main application views.
The purpose is to keep both storyboards clean and easy to maintain.
What would be the drawbacks of such approach ?
Thank you
I would suggest only having separate storyboards if it becomes an issue for you. I have gone down the path of having separate storyboards, and didn't find any advantage organizationally. It wasn't worth keeping track of which view was in which storyboard.
Once you move to a universal app it is probably more useful to have one storyboard for iPhone and one for iPad. I currently have 3 storyboards, and they are not organized according to what type of view, but which environment will be using the views.
iPhone Storyboard
iPad Storyboard
Shared Storyboard(some views you will use between both)
For me, storyboards are nothing more than just a container to dump my views, and prevents a bunch of separate .xib files all over the place(initialization of ViewControllers from the storyboard is much simpler though). I used segues for maybe a week, but then the app's needs quickly outgrew the limited benefit of transitions.
It is actually really easy to copy and paste between storyboards, so don't be afraid to try a bunch of different arrangements to see what you like. You'll just need to adjust which storyboard you instantiate the object from obviously.
Our company is developing a quite large app for the iPad. Eventually we want to be able to customize the UI per customer (tenant) and maybe even per user (of that customer). We started off in HTML5 but are moving to native.
I've done some reading on downloading XML from the server (or even generated XIB/NIB files) and dynamically adding those to your app.
Now with iOS 5 (and even further in 6) storyboarding is playing a big role.
My questions:
- Would it be better to use (multiple?) storyboards or XIBs?
- What are my options for both if I want to deliver a dynamic user interface?
I'm not looking for a magic pill, nor a discussion on HTML5 vs native, just some information on how I could deliver a dynamic interface and what techniques could help in doing so.
my response to your two questions is:
storyboard is great for scene management; it creates a visual connection between
your various scenes/views. i prefer to use storyboard for as much of my UI as possible.
however, there are elements that i have in some apps that pick up existing or reusable
or otherwise dynamic XIBs. i simply tie these together with my storyboards by loading
the XIBs in code at the location at which i want them. so, my ultimate answer for your
first question is "both", where storyboards are used where possible, and XIBs used for
dynamic scenes/views.
your options for dynamic user interface include at least the following two options (of which, as stated above, i prefer the second):
create all code using XIB files, and perform all UI transitions without storyboards
in code
create as much UI as you know will remain relatively static in terms of relationships
between viewControllers with storyboard, and then load the dynamic parts of the UI
using initWithNibName:bundle:
finally, you can use multiple storyboards if the situation warrants, and this could even apply to dynamic UI, whether it comes from re-usable components created elsewhere in storyboard and maintained separately, or storyboard XML (if you look at storyboard source, it is just XML under the hood) whether acquired from something that generated or wherever. you can even decide to manage your UI with multiple storyboards at the design phase if your app will have several complicated interconnected view-controller scenes (e.g. each tab in a UITabBarController may have its own storyboard, where each storyboard's scene rootController is connected/loaded when a tab is chosen).
StoryBoard all the way! I use to absolutely dislike storyboards, but then i got use to them and now i love them. Storyboards are the way to go.
Layout seems a really powerful framework for developing dynamic GUIs on iOS.
DISCLAIMER: I'm not the author of that framework; the author is Nick Lockwood, who seems to have an account here on SO. I found both this question and Nick Lockwood's Layout framework by googling "ios dynamic gui".
I haven't tried it yet, but it looks really promising.
The project is even hosted at GitHub here, and it has a MIT license.