UIScrollview to display a custom UIView made up of core data attributes: Logic for designing that?

Could you tell me if my logic is sound? Because I'm still very new to iOS (going on about a week) and would really appreciate your feedback before heading off in the wrong direction.

I h开发者_StackOverflow中文版ave my core data setup with a photo entity. And what I'm trying to do is create a 'note-card' like object within my UIScrollView. The note-card will have a UILabel at the top, followed by a UIImage in the middle and two UIButtons beneath the image (i.e., buttons will be 'send' or 'cancel'). My goal is to have these note-card like objects scrollable like pictures, including a page turner.

For the most part I think I have the ScrollView and Page Turner parts taken care of. I'm just unclear as to the best way to create the note-card objects.

Should I just create a subclass of UIView and then programmatically create the note-card instances or is there a way to create a XIB file for a UIView so that I can create IBOutlets from the class to the view? Because if the latter is possible I'd like to do that but don't know how to make the XIB file accept outlets from a UIView object, as opposed to a UIViewController.

Outside of the custom UIView I'm still unclear as to how I should approach querying these objects from core database so that upon loading the 'pending decisions' window I have scrollable objects to make a decision on.

In my UIScrollViewController class, under viewDidLoad, could you tell me if I need to use a For Loop made up of FetchRequests along with code that then alloc inits and sets my UIView variables using the core data attributes? Because I'm just unsure of whether that sounds right and if there is a better alternative.

---

You can create a custom XIB and UIViewController-descendant class, just like any other view, and reuse it in your scrollview. This saves you from laying out the subviews manually, and allows you to encapsulate any logic around formatting strings to display. Using this approach the custom notecard view will work if standalone or as a subview in something else (like a scrollview), and provide a consistent interface to the user.

You can connect outlets in a View to any object you desire - if it isn't a UIViewController derived class it can be referred to in the XIB as a Proxy Object. You set the class of the proxy to your custom class and connect the outlets as usual. It gets a little wonky when you're creating the view though, as you need to pass an instance of that custom class (the Proxy you defined in the XIB) to the NSBundle loadNibNamed method in the options dictionary. It works, but I usually use the previously mentioned solution, as it allows the view to work correctly independently without any additional code.

In both solutions, I have a designated initializer for the view which takes the Entity as a parameter so the view can set itself up, as well as a property which can be used to change the entity after the view is rendered (the setter for the property causes the view to update and animate when it changes)

Either path you take, in the current SDK (< 5) the subviews will not participate in the usual view lifecycle (viewDidLoad, viewDidUnload, etc). Only the primary view controller (the one displayed using push/popViewController, presentModalViewController) has those methods called, so if your subviews have code which gets executed in one of those lifecycle methods (and they probably will) you'll have to create your own plumbing to notify the subviews of what is going on. Since the SDK 5 is still under NDA I can't say what is different in there, but I can say that if your app can wait for 5, your life will be much easier. Take a look at whats new in 5 and you'll know what I'm referring to.

As far as loading the data, it's hard to recommend what the best method is without knowing more about how your application loads info, how many records are displayed at a time, etc. In general, you should make as few fetch requests as possible, while not loading more data than will be displayed immediately. In my projects I usually:

• Create a single FetchRequest per 'view'
• Set the batchSize of the fetch request to 2.5 times the size of a screen (an arbitrary value that has worked well for me)
• I always create custom NSManagedObjects (shameless plug) for my entities. It makes working with the entity easier as it provides autocomplete of property names, and is actually more performant than getValueForKey: (according to apple)
• If the entities have a lot of data in each, I experiment with setReturnsObjectsAsFaults to see if delaying the load of the heavy data helps memory more than it hurts performance
• If I only need a couple properties of each entity, I refactor my entities so that there is a 'header' entity with just the properties I need in the list view, and a 'full' entity with all the data (referred to in the header to make it easy to load for a detail view)
• If I only need one property from each entity, for example to get a list of unique dates appointments occur on for displaying an indicator in a calendar, I use the propertiesToFetch combined with NSDictionaryResultsType to return just an array of those values