I am looking for an overview of data synchronization techniques available on the iPhone platform. We need the ability to be able to sync a subset of content from a server to a local database residing on the iPhone.
On other projects I have worked on, the data synchronization was handled by the database. Is that available in SQLite? If not, any suggestions on techniques? Rolling our own would not be my first choice.
Thanks in advance.
Unfortunately I don't think there's currently a tool/feature that does this. A similar question was posted, which links to an article how someone rolled their own.
In essence, you could create a "pending" queue table that kept track of the record id's that needed to be updated. When the app needed to synch, as long as you had a way to identify the local record with the server record it could synch it that way. And of course the opposite way from the server down.
iPhone SQLite DB and Web-based DB synchronization and interaction recommendations
There is one framework that could help you if you are using Core Data.
You shall have a look at ZSync. An overview is available here:
http://ideveloper.tv/freevideo/details?index=17089146
If you are using SQLite I strongly suggest that you consider switching to Core Data. You will certainly gain some performances and the integration of undo/redo.
You'll have to remove a whole bunch of custom code anyway... :)
Related
I've got to the point in development where I need to set up a database migration tool. So far I've checked out some stackoverflow answers about the subject and it would seem like sails-db-migrate would be good to use, since db-migrate which it's based on seems to have ok docs, and it was recommended by one of the Balderdash guys.
My problem here is this: I have two databases related to my app, one where we store data like users, models related to our devices etc, and one where we store data collected by these devices, like movement data or power on times. I've been able to set it up in Sails pretty easily in connections.js, but I found no mention of using multiple DBs in sails-db-migrate nor db-migrate docs.
Does anyone have experience in how to deal with this situation?
I am creating an iPhone application I need
tableview with rows and column
and fetch the rows and column data from mysql database
Please help me out. Thanks
First of all if you target iOS 6 or later then you should use UICollectionView for this purpose. It looks like a simple grid and much easier to manage than UITableView with 'rows and columns'.
Answering your second question then you might look into Core Data, simplifying definition - its entity based database engine built on SQL(in most cases).
There is complete tutorial how to combine em.
Hope it helps.
As standard iOS doesn't support tables with columns although (as #Mehdzor says) UICollectionView sort of does this.
To be honest if you can't make UITableView fit your needs then you are probably going to have to either design your own table or use a third party framework. Apple have done this when they developed Numbers for iOS but you have to be careful when you are working with small screens.
For your second question CoreData is brilliant. I use it myself for several projects and it is really easy to use. It really comes into its own when you get to synchronising devices via iCloud (a really, really, really difficult thing to do from scratch).
The only downside to CoreData is that it is controlled entirely by the Apple framework. As such you cannot easily port your app onto other systems. Other alternatives are things like Parse, or (if cloud synchronisation isn't necessary) you can control your own databases using the sqlite3 library. Although sqlite3 for Apple is written in C, it's not bad to use once you get your head round it.
EDIT: If your mySQL database is on a server then you could just use web services to query your database and let the server side logic do the actual work.
I would like to know what I have to think about in order to download an SQL DB into core data? I am not sure what frameworks I would have to use or if there are any particular requirements when formatting the SQL DB.
Any help, suggestions, links to tutorials would be hugely appreciated.. I have done some searching around and its just hard to make sense of things because I am not sure if what I am looking for is even correct.
Im not sure if I understand what you are after, but maybe 2 links would be helpful:
an application that lets you load you data to a Sqlite DB from a lots of formats (Excel, xml, ...) is Navicat. It's an easy way of getting data to the DB. As David H mentioned, you could then work with the data without using Core Data via an Sqlite wrapper like FMDB. Then you can access the data with SQL commands.
A totally different tutorial is offered by nsscreencst.com: Importing into Core Data is a tutorial that shows how you can import JSON data to Core Data from a web API. This might be related to your use case. Unfortunately the videos there cost $9/month, but IMHO they are doing a terrific job.
(I'm not affiliated with either of the above companies)
This is just not possible - even though Core Data can use SQLite for storage there is no import/export. You really have two options:
1) If you have one database you want to use Core Data with within an iOS app, then you can write a really simple Mac App that interacts with your SQL store, and essentially replicates it in Core Data using a Core Data Schema you create based on your SQL database. The advantage of this is that is simpler to test and develop using a mac app. The final Core Data repository can then be used by your iOS app (by including the Core Data Schema with it).
2) Do all the import in your iOS app. This may take longer to develop but you can then dynamically download the SQL database into the phone and use SQLite to read it.
To import your data you have to create NSManagedObjects objects from every single record in your SQLite database. Depending on the complexity of your database model this can be very tricky.
There is a good introduction by Marcus Zarra on how to create NSManagedObjects from JSON: https://stackoverflow.com/a/2363996/480069. This should give you an idea on how to start. As Marcus said be aware of the relationships in your object graph so you don't end up in a loop when having complex relationships.
There are also a lot of good tutorials out there how to serialize NSManagedObjects, so just give Google a try: NSManagedObject serialize.
We have many systems that talk to each other and its become a bit of a mess. e.g system B gets data from system A and System A gets data from System C which also gets data from System B etc etc. The data is passed around using a variety of methods. Some of the data is copied across using sql periodically thus duplicating the data. Some of the data is pulled using views locally and remotely in real-time. We want to come up with a better solution. My plan is to create a central repository that the systems dump and get data from. Does this sound like a good idea? Whats the best practice for handling data between remote systems?
Thanks in advance.
You mean like a data warehouse? This is pretty standard as long as you don't want to update the data, and just want to use it for reporting/driving other applications.
You have a variety of options for getting the data in there including linked servers, SSIS packages and replication (if between oracle servers or ms sql servers)
You can read Microsoft recomendation: http://technet.microsoft.com/en-us/library/dd459147(SQL.100).aspx
As Martin Booth and Dalex say, if the data is used only for reporting, a datawarehouse is the obvious solution.
If you use the data in transactional systems, there are some other options.
If your system is primarily about data, I'd consider using ETL tools (http://en.wikipedia.org/wiki/Extract,_transform,_load) to manage the copying around of data.
If your system is not just about data, you should look at a service-oriented architecture; this is a brilliantly vague term, and can result in many billable consulting hours, so it's worth doing your homework. In general, the idea is to decouple the underlying implementation (views, replication, dump/restore etc.) from the conceptual "services". This might be too big a jump from where you are now - but the principles are useful when design your solution.
What am I trying to do?
A UI process that reads data from a Core Data store on disk. It wouldn't need to edit the data, just read and display the data.
A command line process that writes to the same data store as accessed by the UI.
Why?
So that the command line process can be running all the time but the user can quit the UI process and forget about the app until they need to look at the data it's captured.
What would be the simplest and most reliable way of achieving this?
What Have I Tried?
I've read up on sharing a data store between threads and implemented this once before, but I can't find anything in the docs or on the web indicating how to share a store between processes.
Is it as simple as pointing both processes at the same data store file? I've experimented with this briefly. It appeared to work OK, but I'm worried I might run into problems with locking etc when it's really put under stress.
Finally
I'd really appreciate someone giving me pointers on what direction to go with this. Thanks.
This might be one of those situations in which you'll simply have to Try It And See™.
Insofar as I can remember, SQLite (which is the data store you'll most likely want to be using) has built in mechanisms for file locking and so on; so the integrity of the file is likely to be assured. If, on the other hand, you use the CoreData/XML approach, you might run into problems.
In other words; use the SQLite backing for your file, and you should likely be fine.
You can do exactly what you want, you probably want to use the SQLite store otherwise saving and committing every time you want to synch out data will be horrifically slow. You just need to use some sort of IPC doorbell between the apps so that you can inform one app it needs to recheck the persistent store on disk and merge in its data.
Apple documents using multiple persistent store corindators as a valid option in Multi-Threading with Core Data (in "General Guidelines", open 2). That happens to be discussing completely parallel CD stacks in the same process, but it is valid if they are in completely separate address spaces as well.
Nearly two years on, and I've just found a much better way of doing this.
The answer seems to lie with Sync Services. I didn't even realise it existed! There's an excellent post about this at:
http://www.timisted.net/blog/archive/core-data-and-sync-services/
I've not tried this with my app yet, but it seems like an excellent way of sharing a core data store between two processes or applications.
If I experience any performance issues, I'll update this answer accordingly, but this seems like the Apple recommended way of doing it.
You need to re-think your architecture. If you want a daemon to own the data store, then have your GUI app connect to the daemon. Trying to share the data store is a can of worms you don't want to open.