Category Archives: File management

Moving Files and Folders

Posted on by

(or “Why File Synchronisation is Hard”)

One of the questions I get asked most often is why it’s not currently possible to move files or folders in UX Write. While this might seem like a very simple feature to add, there’s actually a lot more to the story, due to the need to ensure reliable file synchronisation in which no data loss can ever occur.

Normally, this is all handled by the operating system and third-party sync clients like that provided by Dropbox. However, Apple made the tremendously unfortunate decision to exclude any notion of a user-visible filesystem on iOS, so this isn’t possible. Desktop operating systems have had built-in file management capabilities for more than thirty years, and everyone who’s ever used a personal computer is familiar with the concept of organising their files into different folders.

While unnecessary for casual usage like browsing the web or playing games, file management is absolutely critical for content creation and management; its omission from iOS cripples the iPad as a productivity device. Nonetheless, it is possible for individual app developers to work around this limitation, but doing so is highly non-trivial in the case where synchronisation with an online file storage service is needed.

For the developer, moving files locally on a device is trivial to implement. There’s programming interfaces built in to the operating system to do this, and it’s a simple task to create a user interface for selecting the files to move and their destination. The difficulty lies in synchronising those changes with a server (or “The Cloud”, if you prefer that term) in such a way that guarantees no data gets lost in the process.

Clients and server

With online storage services, it’s possible to have multiple devices and people with access to a particular account. Software like the Dropbox desktop client, and UX Write itself, allow changes to be made to files while you are offline, and then later push those changes to the server. However, cases can sometimes arise in which different people have changed or moved the same file or folder while offline, and then later reconnect to the Internet and sync with the server. This is where things can go disastrously wrong, if conflicts are not handled carefully by the software.

An Example

Suppose Bob and Alice have access to a shared account, and are working with the same set of documents relating to a particular project. Both are working offline, when Bob decides to move a folder to a different location and Alice simultaneously makes some changes to a document inside that folder.

When they subsequently reconnect to the Internet, their iPad or PC will try to sync with the sever. Whoever happens to sync first will “win” and have their changes applied to the server successfully, while the “loser” will run into errors, with the server reporting that the folder doesn’t exist any more.

If Bob wins, the folder will be moved, but when Alice’s device tries to upload her modified version, it will encounter an error because the folder it was in no longer exists at its previous location. An incorrectly-implemented syncing mechanism may conclude that because it can no longer see a folder at that location on the server, it must have been deleted and that it should therefore result in the local copy being deleted as well — which happens to contain Alice’s modified document. The syncing mechanism would then see what appears to be a completely new folder on the server, and download that. But Alice’s changes would be gone.

Solutions

File synchronisation is a complex topic, but necessarily has to be addressed to at least some extent by any app that lets you work offline with documents whose primary copy resides online. It’s unacceptable for an app to blindly push changes to a server without checking to see if the files or folders in question have been modified by someone else, and it’s also unacceptable for the app to download all changes from the server and overwrite local copies that may have been modified independently. It’s necessary to provide both conflict detection and resolution capabilities, with the latter preferably involving automatic merging of changes where possible.

There are many possible solutions to these problems, which have been implemented in various syncing clients and version control systems. Git provides what I consider to be the most elegant solution to this (plus a whole host of other things), but that’s another topic entirely which I won’t get into right now.

The simplest approach I’ve been considering for an initial implementation of moving is to do it synchronously — that is, require you to be online at the time of the move, and wait until the server has reported a successful completion of the operation before allowing you to continue using the program. In computer science terms, this is known as an “atomic test and set” operation, where a check is performed to see if the change is valid, and if so, the change is made, all in one indivisible operation, avoiding race conditions. The alternative is to perform the move asynchronously — that is, in the background at a later point in time; but that has all the problems mentioned above, and requires keeping track of lots of extra information in order to do it reliably.

In the long term, I plan to integrate support for Git directly into UX Write, so you’ll have access to its full set of functionality, including versioning, branching & merging, and conflict resolution. Software developers use this all the time for collaboration, and I’d encourage you to learn more about it if you’re interested. I’ll be posting more about this integration in the future once I’ve had a chance to think it through further.

