What i want to do is have a textfield on the screen and a table below it, when the user enters something into the textfield, i'd like to write that value into an existing array, which is being used to populate the table? Can someone help me out with this one please?
Thanks alot
Not typically the place for people to write code for you.
That said, here's an example.
http://drop.io/blnnhnt/asset/example-zip
Notes:
- Uses Core Data to demonstrate persistent store.
- Uses standard UINavigationController, with two dynamically added UIBarButtons
Related
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.
is it good practice to share the ADD and EDIT screen to use the same UIViewController?
That is in the case where the only real difference would be in one the values would be populated with existing (EDIT).
PS. Some clarification. So perhaps take the simple case where there is just one or two NSString fields (e.g. title & description) - so is there anything wrong (e.g any gottchas) associated with using the same controller/NIB(view) for both EDIT and ADD?
Not sure about "good practise", but...
Populating a Label with one or another string is easy, also easy is hiding buttons or fields on depending if the ADD or EDIT view is displayed.
The problems tend to come when your view has received the user input and then needs to decide whether to modify an existing object or to create a new object.
So before exiting, the view has to decide how to treat user input. If the differentiation is mind boggling complex you are better off with two viewsControllers. If it is a matter of a simple if-the-else in or near the viewWillDisapper method then one view can do.
I would use inheritance in this case. Some base UIViewController and two additional UIViewControllers - one for add, second for editing. You can use one UIViewController too, but it depends on how difficult your task is or isn't. It's too general question.
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.
I'm trying to write an iphone OS app that includes a logbook feature. The problem that I'm having is that I want each new logbook to have its own categories that are user-defined, for example a chemical receipt log would have chemical name, vendor, receipt date, expiration date and comments.
The way that I'm trying to go about this is by calling an editCategory view controller when a new logbook is created that contains a number of UITextields where the user can enter the categories. I want to take those strings and apply them to a newLogEntry view controller, so that when the user creates a new log entry, they are presented with each category followed by a UITextfield so they can enter the relevant data.
The trick is, I have no idea how to grab the category data from editCategory and apply it to newLogEntry. I'm currently using Core Data, as that seems to be the easiest way to go about this, but I'm not married to it if it interferes with a good solution. Also, I'm still more comfortable with genetic code than objective-C code, so please bear with my ignorance.
Have you considered using the App Delegate? You could keep those values in the App Delegate, and call on them in the ViewDidLoad method of your newLogEntry view controller.