I have a Core Data-based app that keeps records of purchase receipts, and I'd like to know if I can send one specific record (i.e., one row from the SQLite table) from one phone to another via email or whatever. I'd like to have a button that says "send a copy of this receipt to so-and-so" that would email the record that could then be imported. These are very small records that have less than 20 rows.
I know that this has been asked before (Core Data Store Sharing between iPhone Apps), but I'm wondering if anyone who has actually implemented this could share an approach.
Thanks!
If the length of the record you wish to send is no more than 95 Kb, then you may take advantage of GameKit and export/import it using a P2P connection. I do this in one of my apps using Bluetooth as the underlying connection. Otherwise, large records may be handled by a bonjour client/server implementation. Again, this is commonly done when synchronizing data with a desktop application.
In this case, by far the easiest approach is to write a serialization/deserialization method for your entity. I would suggest using a plist with an application-specific extension. You can then load the plist in your recipient and deserialize into the client's managed object context.
Related
Can people give me examples of why they would use coreData in an application?
I ask this because most apps are just clients to a central server where an API of some sort gives you the information you need.
In my case I'm writing a timesheet application for a web app which has an API and I'm debating if there is any value in replicating the data structure on my server in core data(Sqlite)
e.g
Project has many timesheets
employee has many timesheets
It seems to me that I can just connect to the API on every call for lists of projects or existing timesheets for example.
I realize for some kind of offline mode you could store locally in core data but this creates way more problems because you now have a big problem with syncing that data back to the web server when you get connection again.. e.g. the project selected for a timesheet no longer exists.
Can any experienced developer shed some light on there experiences on when core data is best practice approach?
EDIT
I realise of course there is value in storing local persistance but the key value of user defaults seems to cover most applications I can think of.
You shouldn't think of CoreData simply as an SQLite database. It's not JUST an SQLite database. Sure, SQLite is an option, but there are other options as well, such as in-memory and, as of iOS5, a whole slew of custom data stores. The biggest benefit with CoreData is persistence, obviously. But even if you are using an in-memory data store, you get the benefits of a very well structured object graph, and all of the heavy lifting with regards to pulling information out of or putting information into the data store is handled by CoreData for you, without you necessarily needing to concern yourself with what is backing that data store. Sure, today you don't care too much about persistence, so you could use an in-memory data store. What happens if tomorrow, or in a month, or a year, you decide to add a feature that would really benefit from persistence? With CoreData, you simply change or add a persistent data store, and all of your methods to get information out or in remain unchanged. The overhead for that sort of addition is minimal in comparison to if you were trying to access SQLite or some other data store directly. IMHO, that's the biggest benefit: abstraction. And, in essence, abstraction is one of the most powerful things behind OOP. Granted, building the Data Model just for in-memory storage could be overkill for your app, depending on how involved the app is. But, just as a side note, you may want to consider what is faster: Requesting information from your web service every time you want to perform some action, or requesting the information once, storing it in memory, and acting on that stored value for the remainder of the session. An in-memory data store wouldn't persistent beyond that particular session.
Additionally, with CoreData you get a lot of other great features like saving, fetching, and undo-redo.
There are basically two kinds of apps. Those that provide you with local functionality (games, professional applications, navigation systems...) and those that grant access to a remote service.
Your app seems to be in the second category. If you access remote services, your users will want to access new or real-time data (you don't want to read 2 week old Facebook posts) but in some cases, local caching makes sense (e.g. reading your mails when you're on the train with unstable network).
I assume that the value of accessing cached entries when not connected to a network is pretty low for your customers (internal or external) compared to the importance of accessing real-time-data. So local storage might be not necessary at all.
If you don't have hundreds of entries in your timetable, "normal" serialization (NSCoding-protocol) might be enough. If you only access some "dashboard-data", you will be able to get along with simple request/response-caching (NSURLCache can do a lot of things...).
Core Data does make more sense if you have complex data structures which should be synchronized with a server. This adds a lot of synchronization logic to your project as well as complexity from Core Data integration (concurrency, thread-safety, in-app-conflicts...).
If you want to create a "client"-app with a server driven user experience, local storage is not necessary at all so my suggestion is: Keep it as simple as possible unless there is a real need for offline storage.
It's ideal for if you want to store data locally on the phone.
Seriously though, if you can't see a need for it for your timesheet app, then don't worry about it and don't use it.
Solving the sync problems that you would have with an "offline" mode would be detailed in your design of your app. For example - don't allow projects to be deleted. Why would you? Wouldn't you want to go back in time and look at previous data for particular projects? Instead just have a marker on the project to show it as inactive and a date/time that it was made inactive. If the data that is being synced from the device is for that project and is before the date/time that it was marked as inactive, then it's fine to sync. Otherwise display a message and the user will have to sort it.
It depends purely on your application's design whether you need to store some data locally or not, if it is a real problem or a thin GUI client around your web service. Apart from "offline" mode the other reason to cache server data on client side might be to take traffic load from your server. Just think what does it mean for your server to send every time the whole timesheet data to the client, or just the changes. Yes, it means more implementation on both side, but in some cases it has serious advantages.
EDIT: example added
You have 1000 records per user in your timesheet application and one record is cca 1 kbyte. In this case every time a user starts your application, it has to fetch ~1Mbyte data from your server. If you cache the data locally, the server can tell you that let's say two records were updated since your last update, so you'll have to download only 2 kbyte. Now you should scale up this for several tens of thousands of user and you will immediately notice the difference of the server bandwidth and CPU usage.
In our iPhone app , we offer email templates populated with DB. also user can create their own templates.
Say for example , i have my own templates created over 500 entries to use
here i need to know the possibility on the below things since my client asks me.
If i want to to send my templates stored into my DB to myfriend who uses the same application.( So my friend does not have to create the templets on his own , he can use mine)
Can that user be able to load those template details ( DB information ) into his app? (like posting the db contents to server and the same content can be loaded into his app using link)
I think it cant be done but i would like to know opinions and views to convey this to my superior.
Thanks a lot
This could help: How do I associate file types with an iPhone application?
Okay, well.. It's possible to do what you are trying to do.
You would need to
Serialize the data that's stored in the DB
Figure out a way to send this data to the server/as an attachment in an email over to your friend.
So from that point of view,
Doing the first is pretty simple. If its all just string content, you can serialize it into an XML/JSON. There are a lot of ways out there that converts objects into strings or bytes to send them over the network anywhere you please.
The second needs support from the server. You would need a server that can identify the applications from one another. ie. yours from that of your friend's. It should then be made to handle the serialized content you are planning to send over and then figure out a way to send it to the friend. maybe a push notification? You could possibly look at Urban Airship or some such offering for doing this incase you dont have an existing server.
Or, you can cut yourself all the work and see if your workflow can fit into this
http://www.raywenderlich.com/1980/how-to-import-and-export-app-data-via-email-in-your-ios-app
I am sorry for asking such a noob question. I know that one way of storing data on the iphone via database is using SQLite, but after reading for a while it seems that the database is local and therefore each application has a copy of the database? is this right? if that is the case then what if I have two ipod with the same apps. and ipod A wants to update the database, then the data isn't reflected on ipod B?? Sorry for the noob questions
You overcome this by having a server which can synchronise the data between the apps. This is actually a much bigger problem than you might first think. In sonatribe.com we're having to consider situations where users aren't connected to the internet - so we queue the users actions and then push the data to the server when the device is connected. You then have to consider which database is the priority? Which one over writes the other when there are conflicts.
We also release new data for new events regularly - this data is then synchronised when the app is fired up.
One of the lessons we learned was that it's better to keep the number of calls down - connecting is expensive - but once connected the flow of data is fast.
FWIW - we went with MonoTouch - and the main reason was for the integration with WCF and the data capabilities (LINQ) of .NET. Using the SIlverlight profile and svcutil it's easy to get connected and communicate with web services passing complex objects over the wire - very handy for this sort of thing.
You also need to consider users who are on a limited data contract. We have the ability to turn off auto synch with the server in the settings. This is also useful for when our users are actually at the music festivals - in the UK, reception is renowned for being bad at events like this due to the sheer volume of people in one space. Although this is improving, users will appreciate the fact that they can stop the app communicating with a server on their behalf.
I want to develop a CRM iphone app. I think there are 2 methods to deal with the data store, one is using the Sqlite(but it can not share datas with others ?), the other method is using the webservice(let the app CURD data by one web application), I want to know which is better?
I think the question is not about having one or the other, you could have both: Webservices to expose a central server somewhere where common data is stored and your local SQLite database where a copy of this data is stored. This allows you for fast search etc. instead of contacting some remote server that may or may not be on-line.
If you want to share your data then you have to store your data in webdatabase otherwise store in sqlite
you can store your data in sqlite for fast access and when you want to share that time you can send it to webservice and retrive when you need to see more data
Okay, I want to have an app that takes phone numbers from an online database and displays them in a table view. When the user is not online, I want them to still be able to see the numbers they already got from the database in the table view. If the user manages to go back online, the database updates the view. My question is, is this possible to do and if so, what's the best way to approach it? (bit of a newbie, please help me out)
There are many ways to do what you are asking, depending on the complexity of what you are after.
Could I suggest the following steps (I'm not sure which ones you can do, and which ones you are having trouble with).
Connect to the server and retrieve the list of phone numbers
If the database has a web server front end this might be as simple as sending a get request to the server (see NSURLConnection) and parsing the result. Otherwise you will need to know/tell us what type database you are using.
Store the phone numbers on the device
Use SQLite to store the numbers on the device (See iPhone SQLite Resources)
Check for internet connectivity
Periodically check for internet connectivity, and if a specific time has elapsed since you last polled the server, retry. (See Checking iPhone internet connectivity)
Although you’re probably looking for a native app solution, you can also do this with a web app.
http://diveintohtml5.ep.io/offline.html
I am a new developer iPhone developer, "learning" to be precise. I came across the useful NSUserDefaults (a dictionary in which you can store/restore state even after your application relaunches). Problem with this dictionary will be memory in your case. NSUserDefaults is sort of global to all applications and yours may spoil the show for other innocent applications (like Weather :D ).
To work around this, you can have your application declare a property list file where you store a few numbers (best practise would be the most recent but you can use any selector of choice). Look for an appropriate time in your run loop to store these numbers into your property file and load them when the application starts.