For example i have a screen with multiple textfields (name, surname, address, phone etc) and after button click need to collect that data and pass to registration module. What is the good way to collect that data?
You can use multiple options here like
SQLite: Its pretty old way of saving and fetching data as it has lots of things to do while using.
Core Data: This is the most used way if you have multiple fields like first name, last name, email, mobile, gender, state, city, etc
Singleton Class with required fields: If you want to use properties on multiple places and with less number of initialisation, then go for with approach.
NSUserDefaults: Basically this should be used if you are saving some flags and small properties like user ID or user name.
plist (Property List): It is a flexible and convenient format for storing application data.
So as per my knowledge you can prefer Core Data as you good amount of fields and core data is easy way. And you can use same core data model for multiple entities when you want to add some more tables and fields in it.
1). Best way is to use FMDB if you want to store registration detail from textfield.
Download FMDB from Github
2). If you want to store and get only few registration data at a time then you can use NSUserDefaults for store data temporary and as well as retrieved.
Related
I have a knockout application I am building that has multiple viewModels in one page.
I have been mocking data so far but I am now building the API that will run it.
My question is what do I do with complex viewModels with regards to the API.
For example I have a 'add company' page that has the following tabs:-
Company info (name, address, etc.)
People at company (multiple people)
Insurance Documentation (3 different types)
I currently have each of these as separate viewModels.
When I press save I am now confused what is the best way to do things.
If I send all 3 viewModels bundled together (add them to one master viewModel) then it becomes easy to ensure that IDs all line up but that doesn't seem very modular or a good idea and breaks the idea of being 'API Centric'.
However if I send each viewModel to a different API end-point how do I ensure that the ID's match-up correctly (people -> company) etc.
At the moment I am looking at two options:-
When press 'add new' create a blank company on the database and grab its ID -> use this to match everything up.
OR -
When I press save send the new company up first, then when response comes back as (hopefully) ok then upload the rest of the information to their respective end-points using the now correct ID.
Both seem messy so I am wondering what is the 'accepted' best way to do this??
Your second approach is how I would do it, pressing Save would send the Company model first. Then once you receive the 'OK' response with the Company id, in the callback you can add it to the other models and send them up.
Nothing messy about that, just standard asynchronous behaviour.
I currently have a view on the Queue entity, that includes a Category attribute for an Email, Phone Call, and Appointment:
The Category attribute in all entities is a lookup to the same Category Entity Type.
I want to be able to combine them all in a single column on the view:
The current only way I can think of, is to create a dummy Category Field on the Queue, and write a plugin to sync it with the category of the activity, or write a plugin on the retrieve multiple that hydrates the column. Are there any other possibilities? Also, the business is asking to do this in lots of different situations, so if there is a more "meta" way of handling it, that would be great to.
This is an IFD CRM if it matters.
If I have an online database containing data about people (name, age, country etc), and then I create a page that displays information of it, and save it as: mywebsite.com/api/get_person_information/person_id
This page would simply display a serialized array (php) with information of a table's row (which primary key value should be replaced in 'person_id'). Could that be considered an Web API?
A web API is anything that lets other people make an application reusing components of your application or your data. That would make exposing your data in a machine-readable way an API.
(You might want to use a more popular format to expose said data instead of PHP's variable dump syntax.)
So I'm using Core Data in an existing iPhone app, and I've set up two entities: Person and Item. The root view of my app's navigation (currently) shows a list of people, and you drill down from there to items. In short, the hierarchy looks like this:
Person -> Item
I want to add a new entity above Person in the hierarchy, called List:
List -> Person -> Item
Additionally, I want the user's first List to be created for them on startup, and for any People the user's already added to be assigned to that list.
I'm familiar with Core Data's lightweight migration & versioning feature, so I think I know how to add the new entity and relationship, but I'm not sure how to:
Create a List record on app start if they've never had the Lists feature before
Set all existing People records to belong to that new list.
One quick and dirty way would be to add some code to my app delegate's applicationDidFinishLaunching method that performs the migration by (1) checking to see if there are any Lists, (2) if not, creating the default one, (3) fetching all existing People from my data store, (4) setting each Person's list attribute to the newly created default list, and finally (5) saving those changes.
My question is: is there any faster or easier way to do all of that?
That's pretty much what you'd want to do. Use an NSFetchRequest to see if any Listss exist. If not, create one. Then do another request to get all the Persons. Here, instead of assigning the list property of each Person, I'd create an NSSet containing all your Persons and assign that to the List's people property. You did create an inverse property, right?
This is actually a pretty lightweight operation, all tolled, so I wouldn't worry too much about performance. Unless you've got hundreds or thousands of Person objects, your user will probably won't even notice.
Let's say we have "User" and a "Hotel" model classes. I'd use a User_Mapper and Hotel_Mapper to load/save/delete etc. I want to then have the user be able to mark their "favourite" hotels. In the database I have my user_favourite_hotels table which is a simple link table along with say a field for subscribing to hotel updates.
When listing out the user's favourite hotels, how would you expect this to work from an API point of view? A part of me thinks that this should be a "findFavouritesByUserId" method on the Hotel_Mapper, but other than saying it "feels" right - however a colleague suggests that the "favourites" is owned by the user and should therefore be on the User_Mapper.
Perhaps I should have a User_Hotel_Favourites_Mapper? I was thinking of incorporating the "favourites" data in to the User object so it's saved and loaded whenever the User object is. I'm not sure whether it'd be better to split it out in to it's own object and mapper however.
I'd appreciate any advice on how best to setup the API for the above and any pros/cons/experiences.
Thanks very much,
James.
This (admittedly retired) patterns&practices guide to designing data tier components suggests that you put the method in the mapper of the type of object that you're getting back from the call.
If you have methods that return a particular type of business entity, place these methods in the Data Access Logic Component for that type. For example, if you are retrieving all orders for a customer, implement that function in the Order Data Access Logic Component because your return value is of the type Order. Conversely, if you are retrieving all customers that have ordered a specific product, implement that function in the Customer Data Access Logic Component.
So, in your example, it would go in the Hotel Mapper as it is returning Hotels.
If you want to store favorite hotels for the user, you are using the UserMapper, which notices that domain object for User has changes favorites, and updates both tables for users and for user_favorite_hotels ( you just need the hotel IDs ).
When you are retrieving favorite hotels of some user, you use HotelMapper and set filter to be based on User, because you will be working with instances of Hotel.
Considering that this was asked more than 2 years ago, I'm not sure if an answer matters to you now. But here's what I think anyway.
If User could have multiple types of favourites (including Hotels), it may make sense to have a UserFavourites abstraction to cover all possible types of favourites. UserFavourites could expose a getItems() method to get the underlying Favourites.
This could be managed with the help of a manager class to return the appropriate Favourites object(FavouriteHotels for example) on which the getItems() method can be called.