I have a UITableViewController which is starting to get a bit crazy with all the switch statements for each UITableView delegate.
Does anyone have any suggestions or examples of more of a data driven implementation for a UITableViewController? I'm thinking some type of data structure which would hold references of where to go to get cells for certain section/rows, where to get the section names, etc.
I think the More iPhone Development book describes something like this, just wanted to poll the community and see if anyone had some lessons learned on their own implementation.
I don't think there is a standard one that is generally suitable for everyone, but it's not too hard to whip up your own to suit the needs of your application. Basically, you want an array/list of sections, and for each section, an array/list of items. For each item, you'll want to allow specification of an image, text, detail text, and some sort of action to be fired upon selection.
If you want to get fancy, you can specify background colors, fonts, and other such things for each section heading, section footer, and item.
If your list items don't all look the same, then your tableView:cellForIndex: implementation needs to be smart enough to use different reuse identifiers for different-looking items.
A nice thing about this approach is that you can often use the same view and same controller for many "screens".
Consider using Core Data and NSFetchedResultsController.
Core Data's NSFetchedResultsController will do most of the data work for you. It might be overkill if your model is simple or not persisted though.
Related
Im currently working on a project where I want to the user to be able to chose between two layouts (list and grid) at runtime. I was searching for examples in the UI5 documentation (Sample Apps) and on GitHub, I did not find examples for how to to this or best practice examples. So I thought about how I could achieve this behaviour and had multiple ideas, but somehow none of them feels like doing this would be best practice.
Idea 1 - Destroy the "old" controls and generate the new controls inside the Controller
My first idea was to destory the controls I do not longer need. For example if the user wants to switch to the grid layout, the list and every control related it to it gets destoyed. In the controller the needed controls for the grid are created and then rendered in the view. In my eyes this would mix up view and controller logic inside the controller and does not feel like best practice
Idea 2 - Create two views and switch between them
My second idea was to create two views, each for the layout I need and switch between them. This would mean a lot of code replication in both the controller and the view. Does not feel like this would be the right way.
So I would be glad if you have own experience on this or if there is really something like a best practice for such a behaviour.
Thank you and kind regards!
I would say, idea 2 because of the following reasons:
It is best practice to work according to the MVC methodology which means separating logic, view and data. Since the controls define your view it is best to instantiate your controls in the files that are meant for it (the XML Views).
Performance: Destroying all controls means that if the user decides to switch between views, the controls have to be re-instantiated by the controller every time. This is, even though you probably won't notice it, not performant.
You don't need code replication: The argument of code replication is not necessarily true. If you can execute the same actions in the list and grid-view, it should be enough to just link the controller to both views and in that case you'll hardly have to replicate any code. Just make sure that you split your logic in enough functions. That way you might need to write some extra public functions to handle events, but not much more.
I'm currently working on developing a desktop application for MacOS for downloading batches of audio files from URLs at one time I've run into a question about UI design that I can't figure out.
I have a class called SongEntry.swift that holds information regarding the URL that was entered (e.g. url, title, length, author, etc.) and I want to create a vertically growing list of custom views that updates when a new one is added.
Where is what the base view looks like:
Inside of the big white area is where I want the list to be held.
I've tried to create a separate view controller that handles each entry but that didn't work. I know UI design for MacOS is much different from iOS, however I think what I'm looking for is a way to simulate the table views and cell prototypes from iOS but can't find a suitable option.
If anyone knows of a possible solution or can point me in the right direction, I'd greatly appreciate it!
What you want is one of the collection views. For vertical list, you'll probably use NSTableView with only one column and hide everything else like headers.
Here are roughly the steps you need:
You can use your existing view controller or create a dedicate view controller for just the table (and use the 'embed' option in Interface Builder)
This view controller will adopt the NSTableViewDataSource and NSTableViewDelegate protocols to provide the data (your SongEntry objects) and the view for each row.
You set your NSTableView's source and delegate to your view controller.
You create a view which will serve as your "cell", it will be used by each row to display the data. You can design it either in IB or in code.
The entire process is described in detail in the Table View Programming Guide for Mac.
This topic can be a bit confusing. Note that there are two main approaches: the view-based and NSCell-based tables. Don't bother with the NSCell way, it's more of a legacy leftovers.
Also note that there are some overlap of methods in both NSTableViewDataSource and NSTableViewDelegate to provide data and views that can be a bit confusing at first. Just play around with the code and samples and it will be clearer which delegate method to use when.
There are many examples both on Apple's developer site and github. Also a good tutorial on raywenderlich.com.
Any code examples for using a UITableView to implement in-app settings?
That is where to get the iPhone settings app look and feel one custom builds the settings into a UITableView. So you you would custom set the sections and cells that get returned with switch type statements.
In particular interested in reviewing the coding approach for how to:
best configure the cellForRowAtIndexPath and didSelectRowAtIndexPath
how to handle those cells for which you want in cell editing (e.g. text)
those cells where you need to launch off into another screen to set a date/time for example
how to collect up parameters and pass back to calling rootViewController (in my case need to persist data out to Core Data persistence)
Note: using Core Data so not interested in using libraries such as InAppSettings [any feedback re whether such libraries might be ok appreciated at this SO question I created].
thanks
I am not sure if you can use the inappsettingskit for your needs. It is open source so you are free to modify the code as you wish, but it doesn't look as an out of the box solution.
If you want to make these settings available in the settings app you will have to live with some workarounds for example saving NSDate AND getting a nice UI control to modify it: Use a textfield, there is no control specified which let's you pick a date. Have a look at Apple's documentation.
So the last option will be coding. First of all, determine what kind of types you want to support. Then create custom TableViewCells which reflect those kinds. If some kinds do need some special way of editing, for example a color picker, you'll have to write those controllers as well. You set a cell into editing mode with the delegate method tableView:didSelectRowAtIndexPath and present the custom controller or get into editing directly for example a UITextField. A Slider is handled directly without any coding.
The cells will need some kind of identifier so you can identify those in your model. A TableView and Core Data can interact with each other pretty well by using the NSFetchedResultsController. Create a simple window based app with a template and check the Use Core Data for Storage. The rootViewController illustrates how a tableView works together with Core Data. For your case it will be getting a bit more complicated as inserting a row will have to determine what kind of cell it should add.
I think you should look into this and get back with some more specific questions.
Do you create a Viewcontroller per view screen? or should you share a viewcontrollers? (ie in the example below Should there be 3 controllers or just 1 controller?)
Example
Screens are related
Screen1 (input information),
Screen2 (Review and confirm Information),
Screen3 (thank you / status response).
You should code according to the MVC paradigm. Parcel out your code and separate it based on overrarching function. Here is a high level overview of MVC
(Data) Model: contains all of your app data, objects that are passed around and used to populate the views
View: everything that is some sort of visual output
Controller: Classes that make the models and views work together.
What this is saying, in iPhone development parlance, is don't just jam a bunch of code into your UIViewController subclass. If you want to change the way part of the system works, having one huge class with a ton of code in it is a lot harder to edit and fix, than several smaller classes with a specialized use.
To answer your question, you should most definitely use one controller for each view function, but going beyond that, you should create specialized classes that take the inputs and manipulate that data, create specialized classes that then use the data to send it back to the user in an output.
Don't put all of your code into one class. It might work, but if you ever need to tweak it, or, just like when the iPad came out, it has to be adapted to use on another platform, it will be easier to manage if you only have to change something small to make it work
In your case you definitely don't need separate controllers. In fact you don't even need separate views. You can create a single view to take information, process it in the same controller and show the result in a UIAlertView.
What is the best practice for storing font information of labels in Cocoa-Touch following the MVC paradigm?
In my data model I would like to store information that are displayed by a custom view as UILabels. It is evident that the label text belongs to the data model. But where should I store the corresponding font (and in my situation also color) information? Do they "belong" to the data model or rather to the view?
The reason I am asking is this: If I simply add a property of class UIFont to my data model, I will run into trouble when serializing and copying my data (since UIFont does not implement the NSCoding and NSCopying protocols), whereas the other classes that I typically use for my data models do. (The problem does not exist for UIColor since one already has NSCoding and can easily add NSCopying, although one could still ask if the color should "belong" to the data model.)
In general I would like to be able to serialize all properties of my data models and this seems to be a very common and general pattern in MVC. Of course, I could also write an abstraction of font information rather than use UIFont directly as a property in my data model. But I wonder what the best practice use of MVC on iOS is in such a case.
Update: Thanks for the answers. I have decided to go with the "style model" implementation in those cases where I believe it makes sense to store font information in models. In order to overcome the difficulty mentioned above I have simply written categories for the two classes, see this link.
If the user (or external input) can select the font, it is part of the model.
You can store the font name
I will prefer not to store view related informations like font, color etc. in data model. Rather than I will use a separate class to store all styling information (That class may read from a plist file). In general the color and other styling properties of all labels, buttons etc. in the app will be same. So I want to change this information in single place and want to propagate it to every label. This styling information has nothing to do with the data the labels are showing.
The summary is I will prefer the separation of data and styling (You can call it StyleModel, if you want). Obviously other people can choose otherwise, and the decision may also depend on the application details. (Benoît's answer shows an example where style info might be a part of data model.)