iOS and Xojo Cloud File Sync

Targets iOS
1

This is a complex topic, and I’m not sure if it fits here or in another category. I’m looking for best practices but the impact will be felt most on the iOS end, so I felt this is a good place to start.

I am writing a running relay manager app.
There are teams who commit to pace for different legs.
The entire “plan” is updated based on all the remote input from the team.
Then on race day, they each check into each milestone, and could update their paces anytime along the way.

I’ve gone back and forward on how to manage the server end and since a 36 leg relay is a 5k JSON file, and It’s all still undergoing rapid changes on in the design, I’ve opted to do a file based synchronization, not database, although I’ll likely move it to a database later.

Current workflow:

When someone changes something in a leg, they sent the changes to the server.
If the team has never logged a change, the server opens up the template (JSON file) and inserts the changed portion and saves it out to the team’s folder.
If the team has logged a change, the server opens the team’s latest file, inserts the changes and saves it out.
Each leg has a version tracking how many iterations have occurred.
Once the current, updated plan, has been saved, the server responds with an OK and the client (iOS device) requests an update so that they have their change and any others that may have occurred along the way.

My Challenge:

I want to make the updates invisible to the end-user. What I mean by this is that when they update something like changing their pace from 7:40 to 7:55, I don’t want them to have to do anything to push the changes. It’s easy enough to send an update whenever they change anything, but is every keystroke change too frequent?

I’m on the fence about this, because the sample relay I’m working with is 200 miles with 36 legs (probably the most complex case I’ll ever encounter) and with a 5KB JSON file, maybe I can just be perpetually serving that back and forward without concern.

Part 2.
for the users who want to keep synced, but not submit changes, therefore not forcing an update, should I be communicating a version number of the file, or should I be just sending the 5kb file?

I was really worried about this when I started, but now I’m thinking 5KB every 10 seconds isn’t a big deal. I was so worried about the legs until I started sending the entire file and now I think it makes sense just to track a version version the entire file (if I even need to do that).

I have zero experience with this kind of thing, and don’t know what pitfalls I might encounter, so any help would be appreciated.

PS: If you run and want to beta test, I’d love the help. There are a bunch of other runner’s “utilities” in this app.

2

We currently have Ipads syncing timeclock punches with our XojoCloud server. We use JSON packets that can easily be larger than 5KB. So what you are envisioning shouldn’t be a problem at all. I would suggest using a backend MySQL or Postgres DB on the XojoCloud server rather than files. We use a SQLite db on the Ipad side to store information locally and then run a background thread to sync the data between the ipad and the XojoCloud Server.

3

Hey Steve, I’ll either do PostgreSQL (which I’m quite familiar with) or local SQLite db files. There is a good argument for encapsulation in local databases for this. I’m only using the files now while the formats are in flux so much, because rebuilding the database frequently is a pain.

I guess the point I was more thinking about was the frequency of updates and method to update: Just update everything, or only update when a change is detected.

because of the very small file size I’m thinking I should just push all the data every time.
Previously I was really married to the idea of checking version numbers and only updating if needed. I just don’t think this saves much.

4

We started off doing immediate updates of punches to the XojoCloud server. But discovered that some of our users were too fast in being able to clock in. So I separated the punch uploading into a separate thread that just watches for punches in the local sqlite database. It will upload between 1 and 20 punches depending upon how many have yet to be processed. This is all in one JSON record.

This thread is on a timer checking every 10 seconds.

5

Steve,

Do they all have to get the full update?

In my case there could be 3-12 people updating for their team on a relay race. There could be a hundred teams, but with the way I’ve updated it, they are all writing to their own files (soon own records in DB).

Also due to the nature of a running race, it’s not like people clock in and out milestones non-stop… there are delays.

What kind of quantity of transactions do you typically manage per min/hour etc?

6

We have a web app using handlespecialurl that the ipads communicate with using our own api. We currently have 40 ipads checking in with the server every three minutes. Plus the intermittent punches as I said go up every 10 seconds as they appear in the tables. We do have two large XojoCloud servers running the what we call the HSU app that the ipads communicate with. Those two servers most of the time are running about 25-30% of their capacity and that is hosting both a UI application for Web based access to the system and also the HSU app that communicates with the Ipads.

7

OK you are handling a lot more data than I have to worry about.
This is what I needed to know.

Thanks for the 411!