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.
Related
so I have a UITableView and within each cell, a UITextView. I want the user to be able to edit each UITextView as many times as they like, then go back to somewhere else in the app, close the app, whatever, and then come back and see the same thing they wrote. I have not been able to figure out how to do it.
Please help. I'm still pretty new to Swift.
This is a design problem. Anyway my suggestion is to add a flag in your data model.
Data model (the data that you are presenting in your table). If you don't have any data model, add one.
Example:
class UserInformation {
name: String
isEditing: Bool = false
}
and then save this in your preferred location either in DB (core data, realm etc) or plist (which i don't recommend)
now during the creation of cell. You could just check if this is in editing mode. And then fill up the text field using the saved data.
EDIT: You can't just magically know/retain a state in an object without persisting.
You want to store textView informations in any case, including terminating application, there are some steps to implement this feature.
At first, you have to pick up a place for storing your information:
Hard disk
Your own server
Other service (firebase ...)
RAM is not useable in this case.
Supposing you like hard disk option, let's select a method for storing:
Create a file (JSON, text file, ...), save your information every time user enter a new one, open it to get information back.
Save it by CoreData / Realm in database way (CoreData is like SQL lite, a lite weight database for mobile application supported by Apple)
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.
I am looking for a good pattern for performing basic property editing via a modal view on the iPhone.
Assume I am putting together an application that works like the Contacts application. The "detail" view controller displays all of the contact's properties in a UITableView. When the UITableView goes into edit mode a disclosure icon is displayed in the cells. Clicking a cell causes a modal "editor" view controller to display a view that allows the user to modify the selected property. This view will often contain only a single text box or picker. The user clicks Cancel/Save and the "editor" view is dismissed and the "detail" view is updated.
In this scenario, which view is responsible for updating the model?
The "editor" view could update the property directly using Key-Value Coding. This appears in the CoreDataBooks example. This makes sense to me on some level because it treats the property as the model for the editor view controller.
However, this is not the pattern suggested by the View Controller Programming Guide. It suggests that the "editor" view controller should define a protocol that the "detail" controller adopts. When the user indicates they are done with the edit, the "detail" view controller is called back with the entered value and it dismisses the "editor" view. Using this approach the "detail" controller updates the model. This approach seems problematic if you are using the same "editor" view for multiple properties since there is only a single call-back method.
Would love to get some feedback on what approach works best.
I don't think any of the Apple examples (or anyone else's) actually show you how to structure an entire real world application. Instead, each example is just a test harness which shows you how to use one particular feature of the API but pays no attention to how that feature really integrates with anything else. Data models are given particularly short shift.
I prefer a design in which the data model is the spine of the application upon which hands all the view-controller/view pairs. The view controllers do not communicate with each other directly but instead communicate through the data model. The data model tracks what information the app is currently working on and therefore what data each particular view controller needs at any given time.
Let's use a contact manager type apps as an example. The basic of the data model would be a list of contact objects each of which in turn would hold attributes of a contact. The data model would completely control access to the data and monitors which data was currently being used. The UI is hierarchal such that the user first sees a list of all contacts in a masterView, then the details of each contact in a contactDetailView and then can edit each contact attribute in a custom attribute edit view for each type of data so there is a nameEditView, a phoneDetailView, an emailEditView etc. Each has a paired view controller masterVC, contactDetailVC, nameEditVC etc.
The to build it's tableview, the masterVC ask the data model for the number of contacts, their divisions into sections and then request each particular contact object at each particular index path so it can display a table. When the user selects a table row, the masterVC tells the data model which contact object was selected by sending it the index. Then the masterVC pushes the contactDetailVC. It does nothing else.
When the contactDetailVC activates, it ask the data model for the currently active Contact object. It doesn't know or care how the current contact was selected nor even which view/VC preceded it. The data model returns the currently active contact. When the user selects a field, the contactDetailVC tells the data model which attribute of the contact was selected and then pushes the proper editorVC onto the stack.
When the editorVC loads it ask for the data model for the current contact and the current attribute being edited. It doesn't know or care how the current contact attribute was selected nor even which view/VC preceded it. When the user makes a change, it ask the data model to save the change (the data model can refuse if verification fails for some reason) and then pops itself.
Internally, I like to implement the data model in two parts each managed by separate object. One is the abstracted data manager itself in this case a Core Data stack. The second is an user defaults manager that tracks the actual state of operations in the data model and saves them to user defaults. A master object holds these objects as attributes and serves as the interface of the data model.
This type of model makes it easy to suspend, resume or restart the application back to its previous state. Since each view/VC is self contained, when you restart the app, you just push all the views on the stack without animation and the last one pushed pops up fully populated with data even though the user chose nothing in the previous views and indeed did not even see them.
It also protects the user from data loss in the event of a crash since each VC saves its data and the app state every time it pushes or pops. It's easy to add additional view/VC because each VC only has to know about and communicate with the data model instead of bunch of other VC. It makes the components of the app easy to use in different versions of the app or in different apps altogether.
Edit:
Do you just hard code some if
statements to pair up the attributes
with the correct editor, or are you
doing something more dynamic based on
the entity/attribute metadata?
In most the most common design, the Contact entity could have a variable number of phone#s, emails or other data fields so each attribute would actually be a separate entity and the Contact would have a relationships pointing to those entities. When the user selected that contact to edit in the ContactDetailView, the data-model would simply mark the NSManagedObject representing the desired attribute of the contact. It could do so by setting an attribute like "lastChosenAttribute" or storing the URI for the object. When the editor view loaded it would be hard coded to ask the data-model for the "lastChosenAttribute" and would receive an NSManagedObject for a phone#, email etc. The editor would make changes to that object and they would be automatically saved back into the contact.
For data that is singular, such as a name or name components, the data-model would provide the editorVC with the contact entity and the editorVC would be hard coded to ask the contact object for that specific attribute.
It's a tough call--the View Controller Guide recommendation seems cleaner conceptually, but the other method can be easier, especially if you're using Core Data. To give a blanket generalized opinion, I would say use your first method if you're using Core Data, since managed objects inherently have their own context and can update themselves (and classes such as NSFetchedResultsController can automatically respond to updates).
If you're not using Core Data, I would go with the "official" recommendation, since it makes it easier to manage updated properties manually. As to the concern about multiple properties, it's certainly possible to have multiple delegate methods and call the appropriate one. For instance:
//if property is an address
if ([self.delegate respondsToSelector:#selector(editorView:didUpdateAddress:)])
[self.delegate editorView:self didUpdateAddress:theAddress];
//if property is a name
if ([self.delegate respondsToSelector:#selector(editorView:didUpdateName:)])
[self.delegate editorView:self didUpdateName:theName];
This could get hard to manage, though--you'd probably want to have an abstract superclass for properties, or something along those lines.
I've been working on a Cook Book App and I've been making each page individually which takes a really long time to do, I asked a question similar to this and it was brought to my attention that you can setup a way to automate the design process so all you need to do is input your data.
Can someone please explain in as much detail as possible how you setup your xcode files/code to automate such a process
So for example I would just enter the page text and it would automatically put my standard background picture in and add a scroll view and appropriate buttons etc.
Thanks
You could make one master view that contains all the controls that you need: standard background picture, scroll view, appropriate buttons, etc, and make any subsequent views that you create inherit from this view, so that they all contain those controls.
You could also use just one view and work with multiple instances of it, one instance per page. Just make sure to have a Text property on it, or a constructor that takes in your text string, so that you could set it to a different text on each page.
Xcode project templates and file templates are pretty easy to make, with a few caveats.
Check the answers to these questions:
Add new templates in Xcode
Change templates in XCode
Also take a gander at these handy tutorials:
Custom Xcode Templates
Xcode: How to customize the existing project templates
It sounds to me like your putting your data into your views (pages). That's a big design error. You need to employ the Model-View-Controller design pattern and separate your data from your views. That will make it easy to create one view (template) that you can reload with data to display each individual recipe.
The first thing to do is to separate your data from the view. You need to have the recipes stored in an array, dictionary, Core Data etc and then wrap that data in a dedicated object. The second thing to do is to create a dedicated view to display all the recipes. As the user moves from recipe to recipe the app will simply remove and add information to the same view as needed.
I would recommend Cocoa Recipes for Mac OS X: The Vermont Recipes, Second Edition because it addresses these issues and it uses a recipe type app as its example. It's for Cocoa but the basic principles apply to iPhone apps as well.
So I am working on a simple iPhone app, that uses core data to manage objects. My code is similar in function to Apple's CoreDataBooks app, found here. There is a blank UITableViewCell, and you have the ability to add objects to this blank list. If you hit the add button, a DetailViewController pops up that manages the attribute of each object. In the coredatabooks example, the app is like a library, and you can add book objects. My question is about how I might go about making it so that multiple users can have their own separate list of these objects. Again, relating back to coredatabooks, you would be able to make different library objects whose attributes are the book objects themselves. So using the convenient and easy to use coredata ui, would it be very hard to set it up so that in the UITableView, there was Library-A and Library-B and then selecting one of the libraries would move me to a screen that has the list of different books unique to that specific library? If you then select a book, you would then be able to view that book's attributes as before. So I guess my question is regarding how to put another RootViewController-esque view in front of the native one. As you may gather from this post I am in the learning stage of iPhone development, so I don't even know if logically this is even feasible or the correct way to do it. Any help/insight on this matter would be greatly appreciated! Thanks for your patience!
Create another UITableViewController (.h, .m, .xib files). And you can put some functionality into that view controller for adding library.
You can set that viewcontroller as startup object from MainWindow=.xib file. OPen that xib file -> expand navigation controller -> click on root view controller.
then in attributes window you can select your new controller as startup. you have to also set startup class from identity window.
Ruchir is correct, you can add another table view and controller. You will have to make some adjustments so that it is loaded and displayed first.
Also, it sounds like you will want to create a new entity in your data model for a Library which should have a to-many relationship with the Book entity.
Library <-->> Book
The new table view controller can use a fetched results controller that fetches Library entities. When the user chooses a row, you can set a property on the books table view controller before you push it on the navigation stack. Then use a predicate on the books fetched results controller to only fetch books in that library.