In iPhone development for every page you see there are 2 files, a nib file, and a view Controller (books.nib, booksViewController.m), but in a Cocoa application apple suggests to have 3 files (books.nil, books.m, booksViewController).
What is the point of having 2 class files? is it a bad idea to connect the attributes to the outlets in the interface, in the same file that the logic goes?
so keep it exactly like iphone a nib file, and ciew controller?
I think you've misunderstood. If you were creating a Books app for the iPhone, wouldn't you have a Book class for your data model? That's the "third" file you're seeing. You have one file for the controller class and one for the model class. It's a basic MVC architecture (with the nib being the "V").
But there are differences in how applications are structured on the two platforms. It basically comes down the fact that iPhone apps are always fullscreen "kiosk"-style systems, while Cocoa apps are window- and document-based. In a Cocoa app, a view is just an area of a window that you can paint in and respond to mouse clicks, and view controllers are support objects for laying them out. On the iPhone, your entire app interface is essentially a stack of view controllers, each of which manages a whole screen.
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.
I've read a lot about MVC as I'm ramping up with iPhone / IOS development. However in the various sample files I've see so far I'm not really seeing separate classes for model, view & controller?
How should I concretely see MVC in action with a best practice developed iPhone application? For example perhaps one based on a NavigationController & some Table Views etc.
For example:
Should there be a separate Model, View & Controller for each "iPhone UI controller" - noting that there seems to be 1 page == 1 UI controller in iPhone development from what I'm seeing, then my question is effectively should each UI Controller have it's own View file and Model file?
Given that Interface Builder and NIBs are a big part of things, to what extent is a NIB considered to be part of the MVC pattern? e.g. does the creation of a NIB effectively implement the "controller" and the "view", leaving you to create a separate class (in a separate file) for the model?
What happens when you've got shared data (or a shared model - e.g. a list of items) that is shared/used by multiple application pages (e.g. list view, edit view etc) - in this case this seems to me you would have 1 x model, but then reuse this model instance across the separate pages (which are View & Controller).
Hope this makes sense...
You'll be following MVC by using the objects and tools in their typical use. A UIView object is used to present data and receive input (View). A UIViewController responds to events and routes the data back and forth between the data model and the UIView hierarchy (Controller). Your data model lives wherever you want it to, sometimes composited together with your UIViewController subclass, sometimes present in the app as a singleton class (Model). When you specify your shared data model as a singleton class then any class that needs it can access it from anywhere in the app. By maintaining this division of labor, your application will tend to be well-organized and modular, and you can maintain/extend one aspect without having to rewrite all the other aspects of the program.
Interface builder is a tool for visually building the view hierarchy (and to some extent the control hierarchy) of your application.
I am primarily a web developer (ruby, python) that is new to iPhone development. I've done some desktop development in the past within the MS environment (C#), but never anything on the mac.
I'm trying to build a really simple iPhone application and I am confused by the way that views work in general. If someone can provide advice for my particular problem, along with some resources where I can learn how to architect iPhone views in the future, that would be awesome. I feel like a lot of the Apple documentation that I've come across is too specific - I am lacking a fundamental understanding of how views work on the iPhone.
My particular problem looks like this:
I need one view that displays some downloaded text content. This is the view that shows when the app loads, and it is pretty straightforward.
Then I need a settings area (I've already decided I don't want to use the iPhone settings area). The settings area main page will have some text fields on it. It will also have a 2-row grouped table. Each cell in that table will take you to another view which also has a grouped table used for multi-select. I suspect that I can reuse the same view for these two final "detailed setting" views.
In summary:
home page
settings main page
detailed setting 1
detailed setting 2
Any help and advice appreciated.
It sounds like you already have a good idea of what you want each of your screens to look like; that's a good place to start.
What you're probably going to want to do is use Interface Builder to lay out the objects in each view (textfields, buttons, etc.), and then have a custom View Controller (subclass of UIViewController) for each view. You would then navigate to a new view by doing something like:
MySettingsController *controller = [[MySettingsController alloc]
initWithNibName:#"SettingsView" bundle:nil];
[[self navigationController] pushViewController:controller animated:YES];
(assuming a navigation-based app).
If you haven't yet, I recommend reading Apple's View Controller Programming Guide
Some advice: Despite your back ground, don't think of the views as pages or the app as a web site. That will cause you problem in your design because the technology is different and views don't work like web pages and apps don't work like web sites.
The major difference is that while web pages often contain actual data, views do not. The view object is only concerned with display. It doesn't know what it is displaying and it doesn't store or logically manipulate the data. The data comes into the view from the view controller which itself gets it from the data model.
See Cocoa Core Competencies: Modal View Controller
Rails uses MVC if you've used that with Ruby. The basic principles are the same.
Well, there are plenty of information on Apple developers' pages: you could start reading Your first iPhone application
There are quite a few good sites with very good info both on cocoa and iPhone developing:
Cocoa with love
iCode blog
and many more (google is your friend in this).
A couple of books I liked are "Beginning iPhone3 Development" and "iPhone developer cookbook".
The first is probably more useful at the beginning (no pun intended)
As for the specific case of yuor application, you could use a navigation controller for the settings page, and each time you need to dive into the details you will just push the right view onto the navigation controller's view stack.
So you would design 4 views with the interface builder
Main view
Settings view
Detail 1
Detail 2
And then push the views onto the navigation controller.
It's pretty straightforward, I won't go into the details, but just searching something like "iphone navigation controller example" on google will give you plenty of samples that you can easily adapt to your needs.
These were all helpful responses, in particular the reference to the iPhone View Programming Guide. This helped me to diagnose my misunderstanding which was related to the role of View Controllers, and the relationship between individual views and view controllers. I think part of my confusion came from learning MVC in the context of Rails, where this relationship is quite different.
For others looking for advice in this general area, I would recommend checking out Lecture 6 from Stanford's iTunes U iPhone Application Development course from Winter 2010 "Designing iPhone Applications, Model-View-Controller, View Controllers", and the lectures 5 & 7 if you have time. I think that was when the penny dropped for me, despite having already looked at a few of the books mentioned here.
I'm new to xcode and the iphone sdk. I've been working with the view-based application for quite a while, and I was wondering if a utility application and a view based application involved the same type of coding. Can someone point out the difference for me?
Thanks
The both use the same frameworks, the only difference is how they are set up by default. The unity template provides a two view application (by default) and the view based only one.
It seems that Utility application in Cocoa-Touch is just a simple application template for application with 2 views.
This is apparently good for simple apps which have primary screen and configuration screen.
Have a look at Understanding view controllers in Cocoa Touch which has some explanation.
It depends from what point you looking at differences. You still use cocoa-touch for your application. The difference is that simple view based application is a simple template for one screen application, you can extend it as you like. Utility application is simple template for an application with 2 views but you can extend it as you like.