I am planning to make a software which requires two or more databases to be in sync with a main server database ( located on a web server ). Suppose one user have installed my software on more than one computers. Suppose he updates some info on PC-1 then the change should be locally updated and if he is connected with the internet, it should get in sync with the main web server. When he opens the software on PC-2, latest into must be shown there ( assuming he is connected with the internet ).
Now suppose both PC-1 and PC-2 have same data, and both are offline. User deletes the data from PC-1 but don't deletes it from PC-2 ( he assumes it'll get managed automatically ), now when both of the systems go online, the record must be deleted from PC-2 too.
Basically, I am trying to find the database which was most recently updated or modified and sync it with the main database ( on the server ). How can I do it ?
It sounds like you want to synchronize some user data whenever the users or application becomes "online" again.
A couple of suitable services are:
Amazon Cognito Sync is an AWS service and client library that enables cross-device syncing of application-related user data. You can use it to synchronize user profile data across mobile devices and the web without requiring your own backend. The client libraries cache data locally so your app can read and write data regardless of device connectivity status. When the device is online, you can synchronize data, and if you set up push sync, notify other devices immediately that an update is available.
AWS AppSync enables developers to interact with their data by using a managed GraphQL service. GraphQL offers many benefits over traditional gateways, encourages declarative coding style, and works seamlessly with modern tools and frameworks, including React, React Native, iOS, and Android. GraphQL is a data language that was developed to enable apps to fetch data from servers. It has a declarative, self-documenting style. In a GraphQL operation, the client specifies how to structure the data when it is returned by the server. This makes it possible for the client to query only for the data it needs, in the format that it needs it in.
Related
I am developing an app that uses a database to store the data on the server, but I am trying to save some of the data locally, and in the event of no internet connection being established, save new data locally to the device and synchronize any changes to the server when an connection is re-established. What is the best and most efficient way to do this?
I have been looking at Androids Room persistence library and it seems like the logical choice, but I am not sure how it goes about synchronizing changes to/from the local storage database. I have looked at multiple threads and forums for help, but have had no luck so far. Please help.
One way is to build your own sync adapter: https://developer.android.com/training/sync-adapters
You will need to handle most of the sync logic between the client and the server, but that allows you to use any database technology in the server. From the docs:
A sync adapter doesn't automate any data transfer tasks. If you want to download data from a server and store it in a content provider, you have to provide the code that requests the data, downloads it, and inserts it in the provider. Similarly, if you want to send data to a server, you have to read it from a file, database, or provider, and send the necessary upload request. You also have to handle network errors that occur while your data transfer is running.
A sync adapter doesn't automatically handle conflicts between data on the server and data on the device. Also, it doesn't automatically detect if the data on the server is newer than the data on the device, or vice versa. Instead, you have to provide your own algorithms for handling this situation.
Use firestore and enable offline data persistence. https://firebase.google.com/docs/firestore/manage-data/enable-offline
I have a java client (Standalone app) that is using the Firebase Admin SDK, because I need to read values from the Realtime database whenever a value is changed. (A ValueChange listener is being used).
Currently I'm including the service-account.json in the app. Even if I set the roles to Viewer, using this service-account.json, I can create accounts usingFirebaseAuth.createCustomTokenAsync, which is something I dont want.
Is there a way to make a service-account with Realtime-database read only?
I know I can use setDatabaseAuthVariableOverride to "limit", but if someone extracts my service-account.json from the app/jar, they have the power to do everything..
I'm not using node.js, just Java with spring. And js firebase is a no, because I need to receive updates even without a web page.
Never distribute service accounts to end users. They should only go to trusted parties.
There is currently no fine-grained way to control access to Realtime Database via service accounts. Access control is performed via Firebase Authentication client libraries, which are not available for non-Android Java clients.
Here is the current scenario:
I have two(2) Android phones.
Android Phone 1 as the server phone.
Android Phone 2 as the client phone.
Here is what I want to do:
I want to create an Android-based app (E.g. Student Information app) where it will have basically two (2) modes:
Server - for adding, editing and deleting data on a local database.
Client - for viewing data from the database of the server.
The app will be installed to Android Phone 1 and set to Server mode.
The app will be installed to Android Phone 2 and set to Client mode.
I want to ask these questions:
I want to locally host the database of the Server app, so that Client app will be able to view the data. Is this possible?
If yes, how can I do it?
Note:
I am currently a web developer so I know that connected on the same network is a requirement.
I have implemented the same concept on a medium business where the web-based system is locally hosted so that computers on the same network can access it.
Suggest everything that you want to suggest, except the disadvantage of doing this concept. I am aware of some obvious disadvantages based from my research and willing to face the disadvantages provided that I will be able to implement the concept.
Rooting the phones is an option.
I want to accommodate small-sized business that is why I want to use Android phones rather than using Desktop Computers/Laptop.
I have read similar suggested questions here based on my title.
We have done the exact same thing in my company. The way we solved this is that the server exposes a service using the Android NSD API, so the clients (using the same API) can find it on the network. And after a client has connected to the server, the server sends its database file (yes, the .db file in /data/data/...) to the client via OutputStream. When the client receives the entire database and checks for its integrity, it copies it to its own /data/data/... and restarts part of the app.
Android NSD
I am making an application similar to that of apps such as pay by phone and paymobile, which are apps used to pay for parking instead of using a parking meter and having to display a ticket in your vehicle.
I need to start with the back-end (the database) and was wondering if SQL would be appropriate for this app.
As SQLite is stored on the system (the Database) there will be data such parking details and payment details.
Will I be able to send this data to say my laptop which will act as the server for the traffic wardens device to check number plates?
Or would I have to use a sql software that is not on the applications itself?
Any thoughts and suggestions would be much appreciated :D
SQL is perfect for back end database needs. You can various flavors of SQL like Oracle or MySQL on the back end. As far as the application data being sent to the server (your backend laptop), that will be taken care by the application level programming. For android, there are various ways to send data, using the native class AsyncTask or using third party libraries like Retrofit and Volley. You need to take a decision depending on the architecture of your app.
Try this
Create database on your server
Create Web API like .Net MVC on your server
Create connection between your Web API and your database
In your mobile app you can use webservice to get our put your data to database
You can encyrpt your data on your database to more safety
do not use SQLite , because it is unsafe to keep your important data.
I am developing an Android application where users will see lists of Groups and join 1-* Groups. Within the Groups will be members and users can message each other within the group they have joined. Sending messages 1 person to many and reply all.
I want this to support multiple devices. So, if i join a group and someone sends me a message, i want to see that message on my phone and tablet. If both have the app installed.
I want the user to be able to see group details while offline.
I have been doing some research and drawing diagrams on how this could work.
What are my options for how to set this up with a remote database?
Here are a couple of the options that i have finally narrowed down to.
Have the remote DB store everything. Have a local DB on the device that reflects the remote DB. Have the remote DB contain a version number. At some point, either scheduled or triggered, the app compares the version numbers in the local and remote and if the local is out of date it will update to the current remote DB.
Have the remote DB store everything. Have a local DB on the device that reflects everything in the remote DB except the messaging system. This would behave similar to #1. Except the tables and stuff that are related to the messaging system would "somehow, gcm maybe" send a message to all devices associated with the user that a message relating to the user has changed and the app will then update to the most recent version of the remote messaging tables in the remote database. Then their local database contains the new data and their "message box" would be updated.
What would be the best way to do this? How is this done currently in most systems? Are there more options then what i listed?
Remote DB: MySql
Local DB: sqlite
I am aware of some similar questions here on SO, but i am wanting to know if either of these options or something else would be best for my specific scenario. Mainly how to handle the messaging part.
Thanks
I think Option 1 is a pretty standard way of handling this problem.
A DB version # could work, but if it changes frequently you will end up resync all the data very often. Its probably better if you just store "Last Modified Date" on records and only pull down things that have changed since the last sync. That way you can return a smaller set of new records.
You would only want to pull down public information (the groups) and the information specific to the user. The remote DB would have everything, but the local DB would only consist of data that is related to the user.
I found this tutorial that walks through how this might be implemented using php on the remote server for API access. You could streamline this process by using an ORM or "Out of the Box" API solution.
I'm sure there are more elegant solutions out there for syncing a local Android DB with a remote but this is likely the most practical approach for the non-enterprise solutions.