Doesn’t iCloud handle all of this?

Sort of, but only in the context of a single application and a single user. Since UX Write only runs on the iPhone and iPad, many people use it in conjunction with other applications like Microsoft Word on their desktop, so it’s necessary to sync the files between different platforms. iCloud has a restriction that only allows files to be accessed from within the application that created them, and provides neither a generic filesystem model of the sort found on Mac, Windows, or Linux, nor does it cater for the need to edit a given document with different applications. So that basically rules it out, as far as I’m concerned.

In Summary

Better file management facilities are coming to UX Write, but as described above these aren’t straightforward to provide in the context of the ecosystem we have today where everything is stored and synced online across multiple devices. At the moment, my primary focus is on building a word processor, not a file manager, so the latter has secondary priority. But I am very much aware of the need for improvements in this area, and will get to them eventually.

Using Box with UX Write

Posted on by

The latest update to UX Write, version 1.1.6, has just gone live on the app store. This introduces integration with the native Box app for the iPad, which provides an alternative to UX Write’s own built-in file management and syncing capabilities.

One of the biggest problems with the iPad for content creation tasks is the lack of built-in file management capabilities. Despite these being present on every major desktop operating system for the past 30 years and a critical component of almost all professional workflows, the iPad itself does a very poor job of catering to these needs. Thus, it is left up to third-party developers to implement their own file management and syncing solutions, which is a huge time sink that takes away time from working on core app features. Thus I’m always happy to see apps & SDKs which make this process easier.

Box is an online storage service (similar to Dropbox and Google Drive) and has client apps for the iPad, iPhone, Android, Mac, and Windows. A critical and unique feature of the native iPad app is it contains facilities that allow both opening and saving of files with other apps. While the iPad has a built-in “Open in” feature (supported in many apps) which let you send a document one way, there’s usually no way to get it back. Box provides an SDK that individual app developers can use to provide the ability for you to save a document back to Box once you’ve modified it. This is a critical piece of the puzzle that is missing from other solutions that I’m aware of.

Using Box with UX Write

Once you have an account with Box (which you can register for free) and install the Box app, here’s what you’ll see:

Box - Main screen

To create a new document, click on the cloud ‘+’ button in either the top-right or bottom-left corner of the screen. Then select the app (UX Write), and the file type (e.g. DOCX):

Box - Create document

This will bring up UX Write, and you can start adding text to your document. When you’re done, tap on “Close” and then “Save to Box”:

Box - Save

This will switch to the Box app, which will prompt you to type in a name for the document. When you’re done, press upload.

Box - Upload

And that’s it! You can now have your document synced with other devices and computers that you’ve installed the Box client on. You can also view and edit the document in any other Box-compatible apps you have installed:

Box - View & edit

Creating Templates in UX Write

Posted on by

One of the features I’ve had a lot of requests for recently is the ability to create “template” documents, whereby you set up all of your styles in the way you want them, and then all new documents you create will have the same look and feel.

Version 1.0.5 has just hit the app store, and adds the ability to do this, via some additional file management features – specifically the ability to duplicate and rename files. Here’s how:

1. Create a new document, giving it a name like “Template” (you can choose any name)

2. Open the document and configure the styles (go to the formatting menu then “Edit Styles”).

As an example, let’s make the default font Helvetica Neue, change all Heading 1 elements to blue with a bottom border, and all Heading 2 elements to italic blue. We’ll also add custom styles for Title, Author, and Abstract:

Creating a new template – Setting up Styles

3. Now you have your template. Leave the content empty, and go back to the file browser.

4. To create a new document based on this template, press and hold on the template document, and select “Duplicate” from the menu.

5. The document will initially by called “Template copy”, but you can immediately start typing in a new name, e.g. “Project Plan”.

Now you can write your document, format it using the styles you set up earlier, and it will look just as you intended from the template:

Example document created from a template