There's a REST service that I use to populate info in my database, that is later used by my app.
I've read several threads on the matter, and now have to decide how I want the sync between the REST service and my DB to work.
Think of an app that gets info from google finance APIs about stocks and stores it in a DB, displays the information when the app is launched, and sends notifications when specific events happen in the stock price.
I already implemented the simple option of AsyncTask that is launched when a user manually requests a sync. Now I have to implement the auto-sync and these are the options I found:
Create a Service that will do the syncing
Use a Sync Adapter / Sync Provider
So I found a lot of advantages to the second option, particularly those explained in this video, but also two major disadvantages:
I couldn't find good documentation for android sync (a few third party articles such as these, but no official Google or Android Developers guide)
According to this article messing up in a Sync Adapter can cause major issues such as OS crash and reboot.
Most of the info I found is pretty old, so maybe things have changed since, but my App is supposed to work with API level 8 and above, so I would be very thankful for any recommendations and links to valuable documentation.
Definitely go with SyncAdapter. Follow instructions here: Why does ContentResolver.requestSync not trigger a sync?.
To do SyncAdapter, you'll also need to make an Account/AccountAuthenticator as well, so your SyncAdapter knows how to login to your service -- Unless it truly is the Google Finance APIs, in which case all you need to do is apply the right permissions in the manifest so that it will use the account settings already on the phone.
You didn't link the article you mentioned that discussed crashes, but I know it, and it's actually talking about Accounts -- Which yes, you do need to be careful with.
Checkout https://github.com/sschendel/SyncManagerAndroid-DemoGoogleTasks.
Demonstrates setting up sync of Google Task API data to local SQLite db.
Related
I was searching for a way to sync contacts to my application server and I stumbled across SyncAdapter. I'm new to the concept, so here's my question:-
How does WhatsApp/Facebook/Hike applications create account in Settings>Account section of the android device? Is this related to the SyncAdapter? If yes please provide appropriate explanation or some link to the same as to how should I implement this.
Ultimately, I want to sync my contacts to the application server on user registration, and also update the database whenever user adds/updates the contacts on the device. I'm stuck on this for a long time now so any help would be highly appreciated! Thanks
There's an older blog post that demonstrates the account and sync aspects. Even though it is old the content is still relevant to what you need.
http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-1/
https://github.com/c99koder/AndroidSyncProviderDemo
Get the contact sync project from here.This code works fine.
If you want more details refer follow the links,
1.http://udinic.wordpress.com/2013/07/24/write-your-own-android-sync-adapter/
2.http://developer.android.com/training/sync-adapters/creating-sync-adapter.html
If you want to sync periodically, then use background services using Timer.
Firstly: This will be implemented for Android using Google App Engine & Google Cloud SQL/Datastore but it's more the over arching strategy that I'm a bit confused about.
I'm creating an Android app that will record an activity. I'd then like to be able to sync this activity to the cloud and have the activities viewable/editable on any other devices registered to the user. The specifics of authentication, device registration and all that I can work out, it's more so the sync strategy that I'm having trouble with.
Requirements will be:
Activity is recorded on a users device
Activity is stored in cloud after being recorded
Devices should check the cloud for an updated list of activities and maintain a local 'cache' of activities (will be a SQLite database) to display to the user.
These are my initial thoughts on how I'll implement this:
Scenario: Recording activity
Record Activity on Device
Once Recorded upload data to cloud
Force sync with cloud to update local cache
Show user locally cached activities (which will include the recently added one because of the previous sync step).
Scenario: Updating activity
User selects cached activity
Makes changes
Uploads change to cloud (and marks it as modified somehow? not sure how this will work)
Force sync with cloud to update local cache
Show user locally cached activities (which will include updated content of the activity because of the previous sync step).
Problem: Sync local cache with cloud data
I'm not exactly sure how to implement the sync (i.e. steps 3 & 4 of the previous scenarios respectively). I don't want to discard the local cache and re-download everything to ensure the latest data as that seems terribly in-efficient. Preferably I'd like to just download activities that aren't in the cache and update activities that are in the cache but have been changed since the last sync.
Are there any best practices / well known sync patterns (that are easyish to understand) that will help me achieve this?
Kind regards.
You will also need to consider connection loss/retries, battery/power efficiency, and possibly apply custom sync algorithms.
Android already has an excellent pattern/API to address these issues and handle background sync with your back-end server in an efficient way.
Follow the official android guide for sync adapter API pattern , you do not have to implement content provider or authenticator if you do not need them, just implement stubs for them.
Here are couple of example projects to help you through...
Basic example, available at above link called BasicSyncAdapter
Look at Google iosched app for more advanced usage, and best practices including the usage of GCM for triggering your sync, among others.
Is it possible that I store my SQLite table over a dropbox account and have all my users sync their tables with the stored table? Also be able to make changes to that table?
Your approach could work in theory, but there are so many issues involved, that you're better off not doing it. If you wish to store and make data available across all devices belonging to a user, I strongly recommend looking into Datastore API by Dropbox. The API will take care of storing data locally as well as synchronize it over connected Dropbox accounts.
If you want a bit modular approach, you can use Windows Azure Mobile Services. These give you REST APIs to store your data in cloud. However, synchronization has to be handled by the developer - you. I have written a small library to do that here: http://bit.ly/ProjectMirror It's for Windows Phone, but Android version is already in a sister repo there. You could extend it. Let us know how that goes.
In addition to these services, Parse SDK is a good option. It requires you to pay after a while, though. In addition to what you want to do, it also provides other things like user management and so on. But, be aware that some of those operations may require you a live Internet connection.
So, in essence, if you want seamless data storage and sync, use Datastore. Be aware that you'll have no control over the server side. Also, your data will be restricted to the Dropbox ecosystem forever. If you plan on further expanding your app to other platforms, go with Azure and handle the sync. If you want lots of features, go with the Parse.
I would suggest looking into Google Play Game Services using the Cloud Save feature. Even if you are not building a game this feature lets you sync sqlite data in the cloud and Google will handle most of the work for you.
OR you could use a cloud based database which supports both push and pull. That means:
Scenario 1:
Your users change something on their phones. Changes are uploaded to the database. The database then pushes these changes to all other users.
Scenario 2:
Your users change something and upload this to the database. But instead of the cloud based server pushing the changes to all users, the users phones can ask the database for new data at intervals.
All this is very easy to set up. It took me about five, ten minutes. Just follow this easy tutorial:
https://parse.com/docs/android_guide
and for push:
https://parse.com/tutorials/android-push-notifications
We now use this for our company app, storing statistics for example.
Bear in mind that syncing can become complex. Try to keep it very simple, especially if you are new at programming.
I am planing to implement an app and I have come to a point where I don't know what is the best approach.
Scenario:
I have an app where I am making a todo list and I am adding 3 items. I use my phone for this.
Then I take my tablet and want to continue adding another task. Then after a while I take my wife's phone and want to add 2 new tasks.
Basically I want to have a very simple way of storing the tasks online and be able to sync it with the app.
I am seeing two possible ways:
have a web server with a database + web service calls. This has the disadvantage of having a host paid, learn some extra mysql + web service techniques.
store somehow the data on cloud and allow the app by login to access an account which stores the file. I am thinking here at something like Google Drive / Dropbox. But I don't know how I would be able to sync only the updated values, not the whole file. Because I am thinking, if I store all the tasks into one file, each time I update the file, I'll need to upload it fully, which is not the best approach.
I am open to any advices. What approach would you recommend ?
There's also Google Drive's "Application Data" folder.
https://developers.google.com/drive/android/appfolder
This has the advantage of using the user's storage space.
I would look into either Google App Engine or Amazon Web Services. They both give you free allotment of usage per month and if you go over then you start paying, chances are you wont get past the free tier for a while.
AWS is a bit more mature than GAE currently and seemed to be a bit easier to implement that GAE was when I was researching them
Take a look at the new training class for sync adapters:
http://developer.android.com/training/sync-adapters/index.html for the basics of sending data from your device to a server.
On the Android device, I suggest you store your tasks in a content provider. This helps you keep track of updates since the last time you synced. You can then query the provider during your sync, send only the data that's been updated, and store the data on the server.
You should probably store the last update time on the device, so you can tell if the server contains data that isn't yet on the device. Remember that you'll have to download tasks as well if you want all devices to be in sync.
You can try Google's Firebase. Firebase provides SDK for Android and iOS devices. And also, firebase supports offline and syncing. Firebase also provides object storage service. It easier to create firebase app than you think. Have look at this firebase's firestore service.
You can take a look at our Rethync framework (freeware with source) . Using it you can simplify the task of detecting modifications and sync only updated data. Next, Rethync provides both client- and server-side API so you can create your own service (and host it on the web side) or you can write your own transport for the cloud service of your choice (we will provide some transports in future, they are under development now).
I'm considering using the Parse cloud data service for my iOS/Android mobile app.
From what I can see from the documentation, my app would be highly coupled to the Parse SDK, which in turn uses the Parse REST API (I assume).
What measures can be taken to redirect the app to another service if Parse is down or if I no longer want to use Parse?
Ideally I would like to be tell the Parse SDK to use my own domain and redirect it to the Parse servers (how?). If Parse fails, I can change my DNS to somewhere else and attempt to replicate the Parse REST API (how?). Is this possible now? Is there a better way of preparing for this scenario?
parse.com seems to be down right now and I was just searching randomly online and found this post. Given I can't work on my project now due to the outage, I will put in my 2 cents for this topic.
First of all, I am definitely not happy if my underlying service provider goes down, no matter that's parse.com, AWS, rackspace or something else. However, that's exactly the trade off we signed up for and in return we enjoyed the ease of development and shorten our development cycle from 1 year to something like a couple of months.
It's dangerous for early stage startups to spend too much time and energy focusing on issues that are not the most important at the given point of time. Personally, I will not worry about parse.com being down as long as I cannot afford the time and resources to build and maintain my own database cluster. Obviously, it's under the assumption that parse.com will still be up for most of the time, something like 99.9% :)
The Parse support and sales team got in touch with me about this. Unfortunately they opted not to have a public discussion so I will paraphrase what they told me.
It is not currently possible to change the server url of the SDK. They're not sure if this is a feature they want or not. (It should be noted that the server url is exposed in the JavaScript SDK and can be easily changed; search for api.parse.com.)
Using Cloud Code, you can build your own server API on top of Parse. The Parse SDK has a PFCloud that can be used to talk with Cloud Code but I couldn't find any usage examples in the documentation yet. This is similar to what toadzki's answer, but should be much simpler to implement.
They also offer custom server installations of Parse.
To take the opposite view...
How big is your app and company? If you're a lone ranger or a small outfit working on a smallish to medium app, the answer most likely is "Don't bother". Yes, in theory you could set up a system so that your app (or some infrastructure somewhere) redirects to a different cloud service, but the time and effort taken to do this, and do it well, is significant. Consider that even if you think you've implemented such a system, you're then going to have to test that it works. Not really a simple task.
Mirroring the Parse API and then forwarding sounds simple, but the devil is in the detail. Especially for something like this.
Also, adding your own forwarding server is going to add a point of failure that will almost certainly be the weakest link in the chain. In short, don't bother!
As an alternative solution to toadzky solution you could make an interface to all parse methods on the device so you easily could switch Parse sdk out with your own custom implementation. In short make wrappers for all parse calls.
That said parse is very reliable and a lot of the functionality also works in offline mode. Also you'll get error responses which you can handle in whatever way you see fit.
If you want to route requests through your own server, do it. Have your server run the Parse SDK, not the device. Make your requests through your own custom API and repackage the request and forward it to Parse. This way, if you decide to change cloud providers, your app can still work without an update.