What is the difference between window based and view based iphone apps ?
Thanks
From xcode:
The window based template provides a starting point for any application. It provides just an application delegate and a window.
This view based template provides a starting point for an application that uses a single view. It provides a view controller to manage the view, and a nib file that contains the view.
Besides what has already been said, the most important thing to remember is that iPhone apps can only deal with just a window. Therefore, you will always have a single window, even though you may have as many views (and corresponding view controllers) as your app needs.
Related
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 am creating a Universal iOs application as part of an assignment (iPad and iPhone :) ).
Naturally, they have a UI which I have been accustomed to create through the NIB files, using the fancy drag and drop schemes. This obviously seems like a great strategy when you are making a dedicated iOS device application.
However, with the universal application, I notice that this strategy can be a challenge since the 2 UIs differ and human error can promote a lack of consistency in the two UI's + double the work!!!
I noticed the solution to the assignment I am doing has the UI created through the AppDelegate file, I have never really done this, and from this stems the questions:
What is the appDelegate files for anyways?
Is it the way to create the UI for the Universal application through the App delegate? Or do you people still create the UI's through the NIB files meticulously for both iPhone and iPad?
P.S: Side question: This assignment requires me to create a Windows based application vs a View based application which is what I have naturally learnt to do. I understand a Windows based App can grow into a view based application and vice versa. However, I do not understand when you should choose to create a Windows based application?
The AppDelegate in Cocoa is your central Singleton that controls the app workflow. It's used by the underlying Framework to start the application, signal runtime envrionment changes and terminate the app. Being a singleton, it's always there and easy to reference ([UIApplication applicationDelegate]) and it loads up your first view controller.
It's generally common to let the application delegate keep refernces to model and controller objects. But what you describe, the whole UI programmed through the appDelegate, is bad style.
No matter if you use NIB's or you code your UI by manually adding UIElements to the view in code, you should do so in ViewController. Generally, the appDelegate will call the first view controller and that viewcontroller will call all view controller afterwards.
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.
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.
Like I understand, an Window has a lot of Views. A View is an object that can draw something on the screen, and the Window provides the space for drawing. So where's the point, that I dont have an window? What's the difference here between them?
On the iPhone, a window really is just a special kind of view. If you look at the docs for the UIWindow class, you'll see that it has additonal methods above and beyond what a regular UIView has. However, most of those methods seem to have analogous UIView counterparts.
The one thing I've found windows useful for is that UIViews have a "window" property that can be used to instantly access the window. If you have many nested views and need to immediately get to the top level from a 3rd or 4th level deep view, that window property can come in handy.
In a View based application we can create the foreground layout and the appearance of the application including text fields,buttons,labels..... depending upon the requirements of the project and how effective an application view has to be in order to make the application shine
In a Window based application we have the background of the view and we can also create a view using a window by using Interface Builder connections.But for building applications that work basing on the background we need to have Window based applications that runs on the console.