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.
Related
The backend developer has designed the RESTful API in such a way that when going into a section of the site I call one large request for all the data in all the sub sections. These sub sections data can be modified and saved. If that happens I would need to create a new model based on the model from the large request, populate it, and save it to a different service (PUT). This service can only PUT and not GET. I would probably create this model as soon as the user navigated to this section, and display the view based on this new model. Now if i navigated to another sub section, that large request model would be out of date and I'd have to fetch it from the backend again instead of making a smaller request for that section.
I propose to him to just create separate services for each sub section that i can easily fetch and save to (I'm using Backbone). Otherwise I'm creating sub models off a main model and they are dependent on each other and I'd have to write the code to wire them together instead of leveraging the power of the built in methods on the model like save, sync, fetch.
Does this not also create an issue in creating modular components if models are depending on other models?
Has anyone seen it done this way?
I'm in a similar situation. Our API was designed under the philosophy that a single request should give everything needed to render a page. So there's one major API endpoint that returns a main data type, and all nested objects are returned in a partial state. So if I'm requesting "employees", the API won't give a "department id" it will return a partial department object like:
department: { "id": "1", "name": "Department A }
There are great benefits to this approach! Making multiple requests is expensive, and you don't want dozens of API hits for every page load. The problem you'll find is that Backbone was designed for one to one mappings between models and API endpoints. They don't give you anything like a Data Access Layer, if they did both our problems may be solved.
My team generally would make "department" an attribute for the Employee model. This has a big problem. The way that Backbone Models register changedAttributes doesn't play nice with complex objects in attributes, which complicates forms based on data structured this way. It's somewhat frowned upon by Backbone developers too. The general consensus is to store complex objects in a property of the Model class, rather than an attribute.
In any event your parse and toJSON methods will get a lot more complicated than what you'll typically find in examples.
I would recommend you to use BreezeJS, which is built only for data rich application. Check out this link
http://www.codeproject.com/Articles/730450/Creating-Single-Page-Application-using-Hot-Towel-T
I was not able to find an answer for the following... please gimme an advice.
I have a form that is built dinamically basing on metadata being obtained from server via ajax request. It gets about 20 values for display data and also about 10 fields for user input. Thus, the presentation view model and post view model are different. Filled fields are posted back via ajax as well.
How do i apply Knockout view models concept correctly?
1. I make a single viewmodel for displaying and posting data. In this case AJAX call will post back a lot of redundant data to server. Option: i can send a new object that will contain only input fields, but it doesnt look OK in KO concept.
2. I make a single viewmodel containing only fields for user input. Read-only fields to display stay out of KO view model and populated using common jQuery methods (so we're out of pure KO style again)
3. Or?
I appreciate your ideas.
Knockout provides the ability to apply MVVM pattern to a client-side (HTML5/Javascript) app. Your JavaScript view model should provide all the data and properties necessary to operate the view or views that it is responsible for, both for user input fields and display-only fields.
Once you post something back to the server, you're leaving the MVVM world and reaching into another layer to perform some operation. As a result, I think it's best to formulate JSON that contains only the data that the server needs to complete the request. On the server side, you may have a C# model with validation attributes or whatever, but, again - you're not trying to adhere to MVVM pattern there.
Hopefully this helps. I'm happy to elaborate if needed.
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.
I was thinking of writing some UIViewControllers to display the data in my Core Data stores while developing and testing an app.
I was thinking of something like this: A view controller that allows the user to select parameters to be passed into a fetch request, then a table view controller to list the fetch results, and finally a view controller to display the data in a particular entry from the fetch results.
Does anyone know of some open source code already similar to this, or a different approach I should take for monitoring my data?
NOTE: To clarify, I'm talking about a generic solution that could be put into any app using CoreData with minimal configuration.
Not a direct answer to your question but there is a new app in the mac app store which allows you to view and manipulate Core Data Stores. While it doesn't integrate in with your own app (and its not the cheapest software out there) you might find it helpful. I stumbled across it a few moments ago and thought of your question here.
http://itunes.apple.com/us/app/core-data-editor/id403025957?mt=12
I'm an absolute beginner with ASP.NET MVC and I'm trying to build a pretty simple application, but I'm having a hard time getting out of the webforms thinking.
I need to register users so they can download my application. I need to capture their information in three screens. Rather than write the database from each view, I want to aggregate all of the data they enter and let them confirm it before they submit their information.
I've been playing with various models and such but if I make one big model, the scaffolding wants to put all the fields on one view.
Can anyone point me in the right direction?
Sounds like you need a Wizard. Here's a few samples:
http://highoncoding.com/Articles/647_Creating_Wizard_Using_ASP_NET_MVC_Part_1.aspx & a youtube video
http://shouldersofgiants.co.uk/Blog/post/2009/09/18/A-RESTful-Wizard-Using-ASPNet-MVC-2e280a6-using-Data-Annotations.aspx
ASP.NET MVC is stateless, which means it doesn't save state between views like Webforms does.
You should save the information from each view into the database, and then set a flag in the user's database record at the end, indicating that the user confirmed their information.
If you need three separate views, you can always copy parts of the code created by the scaffolding to each of the three new views, using only those fields you want the user to see in each view.
If you need validation in each view, use a ViewModel object for each view that pertains only to those fields in the associated view.