I have a problem with my App for iPhone.
Enviroment: I have a TableView, that operates above an MutableArray datasource. An example would be Lap Times for Go cart pilots.
Datasource: I record lap times from both training sessions and from race and qualifying. I consider race + qualifying as one subset of data and training sessions as another subset of data because I think there is big psychological effect and my drivers have slower laps when racing because of fear of crashing into others. At this time I record both data in one array with a variable of Bool "fromRace". So I can filter racing and out of race times.
Human Interface: I created a TabBar that shows racing times in first Tab and training times in second Tab. It feels, like those Tabs contain basically the same view and operate on same data which I just filter using the same view controller since all the methods are the same.
Is it programatically correct to create two separate view controllers and two separate arrays for the datasource basically duplicating the code? Or try somehow to try to discover from which tab I came and alter the data presentation accordingly using just one view controller?
I hope I am clear on what I ask for.
Yes - broadly speaking, a UITabBar is used exclusively to switch between view controllers. That's how it's designed to operate - you load each 'slot' in the tab-bar up with a view controller.
That doesn't mean you have to create two separate view controllers - you could create two instances of the same view controller, and have some flag passed in upon initialisation that would display the data in a different way.
If you just wanted to have a single view controller adapt to display the data in different ways a UIToolBar would be a more appropriate UI element (perhaps with a segmented controller at the bottom).
Related
I wanted to know if I have to create a new ViewController for each view I have. Let's say I have 3 views do I need 3 viewControllers or does 1 ViewController can manage all 3 views?
Edit: Views are Objects that I create with .xib file so following the description given me by Xcode 4.3.3: represents a rectangular region in which it draws and receive events.
My situation : What I want is the main View showing 3 buttons, each button leads to a new View. That's about it each of the 3 views will have about the same thing, a tableView to display data parsed from an XML.
Thanks again!
EndEdit
Thanks
Both are possible, depends on your needs. View controllers can easily manage more than one (sub)view (e.g. every UI control subclasses UIView and you can have many in a single view controller). Sometimes it's more convenient to put views in different view controllers, sometimes it's not.
Depends on your situation and what you want to present to the user. If those 3 view controllers have very similar functions and only minor differences, then you could use the same class and have an instance variable to indicate which mode you're in. For instance if you have a list of Songs, Playlists or Videos, those could be the same class, with an enum variable to differentiate between the 3 modes. If your views are significantly different however (like a Song list and a Video player) then you should usually have separate classes for them.
For iOS, general best practice has been for a single view controller to manage a single "screen (or "window", but of course there is only one of these on an iOS device). This view controller may support a variable number of view objects (certainly not a ratio of 1:1 views/view controller).
As of iOS 5, nesting multiple view controllers managing multiple views in single window is now technically supported, but I still consider it a practice best avoided.
One window = one view controller = multiple views.
In one view controller you can manage any number of views.
It is preferable to use a viewcontroller per view. the advantages of the approch is as follows:
Any time you can convert the Template of the application. (eg. from table view to tabview or split view can make quick change)
with each view controller you follow the MVC architecture.
if you have n controller than try to manage n MVC model so that you can shift any model any where easily.
Memory management will be easy (Push and Pop manage memory automatically.)
if we have sigle view controller and n number of view than it will be quite difficult to manage memory.
Also we need to keep the screen ID for each view and need to mantain also their switching.
there are N number of advantages if you use N numbers of viewcontroller over N number of views.
This is more of a requirement than a problem.
There is a tab bar controller, in one of the controllers of the tab bar controller there is a nav controller. Below it there is a segment control, I have to display some data(which I'll get thru URL connections) in table view. On changing of segment from the segment control the content of the table will change. And the segment control changes the type of data being displayed in the table and even there UITableViewCells are different. All the three segments will display data in the table.
One possible solution is to change the data and reload the table when the segment is changed.
Other solution is to change the views (will have three different view controllers) on changing the segments and these view controllers will implement there own table delegates and will have independent table views.
First one is more efficient I suppose. Second one will keep everything(code) separate of the different segments. There are some issues though, the navigation controller is not accessible in the inner view controllers.
Can any one suggest me the best possible solution for the same?
Thanks in adv.
I looked into this quite a lot and eventually plumped for changing the data source of a single TableView. I only had two segments, cell types, fetchedResultsControllers etc. and it still made for a pretty heavy custom TableViewController. Lazy loading images, if you need to do that, is also a bit of a pain.
I didn't need to have a handle on the navigation controller for the individual table views but if that's important to you, perhaps the second approach is best. Despite the above, the first approach works pretty well having got it down. Interested in hearing any better patterns for though.
I aam planning to write a lcd numeric / 7 segment display for iphone.
(a display that consists of several numbers, each consisting of 7 (dash) segments.)
My question is, after mvc pattern, where does the 'number parsing' code belong? View or its controller?
So, should the controller pass the view just a number to display, letting the -drawRect method find out which segments to lighten up?
Or should the controller pass the view directly, which segments to lighten up, after finding that out in a method within the controller class?
As i learned so far, the controller is responsible for all logic things. But i'm not sure if that kind of logic is also meant by that.
Oh and by the way, should the controller just set properties on the view, or would it be better to call the controller as a delegate from within the view class to fetch the data?
I would say that the view should be figuring out which segments to draw. Ideally, you would be able to turn your app into an analog clock by just swapping out the view (since the numbers delivered from the controller wouldn't change.) While you don't want your view performing business logic, "visual" logic (how data should be drawn) is definitely within the purview of the view.
I'm in the process of learning and designing an app for our company. At its heart, it has a list of "alarms" which when clicked on, goes to a more detailed view with a toolbar to perform tasks upon that "alarm".
I'm having a devil of a time working out how to structure this application. I have something that works currently (i'll explain it in a sec), but now I'm about to hook up the data source for the table and I'm getting myself lost.
At the main screen, there is to be a list of "alarms". This list should be able to be filtered with 3 categories (All, Category 1, Category 2) where the categories are subsets of all the "alarms". I've implemented this using a TabBarController.
Within each tab, I've got a NavigationController (to handle the navigation of between the list and the details) and it's main view is a custom UITableViewController that contains the custom table view.
As described, when you click a item, it navigates to a detailed view. This is all currently working but I'm concerned about the structure.
It's pretty obvious that I have a fair bit of duplication with the 3 different NavigationControllers, but I've read that subclassing the NavigationController is not recommened.
My questions are:
Is there a better way to structure this application? Is there a better filtering method (thats quick and easy) instead of a TabBar?
Where should the tableview datasource go? Most examples I've seen have it being created in the AppDelegate and then passed directly to the tableviewcontroller. My custom tabelviewcontroller is a couple of levels down the controller chain, how do I pass the datasource to it, or can I make the datasource "static"?
I hope that all made sense
Sounds as though you want one navigation controller and table view controller with a segmented control at the top to switch between the different data views. For an example of this kind of layout have a look at how the App Store app works when you select the Featured tab - it has a segmented control to switch between New, What's Hot and Genius.
I'm building my second app, and I'm trying to learn from the places I stubbed my toes on the first one.
Just as in the last app, I have sections of my app that feature a view with buttons along the bottom (basically a custom tab bar) that trigger the switching of the contents of the main, big area of the screen. One is a map view, one is a table view, one is a grid view, looking at the same objects in three different ways.
In my last app, I had each of the content options be a separate view, managed by separate ViewControllers. That worked, but there were places it was awkward. Passing data among those VCs was a little tricky (especially passing back upstream), and I was totally confused by my nested view controllers not having access to self.navigationController, for instance. It could be argued that I now know how to work with that scheme (and I do), but I'm interested in a Better Way.
I'm now thinking, maybe that whole thing should be ONE view controller, and it should have separate top-level UIView objects that it swaps in and out when the tabs at the bottom are clicked.
Problem is, two of my nested views have tables on them. So I'd need to either write REALLY complex UITableViewDelegate methods to figure out which table I'm talking about, or create separate UITableViewController subclasses to manage my table data. Either way, this just eliminated most of the simplicity I was hoping to achieve by keeping it all in one View Controller.
The other thing is, having those content views be UIViews inside the same view controller has some ramifications. There's no load time to swap views, but I'm burning memory I don't need to, if the user never visits one or more of those view alternatives.
Thoughts?
Problem is, two of my nested views have tables on them. So I'd need to either write REALLY complex UITableViewDelegate methods to figure out which table I'm talking about, or create separate UITableViewController subclasses to manage my table data.
A table view datasource/delegate does not need to be a view controller, it can be any object. So you could write two custom classes that acts as datasource/delegate for the table views.
The other thing is, having those content views be UIViews inside the same view controller has some ramifications. There's no load time to swap views, but I'm burning memory I don't need to, if the user never visits one or more of those view alternatives.
You should load the views lazily in that case, i.e. do not load anything before is is needed. And release stuff that is not needed at the moment when you receive a memory warning.