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)
Related
My question would be so simple, but as I am new to iPhone development, I need to know.
I have populated my table by JSON data in View1. Now my requirement is that when a user clicks and hold a cell then a dialogue box will be opened then from there user will have to choose to save the cell data in database.
And in View2 the same saved data will be shown to user in the table.
Can we implement this in iPhone?
Please tell me if there is any tutorial/example of core data or sqlite (whichever would be the best) for beginners. Because I haven't find any tutorial for table to core data
You can use the above #HeikoG link to know the tutorial for core data..Core data is the best way to store and retrieve data from database...But you cannot bring a dialog box using long holding a cell.Its not a good interface..Better you select a cell and expand it and then you can have a button there to add a specific cell to core data database...
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'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.
Got a conceptual question: If I got a tableview with about 100 items and the user can check as many as he wants from that list, how and where do I save the checked status of each individual item for later reuse?
In your own internal structures. UITableView isn't a database. It merely is an interface to your data. Any selection, deletion, addition, etc. will have to be handled by your code and stored. Typically you have some sort of a database or structure associated with the UITableView elements. When you get a check action, you can update a variable in that structure.
For an example of an SQL database backed UITableView app, see here.
For storing the checked elements of tableview, you have to maintain your code in didselectRow mthos of tableview. So, whenever you check the tableview row you can save it in an array. And save that array in the "NSUSerDefaul". So, that whenever you close the application, you can get back your selected tableview row array from "NSUserDefault". Or you can use sqlite database but it is better to use NSUserDefault as there is simple thing to do.
Please give your response if you find any problem.
You can use NSUSerDefault in your application from the following link: click here