Multi-app editing with "Automatically update when file is changed by another program"
Dear Fletcher,
Everything still ticking along here nicely with the latest beta (although last month's TestFlight issue preserved your original submission date which means it's up for expiry again in a week?). I said I'd write with some usability feedback soon but one thing has caused a couple issues with data loss, so I wanted to ask on this first:
Is Settings > Advanced > Automatically update when file is changed by another program operational yet? Ticking the option doesn't seem to make any difference when editing a file in another app whilst that file is open in Composer. I was surprised/amazed to see this option make it over from the macOS version so soon, what with it being at the mercy of the storage/caching mysteries of iOS file provider system...
But using a pairing of other apps - e.g. 1Writer and Textastic - I can see that multi-app editing works out of the box: Bi-directional updates take place reliably (1Writer even displays an "Updated" tick box HUD message to confirm that it has detected an external update), and apps reload the file instantly as soon as they are switched to.
The current behaviour for Composer seems to be not only that external edits are not detected and so not displayed, but they are overridden with the original (pre-edit) state of the document. Composer is obviously (and rightly) saving its representation of the document when sent to the background, but this means that when switching back to the app that has made the edits, those edits are now overwritten with the earlier version for this app too (since it updates live), and the data is lost in the process.
Or, in a less long-winded form:
1) Start in Composer: Type "foo"
2) Switch to 1Writer: Type the new text to make "foo bar"
3) Switch back to Composer: Still displaying only "foo"
4) Switch back to 1Writer: Live update to "foo", erasing "bar"
I have also had some cases where adding the "bar" directly in Composer gets reverted after a switch in and out, though again I'm wary to expect too much of multi-app file awareness. Having said this, other apps seem to do this without any special configuration, so what does this Settings checkbox do internally?
Thanks again,
Mark
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Fletcher on 30 Mar, 2019 12:39 AM
Mark,
Thanks for writing.
The file merge code was based on the needs of the macOS app, and is one
of the things that still needs fine tuning on iOS.
The original design was to merge changes made to the file while the
macOS app was running (e.g. typically changes made on another device,
but you can also use multiple apps at the same time to edit a file.)
iOS works a bit differently, and tends to disable/throttle background
apps a bit more than macOS.
And as you note, iCloud is a bit of a black box when it comes to file sync.
If you're editing a file in multiple apps on a single iOS device, then
the signal indicating that a file has been changed is probably not
making it to the app, so it effectively gets ignored. I'll have to add
code to check for changes whenever the app comes back to the foreground
if there is an open file.
For now, the file merging should work reliably if you are working on the
same file on multiple devices (e.g. Dropbox or iCloud files.) Or if you
have two apps open on an iPad at the same time.
Dropbox should work ok even if switching back and forth between apps,
since Composer can control dropbox sync. But iCloud is less reliable
for this.
To use two apps simultaneously on the same file, open them using split
screen so that both apps stay active. Any changes made by the other app
should appear as soon as the file is saved (which doesn't always happen
instantly since iOS likes to save on its own time. I need to add some
triggers to force a save when the keyboard disappears for example, but
closing the file forces a save.)
Fletcher
2 Posted by marko on 02 Apr, 2019 05:14 PM
Hi Fletcher,
Thanks for the details on what's going on under the hood, and confirmation of why I'm seeing differences with how the other apps behave.
I should have specified that my situation is all about changes getting updated when an app switch occurs, though: I am iPhone-only (and so was once again jealous to be lacking Split-View if this is already working for that). File writes do work immediately when switching to the background, though, so I get instant and reliable updates in the other app as soon as I've switched to it.
(If I used an iPad then I'd certainly be looking for saves on events like iOS keyboard dismiss etc. but then I'd also be using a hardware keyboard anyway - and would probably then be demanding a Settings > Preview > Update preview whenever text changes -level of save frequency for my Split View app too!)
My problem with the app-switch updates is only about the reverse trip: I guess from what you say that 1Writer/Textastic/etc must have specifically coded to check for file updates when brought to the foreground, and if you're going to do the same then my use case will certainly be addressed here.
At the moment I'm trying to remember to manually close the document before switching out, before opening it again after switching back (the Recent Files list from the latest beta helps a lot with all this!). The manual close is not to force a save (you're right that it does, but backgrounding will do so anyway), but instead to ensure that the file has to be reopened and read afresh (in order to notice the updates). Removing this requirement will be perfect.
And as for that original checkbox in the Settings... I hadn't even realised that this was file merge code... - so if there's any way that this can make its way from macOS to iOS then you might have a solution to one of the reasons many of us are still wary of cross-device editing with iCloud Drive ;)
Speak soon,
Mark
Support Staff 3 Posted by Fletcher on 04 Apr, 2019 01:11 AM
Mark,
Still some things to work on, but the newest build (pushed out a bit ago) should improve the cooperation between Composer and other applications if you are jumping back and forth between applications.
Thanks again for writing in!!
Fletcher
--
Fletcher T. Penney
Manager, Founder
MultiMarkdown Software, LLC
[email blocked]
4 Posted by marko on 05 Apr, 2019 12:18 AM
Fletcher hi,
Certainly a nice relief to be greeted with a new TestFlight build this morning... with a full three months to play with now, but with far more than just an expiry reset in the release notes! But then to read in them that you have already implemented the backing file checks, I was over the moon...
There is a definite trap in the check that occurs when switching apps multiple times, and I'll write down the steps to reproduce when I get some proper time to isolate it - but tonight I just wanted to send my thanks for this particular work :)
And with this build I can also already strike off another of the requests I was going to make next... that of Xs Max support? Only took a moment to clock why the app suddenly felt more 'sharp' and 'solid'... I'm sure you've got lots of other plans for UI layout, but not being both zoomed-in and letterboxed would definitely have been worthy of a mention in the release notes for me!
And to read also of the background work underway on core components and to improve (again!?) the text engine performance, I think I'm as excited as you are!
Speak soon,
Mark