I got an application that displays some items loaded from a webservice (e.g. Fruits). These items rarely change. You can also show availability of those items (e.g. for apples, 10kg is available at store A today, 20kg tomorrow, ...)
The user can bookmark some of those items on his phone. I need the user to be able to bookmark some of these items and to have his bookmarks synchronized between devices (I bookmark apples on my phone, I expect to see apples bookmarked in my tablet next time I open the app there).
More or less, I got around 40 items, no more. And each availability data would total to around 200 entries.
Which technique would you use to implement that?
My idea so far:
I build a sqlite database (with contentprovider) of fruits and availabilities
I synchronize this DB every 2/3 days (that is enough, no need to do it more often)
I use a BackupAgent to synchronize the whole DB file
Do you think a database is overkill? The application is expected to always be ran with network connectivity (else we don't allow it).
My other option would have been:
Load items and availability on application start
bookmarks are kept within SharedPreferences
I use a BackupAgent to synchronize only SharedPreferences
This seems less complicated, and more efficient on the sync part. However, I feel that is not really a clean way to do it and less future-proof.
Android's backup API is only useful to initialize a new device based on the backups created by another device. See the backup API docs. It is not the right infrastructure to keep 2 devices in sync.
I suggest you take a look at the Cloud Save features of the Google Play Game Services. It allows you to sync data on two devices. It is typically used by games but can also be used in other scenario's (like yours).
Related
I am creating an android app that can be used by common users and also admin.
Suppose, if admin adds a new place name, that name should be added to database and when common user uses the app, he should be able to see the place name that is added.
I used MySqlLite database. But the problem is that if the app is uninstalled all data is lost. So I want some persistent data storage in which all the places that are added by admin are saved permanently.
Regards,
Sindhu
With the data being needed across multiple devices, your only option is to create/use a backend API.
Parse would have been a good choice but since that is getting shut down soon then it wouldn't be wise to use that.
Take a look at these alternatives here
You could also write one yourself, but unless you have some experience in that sort of thing then it will take some time to learn.
I'm writing an android application that has a search feature that needs to autocomplete from a list of stores. This list will only have up to a few thousand stores in it.
My current methodology is to send a LIKE query to the database every few hundred ms after the user has stopped typing and to populate the autocomplete list with these results.
Would using this method be stressful to the database?
It has been suggested to me that this wouldn't work because making continuous calls would be poor for users with a slow connection and that I should load all the stores into memory and filter from there.
At my work I ran into a similar problem a few months back. The contents of a text box filled by the user were supposed to filter their available options to choose from in a list of strings. The list needed to be updated every time the user typed a key so database calls to fetch records that matched their text were being made several times a second.
This ended up being wayy to slow to update as someone was typing, and this was only with several thousand records and with a server that was being accessed on site.
If you want to update as quickly as someone can type, making that many database calls simply won't do. Users will get pretty antsy having to let their phone buffer to type in some text.
In Short: Make one databse call and load it up onto the phone, and run your filter algorithm from there.
Regularly syncing the list of stores from your back end to the user's device and implementing autocomplete locally is the best way to go.
The JobScheduler API provides a flexible way to set constraints on your background syncing processes.
I am creating one Google Fit compatible App. My objective is to store Google Fit data using HistoryApi, and provide kind of Back Up- Restore functionality to user. If user buys new Android devices then he/she should be able to BackUp(sync) old data using his/her account.
I need to use Custom Data Type, as Public Data Types doesn't meet my requirements.
Everything works perfect, I am able to insert data and read data using History Api.
But When I try to read data from Another Android device using same Google Account then data is not available to read there.
My problem seems similar to this Custom DataTypes not synching between devices
This statement from Google Fit Document is not clear to me.
Custom data types are not available to use in other apps. Only the app
that creates a custom fitness data type can use it
source : CustomDataType
Q-1) What does it really means ? If I have an app GoogleFitDemo installed on multiple Android devices, then is it possible to sync data between this same app between multiple Android devices ?
Q-2)Is it improper way to store and backup data using Google fit ?
Update:
Finally, I found that Custom Data Type can also be synced normally, same as other Public Data Types. I had the sync issue as mentioned by #Ifor. Sync functionality is still buggy. In some scenarios sync stops working, and sometimes synced data is inconsistent across multiple devices.
1). My understanding is that same app same account but different devices it should work. Having said that sync is notoriously slow (hours days...) and has been buggy so it may be hard to tell if you have it right or not.
2) There are better backup methods... But if the data fits in with the rest of the stuff Google Fit is about and is not too big then it's probably ok.
i'm looking for a way to sync items stored in a database among users
so anyone of those users changes anything from his phone , the change will be reflected in the database and SYNC with all users related to him in real time
what's the best way to achieve the real time sync ? push notification ? is Urban airship what i'm looking for ?
Syncing data well is often specific to your application and your data. It's beyond the scope of an SO question but here's some thoughts if you implement your own ...
Some of the interesting design points are:
Reliably getting a delta
Dealing with conflicts
How real time is real time?
For reliably getting a delta, be careful about relying on date time for distributed machines. This post discussed some of those challenges and some alternatives.
Can I Rely on the iOS Device Clock Being Correct?
Merging new entities is easy but if multiple folks are editing the same entity, you need to decide how to merge. For conflicts, you can in order of preference (1) auto merge - come up with an algorithm that automatically merges the content without user intervention and ideally with no data loss (2) rely on the user to merge with an interface and (3) a form of auto-merge: last write wins. There's also variations where you interleave the revisions - it's a form of last write wins but the revisions are maintained . You can also auto merge at a field level of an entity if that's appropriate. My post to the question above covers interleaving but it depends on what your data is.
How real is real time? When syncing occasionally connected devices, the devices will getting farther and farther out of date and it takes time to catch up. Consider batching sets of changes in the communication pattern to optimize but it will still not be real time. Embrace that in the design - does the user see data animate into there current views as data is synchronized?
Architecturally, you'll likely want to expose your data in the cloud through REST services or SOAP web services since it's cross platform. For multiple devices platforms, you'll likely end up porting the sync algorithm. The best you could hope for is using something like Sqlite so you can share your devices database schema code and sql statements.
I would start with Dan Grover's presentation, "Cross-Platform Data Synchronization": http://iphone2009.crowdvine.com/talk/presentation_file/5104/Grover_Syncing.pdf
I have an application that uses the SQLiteDatabase as its database, because each application has its own, custom database (well, custom values), for another app I am making, I want to hose a single SQLiteDatabase that every app will access, for example one app adds a row, while another then reads it at a later time.
Is there anyway to do this? Everything I've found has left me believing there is not, but there has to be.
Any ideas?
Update:
I'm not sure if you've quite understood what I'm trying to do, sorry. The apps accessing this db are all the "same" app, but from different phones, for example, the database could be used to store a user id and their favorite color, so another phone could search their user id, and get the color in db with that user id –
I'm sorry if I did not make that clear enough
Of course there is way to do it! There is always a way!
Anywho, what I think you are looking for is a remote server. These can be done in a few way depending on how much money you have.
(1)If you're broke like me all the time, then you can make an extra computer you have at home act as a server for your app. This can cause a few ( :) hehe few) security issues for your home though. Also you will have a lot of traffic on your home network.
(2)Another option it's to get a domain name and web host. Most of the web hosting services I have seen offer database support. So what you could do is hop on, create your database on the web host server then link your app to your server. The cost on that varies based on your needs.
Really though, is your app interfacing with mulitple people? I can't think of a reason you would want this feature on any other phone (device) than your (relative to us customers) device. I rarely hand my device over to others, and never unless it's locked.
SQLite is serverless. In a situation as described there are no guarantees that it will work properly. Your solution is to create a database server that will cater to multiply Android clients simultaneously.
For more information on SQLite see LinuxForu.com and/or SQLite.org