If I have both a web interface and a iOS application, what techniques could I use to make sure the data is sychronized between the two?
I'm looking for something that isn't overly complicated, and might not be a solution that works 100% of the time, but something reasonable.
So the scenerio is, someone uses the web interface while their iphone app is open, and say ads some data. Say this is a grocery list application, and they added 'bananas' to a list.
Now the iphone is not in synch with the changes made on the web interface.
What should/could i do in this case?
Update
Data will be stored in mysql, and ideally some will be cached locally on the iphone.
What you are describing here is a classic synchronisation problem between a mobile device and web service.
On a high level, a classic solution would be to poll for data every x seconds on your mobile device to your web service to see if there are any updates (where you base 'x' on the level of synchronization you need taking into consideration that lower values put more strain on data transfer and thus require more battery power). In order to submit changes from the mobile device to your webservice, you could require that a data connection be available so that when data is entered, it is instantly submitted to your webservice or you could queue it so when a data connection is available, it batch sends the requests to the webservice and the webservice handles conflicting data based on timestamps or some other metric.
Related
I want to create a game with Firebase, and I wanted to run a function when the current user gets a friend request in the real-time database. The function, for example, will show the friend request under a friend request table. Is there any way, perhaps in the App Delegate or elsewhere, where I can check for a friend request (an update in the Firebase Database) for certain intervals when the app is open (no matter which View Controller is shown)?
Thanks!
The Firebase Realtime Database client use a (Web) Socket to keep a connection with the servers. This is very efficient, but keeping the radio chip active uses significant power. For this reason the OS will typically close such connections when the application isn't actively being used.
To reliably deliver messages when the application isn't actively being used, consider using Firebase Cloud Messaging, which (on iOS) uses APNS for delivering the messages. This is a more power efficient way of delivering messages, so is typically allowed more leniently by the operating system.
I'm new to IOS programming, and I have had a great time learning it. It took me about 4 months to really get a good grasp on it. I have began creating my own app, and I ran in to a few questions. The app I'm creating is a live app like instagram, foursquare, etc. How do I store all of the information I need. Can I use Core-Data to create a real-time app that can handle updates from multiple users?
The app I'm creating is a live app like instagram, foursquare, etc.
How do I store all of the information I need.
You'll probably create some sort of server to manage the data. Having a single, central source of data is a lot easier than trying to sync data between multiple devices.
Can I use Core-Data to create a real-time app that can handle updates from multiple users?
You can -- Core Data works on MacOS X as well as on iOS, so you could write a Mac program that is the server for your iOS app. Whether that's the best approach is another question... I suppose it depends on how well you already know Core Data, whether there are any advantages to using the same Core Data data model on both the server and the client, how many clients you think you might have to support at once, etc.
If you're asking about using Core Data on the iOS client, then yes, you can certainly do that.
I have an iPhone (iOS) app that keeps data in a local SQLite database on each device. The app is used to manage a virtual bank account for kids to track their allowance, spending, savings, etc. (KidsBank and KidsBank Free). I am getting a lot of requests from parents to provide a sync capability between parents and possibly even their children's iOS devices.
I have considered several options, but all are tedious and non-trivial since this basically requires database replication or a new architecture. Any transaction on any device ideally should appear (sync) to all devices in the family (as immediately as possible).
Ideally, I would like the sync to be automatic & hands off
Options include
(1) Use of iCloud
(2) Use a direct network connection between devices (wifi)
(3) Use of a server side database and web service (JSON/RESTFul)
(1) iCloud
PRO: iCloud provides distributed file sync
CON: iOS 5 required, SQLite database files can not be synced via iCloud, classic database replication (and non-trivial)
Using iCloud is a strong consideration. Devices can write a custom transaction log to an iCloud file where there is one file for each device identified by a unique device ID. Global unique ids (GIDs) and last change timestamps are added to each table. All participating devices will write a unique device ID to a separate file in iCloud. Upon app launch or upon log file change, the app running on a specific device will load all transactions but not those generated on their own device from the files via iCloud. The last participating device to load the transaction will remove the transaction from the file. If the device is not the last participating device, it simply signs off on the transaction and allows the file to sync via iCloud. There may be better algorithms, but the basic idea is the same - using iCloud to push around change logs.
(2) A direct wifi connection will allow two devices to manually sych.
PRO: Not as complicated to manage the sync process
CON: Users must both select to sync from their apps while connected on wifi
(3) Move the entire database or manage transactions on a server.
PRO: Sync is no longer required
CON: Typical issues for a web-driven app. Would need to rewrite the database service layer (currently in SQL) to use a remote web service. Cost of running a server (I would use AWS).
Can anyone offer some experience in syncing SQLite between multiple devices? I'm leaning in the direction of using iCloud to push around transaction logs. I'm trying to minimize cost and complexity.
Moving to iCloud is probably the best solution, as it is proven and made by Apple. You don't need to worry to much about the iOS 5 requirement, as according to most stats over 90% use it. iOS 5 is free to upgrade to. You could then rename your old version as Lite, and continue without syncing.
Syncing is probably one of the hardest things you do.
One solution I made is that all changes to a database leave a log, with timestamp, uniqueid and couple of other things to make sure the transaction is totally anonymous and totally unique. I have made an extremely simple web service that has two operations, you can add transaction to it, so I sync whenever the user is on wifi, so I push all changes, receive a result from the server, then delete the transaction records as they are synced.
The other action is to fetch the records, send the timestamp of last sync, userid and other.
All data is sent using JSON and received as such. It can easily handle tens of thousands of users, running on a small Amazon EC2 server.
This is pretty much how iCloud works, but I made this solution before iCloud. Now I am going to iCloud, but probably need to keep the server running for 1 more year or so, depends on usage.
Hope this helps you.
After finding time to get back to working on the app and also with time passing and Core Data iCloud replication maturing, I converted my app to Core Data (NSSQLiteStoreType) and monitor notifications such as persistentStoreDidImportUbiquitousContentChanges. Using lightweight migrations too. Working well.
I am in the process of building an iPhone app with a RoR 3 web service on the back end. The app is a fairly simple peer-to-peer game. I would really appreciate it if someone could share some pointers and tips on how to best divide the operations between the web service and locally on the iPhone.
For example, chess or backgammon, is the current state of the game being constantly saved and retrieved from the server? or is it stored locally on the iPhones of the players?
Thanks!
This will vary wildly depending on how you want to program the application and what your needs are. You could constantly save and retrieve game state from the server, you could synchronize game state at certain intervals determined by game play, or you could run mostly local. It all depends on your requirements. In general cell networks should be considered slow and unreliable (even though this isn't always true). Keeping data transfer to the minimum required to accomplish your goals makes your app feel more responsive and users happier (especially those in poor coverage areas and those who do not have unlimited data plans).
That depends on whether it's a game against another player or against a computer opponent. If it's against another player, then the state would be updated on and retrieved from the server. If it's against a built-in AI, there would be no reason to send that state to the server, unless your AI is inside your webservice instead of including it in the actual application. It's really a design decision based on what you're trying to accomplish. Generally I would recommend keeping as much as possible local to the app, unless there's a reason to do it on the server, but if there's any competitive aspect to your game, you definitely want to keep control of any calculations on your server. Keep in mind that someone can always try to decompile your application or call your webservices directly passing in false data.
I'm currently in the middle of developing an iPhone app with a big reference database (using Core Data backed with a pre-populated sqlite database). Once the app is live and deployed to a client's iPhone, I need the facility to update/insert a small amount of data. What are best practices / methods for doing this?
There may be occassions when the frequency of updates will be daily for a month or so. Other occassions when a data update happens once every few months.
What is the recommended way of doing this? Note, I don't anticipate any data model changes for these updates -- this is purely an insert/update of data.
At the moment I'm starting to research the use of push data notifications (q:payload size restrictions?), app store updates (q:code/data model only, not data updates?) and the use of my own ad hoc data server (which the app connects to routinely to check for updates).
Can anyone please provide me any pointers on the above?
Thanks in advance
IIRC Push Notifications have a maximum payload of 256 bytes. Enough for notification purposes, but not more. Your app would still have to download the actual data from your own server after receiving the notification.
Note that the app bundle is not writable on the device. So if your app needs to update the data store, you should copy the pre-populated database file from the app bundle to the app's documents directory on first launch.
App Store updates would certainly be feasible (especially now that Apple seems to have gotten its review process down to a few days at most) but note that an App Store update will always replace the entire app bundle (code and data), so if your pre-populated reference database is big, the customer would have to download it in full every time.