I have following scenario:
Android application running on mobile device needs to have data syncing feature based on given set of interval specified by mobile application user.
I have designed a UI which will accept syncing frequency from user and persist in sqlite db. I was wondering what would be right approach for building syncing logic. Server exposes restfull webservice for getting delta changes in data. Syncing should happen even if application is in dormant( application is not active) Background syncing should be invoked on specified frequency.
Can i use make use service along alarm for implementing this?
Is there a better approach for implementing this?
Use the SyncAdapter class, a Service, AlarmManager, and every component that follows from using the SyncAdapter class.
Using a SyncAdapter allows the user to control the syncing from the same place he controls the accounts and the syncing of all his other apps: google apps, facebook, twitter, whatsapp, etc.
This is really the best way to do syncing. It's part of the standard UI the user is used to. And it's also the most energy efficient way you can do syncing.
Also, using a SyncAdapter doesn't preclude you from having the user set the frequency of the Syncs inside your app (as long as the primary way of turning on and off the syncing still goes through the "Accounts and Sync" main settings of the device itself).
Related
I'm new to app development and I am soon going to be developing an app for a local charity.
The charity is a dog rescue charity and the app will display information about dogs available for adoption.
The content will obviously need to be updated frequently, even daily, which will obviously not work constantly updating the app via the relevant app stores. What is the most common way to deliver content to an app?
My thoughts on previous experience would be to create a REST API and deliver the content remotely. Would an app allow this? Is there a method more generally used?
Thanks in advance.
You can save all the information to show of each dog available to adoption in a database, then make the app retrieve all the data from it every n time.
I recommend you to use Firebase, it is cross-platform (includes Android and iOS), and I consider it really good when starting using databases.
Here you can find documentation for every supported platform, and easy examples on how to work with it.
Good luck with your project! :)
I see you don't have clear specification on how often to update the app content and technical capability.
Use JobScheduler
Syncing to the backend (via REST API)to fetch the data is a battery drainer & there is no use in syncing data on device which is about to die, I would prefer Jobscheduler which will intelligently act as per various environment criteria met like charging/idle.
There are several facilities available to help your app schedule work. These include:
AlarmManager
JobScheduler
SyncAdapter
Caution: Exponential backoff is enabled on job dispactchers/schedulers
For 24-hour logic check here
I'm currently developing an mobile application and rest service. The mobile application executes lots of calls to the service even if no update is required and data didn't changed. In order to remove this overhead of rest calls I'm planning to implement GCM (Google Cloud Messaging).
My strategy would be the following:
Load all required data on application startup. When data change was recognized on server side a push notification will be sent via GCM to affected devices to make partial refreshes of data (via specific rest calls). Advantages of this would be less overhead at service side, because there are no unnecessary rest calls and a more fluid user experience in my opinion. Disadvantage is that the app is dependent on GCM Messages and that they arrive in time.
I'm unsure if this is the right strategy for this. Could someone maybe point me in the right direction and tell me if this is a good practice?
We could use more information before answering details...
I'm unsure if this is the right strategy for this. Could someone maybe point me in the right direction and tell me if this is a good practise?
I will consider for the sake of giving an overall answer that:
A - User is not always with the application "online", neither has network, not even a desire to have updated info at all times.
B - User is eletronicaly litterate enough to understand difficulties with the program.
With those in mind, then what would be a good approach is:
Poll relevant data, store them locally. At this stage, one would consider the relevant informations that user would have and store them, with a date flag.
Once a flag goes "old" (below your threshold), re-query that data.
Operations follow 2 directives... When observing a data, check its state, show the user if its recent or not, and if its not, poll it. If it is, if the user selects operations on it (POST mostly), re query the data.
This way, you have no static overhead, if users dont have the app on foreground. Also, should they use your "always online app", they understand that network is a necessity.
I am implementing a chat app in android. A vital part of this app is to sync with the server and local database. There are several methods to sync data between server and android device like AsyncTask, IntentService and SyncAdapter.
I prefer to use SyncAdapter, because it is more efficient and it handles most of the background tasks by itself.
When I read the developer page for SyncAdapter I found this,
Note: Sync adapters run asynchronously, so you should use them with the expectation that they transfer data regularly and efficiently, but not instantaneously. If you need to do real-time data transfer, you should do it in an AsyncTask or an IntentService.
Does that means is it not good to use like chat app?
Also I need to mention a feature of SyncAdapter
Automated execution
Allows you to automate data transfer based on a variety of criteria, including data changes, elapsed time, or time of day. In addition, the system adds transfers that are unable to run to a queue, and runs them when possible.
So if it starts to sync when data changes (Since the new messages are stored in the sqlite database), I think SyncAdapter will be a good choice for Chat App.
Any Suggestions are appreciated.
Thanks.
Usually mobile app depends on backend implementation and app requirements, but generally you shouldn't use such methods for chat application, they won't give you up to date data.
I'd say when app is in background, you should use GCM for new messages notifications and when app is in foreground use something like RPC, xmpp, sockets or whatever that keeps your connection alive.
I have an application that uses a webservice to get information and save the changes made by the user.
currently I have one service that runs while the application is open, and it has public methods for each operation. the trouble is that service is growing considerably and I'm thinking refactor, but the question is what is the best way?
I can think of the following options:
Deferred services the current service and that all are initialized at boot time application
Create small services and that these are initialized by local broadcast
although I have doubts about performance. Can give me some clue or example about which method is better, do not really care that changes are instantly synchronized, these are stored locally and can be synchronized when possible. Data sent are not many, so the synchronization is relatively fast
Synchronization processes are something like
Check if there is new data (I have several types of data, these are the ones that are growing)
Synchronize user preferences
Most likely there's no point of having Service running all the time. Instead, I'd go for IntentService. If possible, I'd also condifer using push notification (like GCM) so the server could let my app know that there's new data to fetch (or maybe even send it to me if you'd fit in the GCM payload limit).
This is more of a conceptual question not necessarily bound to any specific technologies.
Lets say you got some database on a server, some REST/JSON API to access content in that database and some mobile client displaying data retrieved through the API.
It would be nice to have some caching mechanism on the client and also to be able to enable offline access to the data as long as the client is only reading (In my case it's fine to deny write access to offline clients to avoid having to manage all those nasty conflicts that might happen).
It appears that a nice way to solve that would be to have a subset of the servers database model present on the client and synchronizing data from the server to the client.
Access to the local database might then immediately return results but also trigger update requests to the server. In case the server returns modified data the client model then synchronizes it's local database and notifies the display of data changes.
The goal in the end is of course is that the user may browse the information regardless of the stability of his internet connection and is not annoyed by connection dialogs or similar as long as he doesn't modify any data.
Now from an implementation perspective... on one hand it seems like a bad idea to couple the server database directly to the client database as they may be from different vendors. I guess at least there would need to be a vendor independent model above both database implementations. On the other hand, transforming the data from the server database into some transport format and than putting it back into the client database seems like a lot of overhead.
Any suggestions how to solve that in an elegant and maintainable way?
I am working on an app that syncs small portions of a large database locally onto the handset. There is an initial preload that has to occur on the handset but after that the updates happen asynchronously in the background.
First of all, decoupling the server and handset using JSON or XML is highly advised. Locking into one technology always causes issues as you are forced to use the same technology regardless of the platform. That is, if you plan on expanding into other platforms (Web,iOS,etc..) you are forced to use the format dictated by the server. Choosing a generic format will make that simpler in the long run. In reality with the amount of public libraries reading/writing JSON is a trivial matter.
There are two ways that we use to sync the data;
1. AlarmManager
We schedule the AlarmManager to trigger a service to wakeup on a regular schedule (lets say every 6 hours). The wakeup starts a background service that contacts the server, downloads the changes in JSON and updates a local SQLite DB. If there is no connection, the update is skipped and scheduled for the next wakeup. We add a ConnectivityChanged receiver to automatically restart the sync when the connection is restored.
2. GCM
It's a little more work but saves a lot of battery and data usage if you only update the local database when there are changes. Google Cloud Messaging can send a wakeup message to the device and tell it to start the sync service. The sync service runs the same as the AlarmManager method above.
We do a combination of both of the methods above depending on how "fresh" you need the data and how often it changes. Something like an RSS feed should probably be updated every 30min whereas weather data may not need to be updated more than every 4 hours.
So to run the database sync we use;
Receivers -> listen for system events and trigger Service
Services -> connect to the server, download the JSON and update the SQLite providers
Providers -> insert the records into the database and broadcast content changes to ContentObservers
ContentObservers -> when the app is running, the ContentObservers update the UI with the new data
There is a lot of technical details in each of the components above but that should provide you with a very robust architecture for syncing server data with a local db.
I'm working on a project that has similar requirements. We want to have a big, available database on a server somewhere and then mobile devices that get data from it. If the devices go offline it's ok because they have saved their own copies of the data locally.
We've decided to use BigCouch (fork of Apache CouchDb that supports clustering) as the server technology and then Couchbase Mobile on the mobile devices. (As a note TouchDB for Android will replace Couchbase Mobile, but it's not stable yet.)
The reason we went with Couch* technologies is that Couch has good replication over HTTP. You can programmatically initiate a sync event on the mobile device and it will replicate all inserts, updates and deletes for you. It stores the information on it's own embedded CouchDb on the mobile device, so it can be read offline.
If you didn't want to go down the Couch road, you could simply use something like SQLlite to store the results of your REST/API calls. Then you would have to write your own replication logic for when a mobile device goes offline and then comes back. There are creative ways to do this, so maybe it's an option.