I need to show data reading from local XML for a books app. I have to show data in different ways, eg. list of authors, list of editors, list of genres, etc then showing the book details.
Which is the best way to organize ViewModels? Can I have a single BooksViewModel class with the various GetAuthors, GetEditors, etc or should I have AuthorsViewModel, EditorsViewModel, etc?
Data is present in local XML and cannot change.
The ViewModel follows the view. So if you're having a separate view (page) for each type you wish to display the information for, then yes, several viewmodels makes sense.
But if your for instance, have a single view for all the data, for example a pivot, and then having a individual pivotitem for each data type, then you would use a single viewmodel, with several observable properties.
Related
I'm working upon a small-scale enterprise database application. It works with such business objects as Vendors, Device types, Devices, Suppliers, Invoices, Departments, Employees etc., so I need to let users view and edit data from all these tables.
My first approach was to create a pair of forms for each type of business object:
a table to view and select an object
an editing form for this type of object
But now I find it hard to maintain all these forms, because e.g. if I want to change the look of all view forms, of course I have to edit each one of them.
So I want to replace all my view forms with a single one "template" form and to call it with some kind of parameters. The problem is, I don't know the right approach to perform it. Maybe there could be some example in some book or somewhere else?
I think the best way is by using Visual Form Inheritance .
Actually we use this kind of programming a lot, it keeps maintenance pretty simple. Stick your base functionality in the parent form, and specific behaviour in the child forms.
I am creating an iPhone app that allows you to specify certain criteria, fetches a list of events from a web service, and lists the events in a table view so that users can add the individual event to their calendar.
How should I approach this with the MVC pattern? Will be using JSON.
Any ideas?
If you are going to be consuming JSON based web-services, you might want to check out AFNetworking. I wrote a network class to work with AFN, check out this SO post for the code.
User calendar and the list of events and how you fetch them is the model. Table view is the view. Classes that glue the two together are the controller. Doesn't matter if you use JSON or whatever else if we are talking about general architecture here.
What is the best way to store static data in MVC application? Data like country and cities.
1- Should the data be stored in database and called everytime a view requests it and populate the dorp down?
2- Create partial view of countires and use it in different forms when needed?
3- Create static classes?
4- Create class and static method which returns the list?
5- Use caching?
Or any other idea would be appreciated.
Also the dropdown list should work with ajax, like selecting country should load the cities, selecting cites should load the region?
Hekim Başi
MVC stands for Model View Controller. Controllers 'control' your data, they do something with it, views are pretty much html, to show your data to users. Models are what you are looking for here, they store data in a way you can acces easily. As soon as you get the data you want, you store it in a model, then acces (and maybe alter) that data with your controller and finally pump it to your view, so the user sees your application.
Does anyone know of a good way to start with a basic model but not use Core Data yet? I have a simple application that doesn't need to save any data (at the moment), but I don't think Core Data would be overkill for it.
I don't want to use the App Delegate to store data, nor do I want to store data in individual views. I was hoping to find some sort of "transitioning" type of solution that would let me switch over to Core Data in the future.
I've seen some simple examples, but they require storing an instance of the model within a particular view controller. I plan to have several views, so I want to find a better way.
The data model for an app can be as simple as a dictionary, or an array of dictionaries, or a plain old C-style array of characters for that matter. Or, to take it one step further, you might create a custom model class that not only stores the data but also knows how to manipulate it as necessary for your application.
How each controller gets access to the model is a different question. Some people like to use a singleton (I don't) so that they can access it globally. A (IMO) better approach is to instantiate the model in an object like the app delegate or root view controller, and then pass either a pointer to the entire model or a pointer to part of the model to view controllers as needed. An address book app might pass just a Person object to an address detail view controller, for example.
When working on an iPhone project, it can get really messy and many files are created (libraries, view controllers, interfaces...) What's the best way to organize your project files? What group structure do you use? Should I follow the MVC paradigm into groups?
Thanks!
Whatever makes the structure of your application most obvious is the short but ultimately unhelpful answer. I'm not sure that there's a single, correct answer.
As a one data point, here's roughly how I've structured my most complex application:
Application-wide data (model) has its own group
Utility classes/functions get their own group (sometimes nested where they require multiple classes of their own)
I have a UI group for simple views. These classes often also contain the controller
I have a bunch of other groups for series of connected views. For example, I part of my app displays tags and there are two or three views related to this. I group the views, the controllers and, sometimes, the data together
The grouping does not mirror the class structure. My general rule is that I want to have files I'll want to modify at the same time close together.
We normally have a group for view controllers and custom list cells.
In our current project, we also have a group for XMLParsers (we have quite a few of those, thread-born instances to parse incoming messages from the server).
The MVC paradigm is basically moot here - of course, it is one you should follow - but I see XCode's groups as much more than just pandering to MVC in terms of filesystem layout.