I have an app I am building in iOS, version 5. This app is using a WebAPI built with C# which calls SQL Server stored procedures. The WebAPI uses RESTful calls made to populate items within my iOS app which are returned to my iOS after an authentication challenge in JSON format. All of this works well. As a best practice I am interested in the best approach to consuming and returning data back to the database. Right now I have some custom classes or entities that represent the data returned from my service, for example, I pull all product data based on some category or subcategory and populate an array of type Product. This Product class matches the exact structure of the data returned, i.e. ProductID, ProductDescription, etc. I know this can be duplicated with SQLite and CoreData. What I am wondering is this. Does it make sense to use CoreData, if so, what advantages will I see in using CoreData.
Also, a second part to this question. For arrays of items that rarely change, does it make sense to place those items in pLists? An example of this type of data might be something like Units of Measure where quart, cup, gallon, etc would be listed in a UITableView for the user to select from but it's not likely that the application will need these values updated often if ever.
I would recommend RestKit. From RestKit website:
RestKit can populate Core Data associations for you, allowing natural
property based traversal of your data model. It also provides a nice
API on top of the Core Data primitives that simplifies configuration
and querying use cases.
It seems to meet your requirements.
I would not go for SQLite. It may seem easier but using RestKit with Core Data will give you a lot more.
Related
In Sqlite we can create multiple schemas based on the users login or based on some other logic. How can we achieve similar concept in iOS app with CoreData framework.
My iOS App has multi user login. I want to have offline usage for what ever users using the app by logging in. Similar to schema in SQLite where data wont get added in same tables, I am looking for similar one in Core Data.
The most direct way to have per-user data is to remove all user data when someone logs out. NSPersistentStoreCoordinator has a method called destroyPersistentStore(at:ofType:options:) which is designed to do exactly that. It will remove all files associated with a specific persistent store. When using this method you'll need to be careful to not keep any in-memory references to anything that was fetched from that store, because they won't work anymore and will almost certainly crash the app if you try to use them.
On a related point, this does not mean having multiple schemas and deleting the schema, as you mention in a comment, doesn't make sense here. In Core Data, the data model serves a similar purpose to a relational database schema. It defines the classes and relationships that can exist in the model but it does not contain the actual data. This is the same idea as a database schema, which define the tables and so on that can exist in the database but which are not the same thing as the data.
I have done the following to try and answer this question:
I have scanned the Apple documentation on Core Data
I have done this very good tutorial: Core Data from Scratch
I have scanned other articles in an attempt to answer this question
Further detail on my question:
I have an existing iOS application. To achieve persistence, I am currently, by hand, marshaling and unmarshalling JSON files which I store in a directory on the phone. I would like to instead use Core Data in the same kind of way that you might use Hibernate or another ORM tool with my existing domain model.
Which is to say I would like to have something like:
MyDomainObjectDAO
save( myDomainObject )
load( id )
etc. etc.
Where the implementation of those methods involves handing an instance of myDomainObject to something like an ORM context which then stores the object. C'est possible?
I imagine that I could copy all the values from my existing object structure into managed objects created by the core data Apple tools, but I wanted to ask if there was a better way to do this. I would like to keep my convenience methods on my domain objects
If I understand your question correctly you are looking for RestKit. What you will do is create a relationship between your object model and your JSON. You will find that you can almost do it all on the fly without creating any NSObjects manually or parsing any JSON. All you have to do is create the CoreData scheme and create some mapping instances. RestKit will convert your incoming JSON to these objects before persisting them into CoreDate. RestKit is awesome though a bit slow!
I am developing an app with different types of users. I have clients and developers and I want to differentiate between them to have different functionality for each profile. I do not know what could I do to manage this.
I am using Core Data for the objects of the app. So, should I do two entities? Or only one called User? Each user has relationships with other entities but they do not have relationships between them.
Like this:
Developers(Desarrolladores), Clients(Clientes), Proyects(Proyectos), Offers(Ofertas)...
In my experience, it is best to keep the core data model as simple as possible when you are starting out with your Core Data design.
Utilize one entity for a 'User' which holds an attribute for which type of User it is. Then add on functionality for these two different types of users with a category. This way, if you change your mind about your design later, the functionality that you give to each will be preserved. Having done multiple adjustments to my data model, this is a must!
The rationale for this and an example of its implementation is provided by the Stanford iOS development course on iTunesU in Lecture 13. Good luck and happy coding.
I'm currently looking into client side model binding to HTML templates especially with angularjs. I was wondering what the best strategy is for retrieving clientside viewmodels from the server, e.g. a viewmodel containing not only the data for editing but also the data for select lists or drop down lists etc..
As I see it , one has several options
retrieve one viewmodel from the server using e.g. web api, containing ALL the data needed for the view model
render a client side viewmodel to javascript inside the server side html
retrieve data for the viewmodel using multiple web api calls, e.g one for the main data to be edited, and one for each additional data (select lists)
I didn't encounter many examples for option 1 as it seems that web api is used mostly for crud operations returning specific data for one type of object e.g. Person or Order
option 2 conforms to the practice of server side view models with asp.net mvc but I have not seen many examples using this technique in combination with angularjs
option 3 looks clean if one considers seperation of concerns, but has the disadvantage of multiple smaller ajax requests.
Could you share your thoughts and experiences ?
Personally, I use option #3. The app would make requests to "prepare the editor", such as populating dropdown lists, and requests to fetch the data you want to edit (or, if you are creating a new object, any default initial values). I think this separates concerns better than option #1, which ties together "model" data and "support" data.
But as you pointed out, this does make extra calls, and, if they are very numerous, can noticeably slow down the page. (or increase complexity; on a big form with lots of dependent fields, ordering may become important).
What I usually do is have the server provide a "combined" api (e.g. /editor/prepare-all) while also providing small pieces (e.g. /editor/prepare-dropdown-1, /editor/prepare-dropdown-2). When your editor loads, you use the combined one; if there are dependencies between fields, you can request only the data for the dependent fields (e.g. /editor/prepare-dropdown-2?dropdown1-value=123). I believe this has little impact on the server's complexity.
I would agree with st. never and have definitely used option #3 and I think combining $resource and Web API would be a perfect RAD combination. However, I've also worked on very complex screens where I've wanted sub-second response times so I've resorted to optimise the entire development 'column' - I develop using SQL Server as my backend database so I've used it's native support for XML to return structured XML from a stored procedure which I then serialise into a .Net Model (POCO) which I then pass to a Json serialiser for transfer to the browser. I might have some extra business processing to perform against the POCO but this still leads to a very simple code structure to transfer a fairly complex structure of data. Typically it's also very fast because I've made one call to the database and monitoring and optimising one stored procedure is very simple.
We run a series of reports every 6 months and store the results to tables that can be queried/viewed at any time in the future. Depending on the cycle either two or four tables will be added. They have a standard naming convention of yyyy_mmm_Table_x.
Our website is built using ASP.Net MVC2 and the database is modeled using EF4 using the standard model designer, not Code First.
I would like to be able to dynamically add the report tables to the EF4 context at runtime. I don't want to have to manually add them to the model using the designer, otherwise every reporting cycle we have to update and recompile the model just because we added the extra reports. That would be a maintenance headache when nothing else has changed.
I can get a list of the available tables simply by querying sysobjects. If I could get this list and add the tables to the context when the site started up then I could use something like the Dynamic LINQ library to query against them depending on which table the user selected from a dropdown.
I can't use EF4's Code First out of the box because that would force me to create concrete classes for the tables and that would just be the same maintenance headache. I suspect I could use the same strategies the Code First framework uses to dynamically update the context, but I haven't looked at this library at all and I'm hoping someone familiar with it can point me in the right direction.
Otherwise I think I would have to drop back to ADO.Net to handle this area. That may be the best and simple way so I guess I'm looking for comments. I'm not a zealot so I don't need everything to be in LINQ and EF4. :) But it would seem to be a little cleaner and consistent, especially if it allows me to make use of Dynamic LINQ. But sometimes the old way is just simpler.
So, if you have any suggestions or comments I would love to hear them.
Thanks!
Even with common EF you still need new data type for each table because when you map the table you need new ObjectSet of new entity type to be able to run queries. As I know it is not possible to map two tables to the same entity even if table structure is absolutely same.
All runtime mapping is stored in MetadataWorkspace prepared by EntityConnection. So if you want to play with it you can start there but public interfaces of these classes don't look promising.
I guess you want to run Linq-to-entities on these tables so using Stored procedure returning data from correct table based on data parameter is probably not an option.
You should use common ADO.NET for this.