I have a UITableViewController, I have 4 types of tabular data to present in the same format. Is it better to use one UITableViewController and reload data each time I need to present data, or should I create four UITableViewController instances with its own data source?
Points I considered (which I'm not sure if true):
I could save resources by reusing one instance of UITableViewController.
However, always calling UITableView's reloadData before presenting the grid might have impact on performance.
What is the best approach in terms of performance / memory consumption / best practice? Or is there no difference? Hope I am clear.
Update: To be exact, I have popover controllers with a table. I use it to as a "Selection Screen" for various fields in my screens.
The number of fields needing the popover are dynamic, so there can be 4 in one screen or upto 10 in another screen. The dilemma is should I create multiple instances of selection popover (one per field), or should I just use one selection screen and reload the data per field?
Short answer :
It doesn't really matter unless your data sets are massive (thousands of rows). Whatever is easiest for you is fine!
Long answer :
I would have a different one per data type - it's probably going to be a slightly more responsive ui if you do (as you pointed out, this comes at the cost of more memory usage).
However, I would use delayed instantiation i.e. only create them the first time they are asked for.
I would also release them if I received a low memory warning notification and they weren't visible.
Related
The UITableView can be used to create a list view if the at least the UITableViewDataSource is adopted by the relevant class. I have the below questions:
Why is it designed in such a way that based on the section and row , the controls are created through data source methods and given back to the UITableView instance. Why not provide all these information in UITableView instance with out using the UITableViewDataSource. What difference is it going to make?
EDIT1:
#hermann and #JOhn: You have mentioned that it breaks the MVC pattern. Let us assume I am creating a custom UITableView like control myself. I design it in such a way that I do not pass the data directly to the UITableView but instead I pass the relevant subviews that needs to be added in the rows and section and their relavant headers alone. I think this will not break the MVC..Am I correct? But still it has the problem that the current UITableView implementation style solves..the ability to reuse controls and images instead of bloating the memory usage.
First, doing so allows to stick on the MVC pattern. A UI object, meaning a view, should never directly communitcate with the model, wich is the business data. Plus it should not perform any business logic, which belongs to the controller.
Second, it is more flexible without the need of subclassing the UITableView object.
Third, the full concept is quite efficient from a performance and memory management point of view. Instead of loading all data upfront, that may be displied within a table, it can be fetched or calculated or whatever on a just in time "need to know now" basis.
Plus data containers, especially memory consuming once like images, can be released as soon as the data has been provided using the delegate/data source methods.
Of course, a subclass of UITableView could do the same in principle. I just doubt this would result in more maintainable code or even save any time or work resprectively.
If you don't want to stick with MVC, then feel free to subclassing the table view and hand all its data over in its init method or enable the table view subclass to load all that data from webservices or data bases or wherever it comes from.
And when you run into problems and get back to us searching for guidance, then be prepared for some nasty replies like "Why don't you stick to the established best practices or the MVC pattern?" ect.
In the event that your very table just displays some rather static values, such as if it just acts as menu for further navigation drill down etc. then this concept may look a bit rediculous. But it does not hurt either. And when it comes to more complex tasks of data providing then it certainly has its advantages.
Give it a chance. Give it a try!
For MVC you want to try to clearly separate what the model, controller, and views are responsible for doing. By allowing the view (tableview) to ask for the data from a delegate, the view can be create extremely generalized.
Using the delegate pattern, the controller can "stage" the data in anyway that is wants and then give it to tableView as the tableView needs it. The tableView doesn't care where the data comes, how it was transformed, what ADT is used, nothing. It is complete ignorant to where or what the data is. All it knows it should show this string at this location for this section and row.
I'm developing an app for iPad. I have a form (UIViewController) for adding new records (of type Person) to my sqlite3 database.
For updating (i.e. modifying) records, I was considering using the same UIViewController, but I want to know what's better: one UIViewController for adding and another for updating, or one UIViewController for both adding and updating?
It depends on the amount of overlap.
If updating a record presents all the same information as creating a record, then it will be less lines of code, and less duplication, thus easier to maintain if there is one view controller.
You could even have two different storyboard views using the same view controller. This will let you give a different look when creating or updating records. I think it's good to have a noticeable visual differences for different operations. It gives a visual clue to the user as to what operation they are currently performing.
On the other hand, if there are different business rules when updating records, or if there is a different workflow when creating a new record, then two view controllers may prevent lots of branching code reducing the cognitive complexity.
In this case, you may want to consider subclassing one view controller from the other.
The question is a little vague. Let me check my understanding:
You're writing code in Obj-C that involves a type called Person that has some information
You have a form by which a human fills out the information in type Person.
You then helpfully give that human an "updating" notice of some sort, so they know you're working hard, not hardly working.
Your question is whether you should use one UIViewController for the form and one for the updating notice, or use one that covers both cases, correct?
If that's your question, I'd answer that it's largely a matter of taste, but you probably don't need a whole new UIViewController for the update notice. I'm not even convinced you need a different view, never mind its controller. You can do it either way as you prefer, but I'd recommend the simplest option that does what you need.
I'm writing an application where a user can add and remove objects from several lists. In order to save their lists even when the application crashes, I want to write them to the disk every time they change. My current plan is to create a class that observes the lists and thus is notified each time one changes, in order to archive them (the lists and all objects in them follow the NSCoding protocol).
It should be noted that I know in advance how many lists there will be, and that these lists are not expected to grow to more than 100 items in length (most will be 10-20).
Is this the best way to achieve what I want to achieve? Should this even be a problem I am worried about, or is it acceptable to only create mementos of these lists when the application exits? I was also considering subclassing NSMutableArray to make a class that saves itself whenever it changes, so that no one class must be aware of all lists that should be saved.
First, good instinct here to worry about the user's data. Yes, of course you should fix your crashes. But even so, you should be protective of the user's data first and foremost. Secondly you should be worried about the user's battery life. So you shouldn't hit their flash drive too often.
If the number of changes aren't large, then I'd recommend creating "list" objects that has-a NSMutableArray (rather than is-a NSMutableArray). You can just write yourself to disk anytime someone calls addItem: in order to always be in sync. If changes happen very quickly, it's pretty easy to build trampolines that will save "every second if there has been a change, but no more often than once a second." (If this is any problem, add a comment and I'll post some code or blog it; it's not difficult.)
I'm working on an iPhone application and trying to conform to MVC as much as possible (I'm still learning). I have an Unsigned integer in my data model that represents a number of seconds. I want this to be displayed in a view in the format '00:00'(minutes:seconds). My question is, where should this formatting take place?
Is it the model object's responsibility to be able to provide it in this format?
Does the controller format this after taking it from the model but before passing it to the view?
Or does the view handle the formatting?
Thank you for any help.
If this formatting is only used in one place, the best solution is to put formatting into the view, and this approach often works quite well. If you do not have a custom view, however, then it is natural to put this work into the view controller. In Cocoa's version of MVC, view controllers are allowed broad flexibility in how they manage the views. (This is a significant place that Cocoa's MVC differs from SmallTalk's MVC, which it is based on.)
But what if you want to share the same formatting between views (or view controllers)? Then you factor out the formatting code into an NSFormatter subclass (or use an existing NSDateFormatter in your case). You can pass these around, put then in ivars, or even create a Singleton to hold them.
Why not just put it in the model in that case? Well, say you have four views that show the time this way, but you then add two other views that shows the time as 00:00.0, and then there's one accumulator view that shows hours and minutes. Now you have to keep expanding the model to handle these cases. The model is picking up more and more information about the views. Keeping the formatting in a formatter allows you to share the code (and bug fixes) without polluting the model with these details. And views that have very special formatting needs can still have their own custom code.
There's no need to create separate NSFormatter subclasses for every kind of formatting. You can create a single MYObjectFormatter class that takes options like "hours," "minutes," "seconds," etc. It would work just like an NSDateFormatter in this regard, and give the simplicity of use you need, while keeping your formatting code out of the model. This is exactly how NSDate and NSDateFormatter are partitioned.
You're likely to run into a range of opinions on that one.
Essentially, as it's purely presentational, I'd put it in the View layer; there's no control logic, it's entirely a question of formatting some existing data for display.
i have a more or less general question about using coredata the most efficient way.
i have attempted two different approaches of managing data that is shown in a view of my project.
Approach 1: when the view gets loaded i perform all coredata fetches and store the results in an array, the view then retrieves the displayed objects from the array. (ie: objectAtIndex:...)
Approach 2: the viewcontroller itself lets my data handling class perform fetches on the go, whenever a specific coredata object is needed it gets fetched.
on my current project this involes about 200-500 objects that need to be sorted and displayed in a tableview according to their attributes.
the fetch methods are the same wether i load all objects first or when i load them in batches (of correct attributes).
the difference is mainly in the cellForRow method where i have to decide if i want to pick the objects out of an array or directly from coredata.
both methods work just fine, i dont really see any performance differences just now, but i fear that with scaling of the project & more data one or the other way might be slower.
what do you think is the better way to do this?
With larger data sets there may be an advantage in terms of peak memory footprint to using NSFetchedResultsController controller that is, presumably optimized to fetch just the right amount of data from the persistent store based on the table size.
With NSFetchedResultsController you have control over the fetch batch size which you can tune for performance based on the size and number of the managed objects being fetched, etc.