iink SDK on Device

Answered

Questions about ContentBlock IDs and ContentChanged event

We would like to be able to catch changes to IINK ContentBlocks in order to send information about the changes to a server and to share the changes with other devices.

Using an app that uses IINK, we were able to confirm that contentChanged events are fired when writing something and when ContentBlocks are moved and that we can get the IDs of the ContentBlocks in the event's parameter.

However, we noticed that there are cases where the IDs of ContentBlocks that were not modified are sometimes included in the parameter when we perform handwriting. We would like to know why that happens. Is there a way to get only the IDs of the ContentBlocks that were modified?

Could you give us some details about the rules that decide which ContentBlock IDs are returned as parameter to contentChanged?

Could you also answer the following questions about ContentBlock IDs?

- Can we assume that the IDs assigned to existing ContentBlocks do not change when we add or remove ContentBlocks (including when the addition or removal is caused by performing undo or redo).

- Is there an upper limit on the value of ContentBlock IDs?

- Can ContentBlock IDs change when we save to and read back from file?



Best Answer

Dear Nicolas,

currently, for your use-case, there is no easy solution that can be used:
-As you have seen, the contentChanged is fired very often (several times per second), and exporting each time the contentChanged function is fired will really slow down the application (customers who tried this approach were complaining it was unusable).
-The solution of exporting the contentPackage has been tested by some of our customers. We did not get a full feed-back, but it seems that approach was satisfying (but they only had like 2-3 users at the same time).

To get the second approach working, there is no magic: you can only have a user at a time ; when he has finished, the contentPackage is saved, and can be exported/sent to another user, which opens it (he will retrieve the content) and can deal with it.
As you can see, you cannot have many people writing at the same time, but only sequentially.

If the server can read the iink files sent by the clients, analyze them, and merge changes into 1 master file, we might be able to have only 1 or 2 editors on the devices. Is it possible to read the contents of the iink files? Are they JSON files?
>>The iink file has not been designed to be editable. The only way to proceed without the risk of corrupting is to proceed as just explained.

Best regards,

Olivier


Dear Nicolas,


currently, if I understand correctly, you would like to be able to exchange the changes you have in between several users?


For such use-case, customers usually save the contentPackage (resp. iink file), and exchange it with the other device/user.


Indeed, your approach seems rather complicated.


Best regards,


Olivier

Thank you Olivier, this is an interesting approach and would indeed simplify things a lot!

Do you know about the performance of that method? We would like, if possible, to reflect the drawing of each stroke on the other devices as soon as the stroke is finished (the user raises their pen). So we would likely be sending an update to the server, to be forwarded to the other devices, every time IINK calls contentChanged.

Would it be too much processing if we save the contentPackage and send it to the server at every event?

Also, we are still interested in the information about IDs which we asked in the initial question. If it is possible, we would like that information as well to help us decide which is the better way for us.

Sorry for all the replies in succession.

What we are thinking about is a kind of collaboration tool where multiple users can write on their device and see what others wrote in near real-time. However, to simplify things, we want to impose a restriction that a user cannot modify what another user writes (maybe we could remove that restriction if it actually complicates the implementation). If we take the approach where we send iink files back and forth, I imagine that we would need to overlay multiple editors over one another, one editor for every user, with each editor using its own iink file.

Again, from a performance point of view, would such a setup be usable if we have let's say 50 users at the same time, meaning 50 full screen iink editors being displayed (only 1 would be accepting pen input)? What do you estimate would be the upper limit for the number of simultaneous visible editors?

Maybe one way to work around this issue would be to have 1 master iink file on the server. If the server can read the iink files sent by the clients, analyze them, and merge changes into 1 master file, we might be able to have only 1 or 2 editors on the devices. Is it possible to read the contents of the iink files? Are they JSON files?

Answer

Dear Nicolas,

currently, for your use-case, there is no easy solution that can be used:
-As you have seen, the contentChanged is fired very often (several times per second), and exporting each time the contentChanged function is fired will really slow down the application (customers who tried this approach were complaining it was unusable).
-The solution of exporting the contentPackage has been tested by some of our customers. We did not get a full feed-back, but it seems that approach was satisfying (but they only had like 2-3 users at the same time).

To get the second approach working, there is no magic: you can only have a user at a time ; when he has finished, the contentPackage is saved, and can be exported/sent to another user, which opens it (he will retrieve the content) and can deal with it.
As you can see, you cannot have many people writing at the same time, but only sequentially.

If the server can read the iink files sent by the clients, analyze them, and merge changes into 1 master file, we might be able to have only 1 or 2 editors on the devices. Is it possible to read the contents of the iink files? Are they JSON files?
>>The iink file has not been designed to be editable. The only way to proceed without the risk of corrupting is to proceed as just explained.

Best regards,

Olivier