Tips & Tricks: optimizing blob synchronization

by Giuseppe Lanzi on 11/19/2015

I’m reviving the Tips & Tricks feature after a relatively long pause, and to do so I decided to take on a subject in which many people have expressed interest: optimizing blob synchronization.

As you know, the Instant Developer synchronization framework is based on transporting data using XML strings: both the individual changes of differential synchronization and the complete status of each document to be copied onto the device in the event of a full synchronization are saved in XML and transferred to the device. And it’s here that we can run up against the limit of the device which, when parsing a relatively lengthy XML string, runs out of memory and forces the app to close.

The math is simple: synchronizing 1000 entities, each with a 200 KB blob, the server will have to send the client 200 x 1000 KB = 200 MB! If we’re talking about a single XML string, even decidedly smaller numbers can make it difficult to open. Many of you know that partial synchronization can help us out, because it lets us synchronize documents in batches that are far less numerous, but it’s not the only option we have to choose from.

I’d like it if the app were able to:

  1. freely synchronize documents, avoiding sending the blobs to the client;
  2. provide a simple way to download the missing blobs when they’re needed.

Here you can find an example project in which the Landscape class is synchronized. It depicts a landscape with a name and a photo, and the latter is represented with a blob on database. The result I wanted to achieve in creating it was to have the fastest possible synchronization, but at the same time obtain the image to display to the user at the appropriate time. To achieve this, I:

  1. created a domain to indicate where the application blobs express the concept MY_BLOB;
  2. used the onGetNamedPropertyValue event to instruct the framework not to send the blobs to the client;
  3. used the SyncService.ResyncDocument() method to obtain the blobs at the right time.

In fact, during synchronization, the various document classes are notified of the onGetNamedPropertyValue event with DO_DONTSYNC as the propertyName, to allow the user to use the Documento.DontSync() method and prevent automatic synchronization of a specific property. I chose the blobs.

Once I finished that, I asked myself, “when do I want the user to receive the image?”, and in my case the answer was “when they look at the document in detail.” So I used the onChangeRow event to launch a global procedure that uses the ResyncDocument method to download the image from the server on the fly. All of this happens only if all the blobs that use the MY_BLOB concept in the document are null.

Try out this test, and you’ll see how it works right away:

  1. launch the two applications contained in the project, which represent the synchronization server and the mobile app;
  2. use the Sync Now command to run the first synchronization;
  3. open the debug and you’ll see that the client received 659 bytes – that’s not much;
  4. close the debug;
  5. select a landscape from the list and reopen the debug. You’ll see that the client received the entire document – a few thousand kilobytes.

The side effect of my solution is that this way, an Internet connection is required when the detail is opened, but to get around this problem we can simply use my same method in a background procedure in a server session on the device.

But I’ll leave this exercise to you. ūüôā

What trick would you like to read about in our next technical article?

  •    Implementing a multi-domain synchronization
  •    A practical example of using Foundation DO Web APIs with the Cloud editions
  •    Other (specify in the comments)
Loading ... Loading ...

Leave a Comment

Previous post:

Next post: