Mobile app development with Dropbox Datastore API
Dropbox has three APIs for mobile apps:
The Sync API is good, but according to statistics, many mobile developers use it to store structured data. Serialize them in JSON, save to files, synchronize with the cloud. This works as long as there is no simultaneous change of data from different devices. Even if you change non-conflicting data, this will be a conflict at the file level and Dropbox will not be able to solve it.
Therefore, we have released the Datastore API . It does not synchronize files, but data, is somewhat similar to a remote NoSQL database with caching.
')
For example, you have a SQLite database. It syncs with the cloud using the Dropbox Core API. If you change the values ​​in different rows of the table on different devices, we get a file synchronization conflict. Although changes at the data level do not conflict with each other. The datastore API solves this problem.
The DataStore uses not a relational data model, but something similar to NoSQL. Each Dropbox user has a repository, the repository contains tables. Tables are divided into records. Each record has fields with values. The records in the table can have a different set of fields, that is, in fact, this is not a table, there are no rows and columns, and there is no rigid structure.
The magic begins after calling the sync method. In iOS and Android, sync is called after the completion of a meaningful sequence of data changes. Can be compared with a commit in version control systems.
In the background, Dropbox constantly receives data changes from the server. When you call sync, your local changes are merged with server edits and sent back. Server changes are applied to the local copy only after calling Sync.
We paid a lot of attention to conflict resolution. A conflict occurs when two devices simultaneously update the same storage. For example, two devices lose access to the Internet. Revision 1 of the repository is saved locally. Both devices change data in storage. When the Internet and the synchronization of devices with the server, we get two different versions of revision 2, this is a conflict.
If changes to a conflict revision affect different entries, they are automatically merged. If the changes affect the same entry, the conflict resolution rules apply. Rules are set at the table or field level.
When applying these rules to the server, you will receive a synchronization error with details about the changes and you can programmatically combine the data and send it to the server again.
By default, the “server wins” rule works. If an application tries to send a field change to a server that has already been changed, the server version remains, the field value coming from the device is thrown. For example, I do not have access to the network and on my smartphone I change Masha's phone number to 911. Meanwhile, my secretary, with Internet access, changes Masha's number to 112. When my smartphone goes online, my number changes will be discarded. Masha's number will be 112.
You can change the default rule to “client wins”, all server changes will be discarded and Masha will be 911. Which is quite strange, therefore, the server “wins” the default rule.
For numerical values, there are additionally the rules of "minimum", "maximum" and "amount". That is, in a conflict situation, a minimum or maximum value will be selected. “Maximum” is convenient for values ​​that should not be decremented, for example, incremental counters.
In the "sum" rule, the result of resolving a conflict is the sum of the change in value. It sounds weird, but it works, for example, for a button click count in an application. The user simultaneously presses it from two different devices, the server summarizes the result. Two devices are synchronized with the server, there were 3 in the field. One device changed it to 4, the other to 5. The field synchronization will result in 6.
To resolve conflicts in lists, we use Operational Transformation. It is also used in Google Wave and Google Docs.
For example, we have an ACZ list. On one device, insert B into the second position and simultaneously insert Z from another device into the third. The result should be ABCXZ, not ABXCZ. It sounds simple, but the implementation required the use of tricky algorithms.
Guido Van Rossum (the creator of the Python language, now works in Dropbox) is engaged in designing the storage and resolving conflicts. He wrote a detailed technical post about how this happens.
The official Dropbox API component is in the Xamarin component store.
A detailed step-by-step application development example with the Datastore API on the Xamarin blog .
approx. per. In my opinion, the new API from dropbox is very useful. When developing Coin Keeper, we spent a lot of time on inventing and implementing synchronization of the application with the server. Then two more months corrected errors. With the Datastore API, everything would be much easier. On the other hand, all advantages are crossed out by the requirement of the Dropbox account from the user.
Would you use the Datastore API in your application?
Subscribe to our blog . Every Thursday, useful articles about mobile development, marketing and business of mobile studio.
- Drop-ins are two simple UI components: Chooser to select a file from the user's Dropbox directories and Saver to save files to Dropbox. No configuration, authentication. Call the component, in return receive a link to the file. Under iOS and Android, only Chooser is available, Saver will appear later.
- Core API is the lowest level API. It allows you to read and write files and directories on the Dropbox server. Authors call API - RESTish. That is, it uses HTTP, readable URLs, JSON responses, but does not follow the REST principles thoroughly. Authentication uses OAuth 2.0.
- Sync API runs on top of the Core API and looks like access to the file system. Directories and files are accessible even without access to the Internet and are synchronized automatically with Dropbox servers. The most convenient API for developing mobile applications.
The Sync API is good, but according to statistics, many mobile developers use it to store structured data. Serialize them in JSON, save to files, synchronize with the cloud. This works as long as there is no simultaneous change of data from different devices. Even if you change non-conflicting data, this will be a conflict at the file level and Dropbox will not be able to solve it.
Therefore, we have released the Datastore API . It does not synchronize files, but data, is somewhat similar to a remote NoSQL database with caching.
')
For example, you have a SQLite database. It syncs with the cloud using the Dropbox Core API. If you change the values ​​in different rows of the table on different devices, we get a file synchronization conflict. Although changes at the data level do not conflict with each other. The datastore API solves this problem.
Data model
The DataStore uses not a relational data model, but something similar to NoSQL. Each Dropbox user has a repository, the repository contains tables. Tables are divided into records. Each record has fields with values. The records in the table can have a different set of fields, that is, in fact, this is not a table, there are no rows and columns, and there is no rigid structure.
Synchronization
The magic begins after calling the sync method. In iOS and Android, sync is called after the completion of a meaningful sequence of data changes. Can be compared with a commit in version control systems.
In the background, Dropbox constantly receives data changes from the server. When you call sync, your local changes are merged with server edits and sent back. Server changes are applied to the local copy only after calling Sync.
Conflict resolution
We paid a lot of attention to conflict resolution. A conflict occurs when two devices simultaneously update the same storage. For example, two devices lose access to the Internet. Revision 1 of the repository is saved locally. Both devices change data in storage. When the Internet and the synchronization of devices with the server, we get two different versions of revision 2, this is a conflict.
If changes to a conflict revision affect different entries, they are automatically merged. If the changes affect the same entry, the conflict resolution rules apply. Rules are set at the table or field level.
When applying these rules to the server, you will receive a synchronization error with details about the changes and you can programmatically combine the data and send it to the server again.
By default, the “server wins” rule works. If an application tries to send a field change to a server that has already been changed, the server version remains, the field value coming from the device is thrown. For example, I do not have access to the network and on my smartphone I change Masha's phone number to 911. Meanwhile, my secretary, with Internet access, changes Masha's number to 112. When my smartphone goes online, my number changes will be discarded. Masha's number will be 112.
You can change the default rule to “client wins”, all server changes will be discarded and Masha will be 911. Which is quite strange, therefore, the server “wins” the default rule.
For numerical values, there are additionally the rules of "minimum", "maximum" and "amount". That is, in a conflict situation, a minimum or maximum value will be selected. “Maximum” is convenient for values ​​that should not be decremented, for example, incremental counters.
In the "sum" rule, the result of resolving a conflict is the sum of the change in value. It sounds weird, but it works, for example, for a button click count in an application. The user simultaneously presses it from two different devices, the server summarizes the result. Two devices are synchronized with the server, there were 3 in the field. One device changed it to 4, the other to 5. The field synchronization will result in 6.
To resolve conflicts in lists, we use Operational Transformation. It is also used in Google Wave and Google Docs.
For example, we have an ACZ list. On one device, insert B into the second position and simultaneously insert Z from another device into the third. The result should be ABCXZ, not ABXCZ. It sounds simple, but the implementation required the use of tricky algorithms.
Guido Van Rossum (the creator of the Python language, now works in Dropbox) is engaged in designing the storage and resolving conflicts. He wrote a detailed technical post about how this happens.
Dropbox API in Xamarin applications
The official Dropbox API component is in the Xamarin component store.
A detailed step-by-step application development example with the Datastore API on the Xamarin blog .
approx. per. In my opinion, the new API from dropbox is very useful. When developing Coin Keeper, we spent a lot of time on inventing and implementing synchronization of the application with the server. Then two more months corrected errors. With the Datastore API, everything would be much easier. On the other hand, all advantages are crossed out by the requirement of the Dropbox account from the user.
Would you use the Datastore API in your application?
Subscribe to our blog . Every Thursday, useful articles about mobile development, marketing and business of mobile studio.
Source: https://habr.com/ru/post/196208/
All Articles