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.
Related
Say I have an OSX app with some sprites moving around, call them gremlins. When I click on a gremlin, I want to display some sliders that control some attributes of that gremlin, maybe scale, speed, direction, that sort of thing, then click the gremlin again to dismiss the sliders. Then click another gremlin and display the sliders to control that one's attributes. I can easily create some NSSliders and set them up in the code. But I'd much rather create a set of sliders in Interface Builder, and load them on-demand: if I wanted to rearrange them and play with their relative positions, it would be nice to do it using that visual interface, rather than having to fiddle with the code, recompile, run, click on a gremlin, and see how it looks. Plus it just seems like better design in general--but I don't know, I'm new to Apple Land, and haven't done anything professionally in this environment yet.
I've tried googling every variation I can think of on "Swift: programmatically load/connect to controls created in Interface Builder", but haven't found any demonstrations or discussion on how to do this, or even an indication that anyone does it. It's making me worry that this is just not the way things are done in Apple Land. Is this possible? Prohibitively/unnecessarily difficult? Is it what people do? If it is possible, what is it called, ie, what can I google for to find out more about it?
Try having a look for "reusing a view xib".
This seems like a good starting point: Example
Create xib file
Design it in Interface Builder
Create a custom UIView file and create initialisers for the view
Add file as owner of the xib (Interface Builder)
Connect elements from xib to Outlets
Load the xib in the UIView file initialisers
Assign it to new UIViews you create
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!
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 need to make an iphone app like USA Free that's in App Store.
Can anybody, please, tell me what kind of app is this (window or view based) and how it is possible to make horizontal slide effect when changing views?
Thank you!
For transitions, take a look at http://developer.apple.com/library/ios/documentation/UIKit/Reference/UIView_Class/UIView/UIView.html#//apple_ref/occ/clm/UIView/transitionWithView:duration:options:animations:completion:
All apps contain one (or more) windows and views. You might want to start with the basic of creating an app. http://developer.apple.com/library/ios/referencelibrary/GettingStarted/Creating_an_iPhone_App/_index.html#//apple_ref/doc/uid/TP40007595
View based just means the project comes with a default class already setup. You can put anything you want in that class. Window based is just if you want to create all the classes your self. Theres not much difference, so it doesn't really matter which you choose as long a you know how to create the horizontal slide effect your going for.
This is Cocoa Touch (et al), iPhone, XCode only.
After completing my first commercial iPhone app, I'm struggling a bit to find a way to start and expand an app from scratch which gives the most linear development (i.e., the least scrapping, re-write or re-organization of code, classes and resources) as app specs change and I learn more (mostly about what Cocoa Touch and other classes and components are designed to be capable of and the limitation of their customization).
So. File, New Project. Blank window based app? Create the controllers I need, with .xib if necessary, so I can localize them and do changes requested by the customer in IB? And then always subclass each class except those extremely unlikely to be customized? (I mean framework classes such as UIButton, CLLocation etc here.)
The question is a generic 'approach' type question, so I'll be happy to listen to handy dev practices you've found paid off. Do you have any tips for which 're-usable components' you've found have become very useful in subsequent projects?
Clients often describe programs in terms of 'first, this screen appears, and then you can click this button and on the new screen you can select... (and so on)' terms. Are there any good guides to go from there to vital early-stage app construction choices, i.e. 'functions-features-visuals description to open-ended-app-architecture'?
For example, in my app I went from NavBar, to Toolbar with items, to Toolbar with two custom subviews in order to accommodate the functions-features-visuals description. Maybe you have also done such a thing and have some advice to offer?
I'm also looking for open-ended approaches to sharing large ("loaded data") objects, or even simple booleans, between controllers and invoking methods in another controller, specifically starting processes such as animation and loading (example: trigger a load from a URL in the second tab viewcontroller after making sure an animation has been started in the first tab viewcontroller), as these two features apply to the app architecture building approach you advocate.
Any handy pointers appreciated. Thanks guys.
Closing this up as there's no single correct answer and was more suitable for the other forum, had I known it existed when I asked :)
If you want to know the method I ended up with, it's basically this:
Window-based blank app
Navigation Controller controls all, whether I need to or not (hide when not used)
Tab Bar Controller if necessary
Connect everything <-- unhelpful, I know.
Set up and check autorotation, it might get added to some view later.
Add one viewcontroller with xib for each view, you never know when they want an extra button somewhere. It's easier to copy code than make the max ultra superdynamic adjustable tableviewcontroller that does all list-navigation, etc.
Re-use a viewcontroller only when just the content differs in it, such as a detail viewcontroller.
Minimize code in each viewcontroller by writing functions and methods and shove them in a shared .m
Everything that's shared ends up in the App delegate, except subclassed stuff.
Modal viewcontrollers are always dynamically created and never have an xib.