Synchronize local SQLite database with central database - android

We are developing an Android App based on a product that already has a website. As a result, when launching the Android app it may happen that a lot of things differ between the local SQLite database and our central database.
What is the fastest way to synchronize the Android App?
Compare the data in our central database with the SQLite database and update/insert/delete accordingly (for each table)?
Or just drop the concerning tables and create them again - and execute a transaction with compiled statements?
Sounds like the first option may be very slow.
Any help would be appreciated!

In your case needs value the situation!! When I have this problems the first questions are...
The tables that I want to do 'drop table' have few data? If it's yes the best way is the 'drop table' command. If it's no then you need to use the 'insert' and 'update' commands. I need to remark that it's possible that the SQLite database grows with time, then the good programmer would second way because it's more secure and you think with future possibilities.
My app syncs any time or syncs a few times a day? If the answer is in any time then you need use the 'insert' and 'update' commands. Because you can't delete database tables every minutes or seconds.
Tell me if I helped you and good programming!

Related

Data Synchronization between Mobile App and Cloud

Well, I'm building a app in both iOS and Android and both app needs to be syncronized with the cloud DB MySQL. Both the apps works offline so I need all the insert and update functionality. Delete is probably not going to be used but still I'd like to know.
Well, what I'm looking here is the solution or ideas or algo that's needs to done to achieve this.
I have kept CreatedOn and LastSync as timestamp column on each table.
Now the problem is should I always keep checking all the rows and all the columns everytime?
What I think is I should keep ModifiedOn column on all the tables and check that with LastSync for every device id. What do you guys suggest?
Maybe it's not the answer you are waiting for, but on the project I'm working on, we are using Azure Mobile Services. There is an Android and iOS SDK where they implemented synchronization between offline database and Azure (just like in Git you can call push and pull methods).
There are some limitations (TableStorage is a limited MSSQL storage), but you should check it out.
I know it's about two years overdue , but I've been doing the same thing (Android App that syncs with web api and postgresql)
What I do up to now (still researching if it's the best way, which is how I found this question) is that I keep a last_update field with a timestamp on when the data was last_updated and an altered field with a boolean on whether the data was altered (by a user action on the device)
So when I perform the sync:
I first copy the database to a backup (in case there is a problem)
I send all the rows that are marked as altered (the server handles conflicts)
then delete them
after that I find the max(last_update) value,
I subtract one minute from it
Then request all rows that have been updated after that value,(this will also also include the data I have sent because there is no way , unless there is a problem, that a row is set to altered with a last_update before the last non altered row)
It may cause some duplicate data being transfered (especially if you make A LOT of changes frequently) but in my case it's a rare phenomenon

Android | Update sqlite from mysql or update app with newer sqlite db?

Still newish to Android.
I need some advise, Should I
1. have a local sqlite DB, and have the app check for new records uptop in a mysql DB
OR
2. Publish my app with a full sqlite DB. When ever I insert new records to the full sql lite DB then publish updates?
I've been scouring the internet for some guidance. Since I am still newer to Android I wonder the difficulty in making #1 work (since I'll have to gen the php code as well).
My suggestion is:
If it's only 200 records now, it doesn't really matter if you preload it or get it from a web service (getting the data will be very quick). Usually preloaded database is better when there is a lot of data and you don't want the user to wait to long before using your App.
On the other hand if there is a lot of data, it will increase the apk size.
Create a web service method for updating the data from the server.
Create a web service method which indicate the client to delete some rows (I dont know what your application does, but usually it's needed)
What do you mean by 'uptop'? Assuming you mean 'online via an API'.
depending on the nature of your data (is is mission critical? what's the risks if it is stale? etc), it's good practice to pack static data with the app that can be referenced by the app much sooner than the updated data...the updated data is a task you run to update that stale data, and perhaps continue to run periodically to keep it updated.
It's bad practice to pack a SQLite db itself in an app, as some manufacturers do their own thing with the implementation of SQLite itself. So pack the SQL as text and create a fresh DB on the device with that.

SQL Server database and Android

I am connecting to a SQL Server database with the Android device. Yes I know not very advisable but everything works fine except ... well it's slow.
Here is what I do:
open conection
download table by table the data I need from the server database (with a connector I found online)
insert table by table into sqlite
I only select what I need; there are about 12 tables and some have like 300 items
Then I send some data to the server database (the select from 2 tables)
How could I make the thing work faster without using web services? (if possible)
If I do use web services will it be faster?
Thanks a lot in advance
PS: I know there are the risks about accessing the DB that way they are not relevant in this case.
Do you really need to replicate the same schema on Android? Try to narrow it down to only the essential data, and maybe create a new 'light' schema for the Android app. Do not use select *, only get the columns you need. Even with this, the first sync will probably be relatively slow. After you sync once, you can only get the newest items, so it should go faster.
If you want to use a webservice, you will have to rethink your model: instead of syncing tables with rows, you will work with entities (customers, orders, etc.). If you transfer the same amount of data, a webservice won't be faster, it can even be slower. The benefits of a webservice are that you don't have to know the exact schema on the server, so you don't need to change your app if it is changed (as long as it has all the data you need, of course); and that thinking in terms of a service will make you only use the data you need, making the whole interaction faster. And, it works over the Web, of course, so it will work with proxies, NAT, and what not.
After the initial sync, you could code your android app to retain the data in sqllite and only download the differences/changes on the next connection.
Depending on how changeable your data is on the server, this method could reduce you sync time.

What should be the preferred and efficient way to use database in android?

I have created a database for my application. I will use the data in this database, again and again. I just want to know the preferred way to do this.
One way is to query the database again and again, and the other way in my mind is to have multiple ArrayList for different fields, or something like that, to store data in the start of application in these Lists and then access these Lists whenever I need data(sort of a disconnected mode e.g. DataSets that we have in .Net).
So, which is the efficient way or is there any 3rd better way?
Is your database local, local and external (shipped to your apk) or remote? If it is local then you can query the database everytime you need. Because you rather have operation with your CPU than keep memory occupied. When it comes to remote database than you can implement various ideas about keeping the last query in case of disconnection, then on the next query release the last query results (not good to me, because you might have milion of results, which will occupy so much memory [scenario]), or save the query results (get result - translate into query for your own database = long process). Or you can query again the database again and again, with least effort so many results. I hope you get my idea and will serve you.

Storing Tables of Information on the Android Platform

I have about twenty pages of information that is stored in tables that needs to be stored in my Android application. Each column is a designated stop on a bus route and the column is filled with times that the bus will be at the stop. There is also certain information that needs to be associated with some times, such as if the bus is handicap accessible at a certain time.
Here is an example of one of the tables: Bus Times
I have thought about using a SQL lite as that seems as though it would be able to store these tables quite easily; but when I think of using SQL I think of dynamic data storage and this shouldn't be changing more than once a year.
Is SQL appropriate for this application? Is there a better way to do this?
Thanks,
Rob
I think a database is really the appropriate form for doing this. Data in a database don't have to chance regularly or very often, almost more important is the fact that you can relatively easy extract very specific information from a large data set. So if you need to store the data lcoally I would use a database.
Just a hint for another approach. Did you think about reading this data directly from the website? Judging from the style of this page I don't think they offer a webservice, but maybe you could parse it using HTTP Get? Don't know if the structure changes over time, but this solution would have the advantage that you don't need locale storage and if the data is update you don't have to manually update your database.
Hope could help you

Categories

Resources