Just tried this. It's really good.
I tried Inkle on iPad and it was slow and janky with too many CSS animations. Plus everything required several clicks to respond. Twine 2 on the other hand was neat and responsive - seemed just perfect for working on a tablet with an external keyboard.
With one massive, massive flaw.
With no way to get the story off of the iPad, I'm left with this brilliant way of working that's utterly redundant. I now have the nicest way to write IF in front of me with no way to publish the result. This is heartbreaking.
Is there something I'm missing here or is this really it?
After experimenting with things, this seemed like the one reliable method of getting a file out of iOS. I would be all about a less cumbersome method but I haven't been able to find one. Also-- testing has been basically confined to my own experience-- during the betas we did not get many bugs reported by folks on iOS, so it's totally possible there are flaws in how it works right now.
Let me know if this works at all; sounds like it may need some more work to get the feature to where it needs to be.
And thanks too for the compliment -- one of my big goals was to try to get a good experience on iOS/Android and it sounds like we at least made some good progress on that front.
Downloaded Dropbox and tried archiving again. It works! Thanks very much, this is lovely. Not really bothered how clunky it is, so long as I can save stuff out.
One issue: I tried this in Chrome for iPad and it just gave me a failed download page. This is a bit of a shame because Twine 2 runs much faster in the iPad version of Chrome. The data isn't carried between browsers either. Let us know if a fix evolves or if there's a workaround...
Anyway-- logged this at https://bitbucket.org/klembot/twinejs/issue/64
Regarding Offline Pages, they aren't executing data:application URIs. Meaning you can't export the archive from there. So what would be an excellent way to work on iPad offline is a no go for now. I've emailed their support and described the problem. Hopefully they'll get back to me with either a workaround or maybe an update.
I'll post news if I get any.
I basically have to manually delete anything and everything character by character. Urgh.
I'd have submitted a bug but Bitbucket banned my account because I tried to make an account. So, um, yeah, then I sent them a bug report too.
If you are talking about the Passage Contents textarea then Twine 2 is using the CodeMirror widget to handle the editing of that text, and they have a number of open issues related to iOS.
I recently lost all my work when I updated iOS. The browser was set to retain data from only websites visited, so now I've set it to save all data forever. An archive would have helped, but when I try to load from file it just defaults to asking for a photo from my camera folder.
If I'm not doing something wrong here, then working on the iPad isn't viable. With no way to load data in I can't confidently work on stuff. I don't want to lose my intro again and then have to build the rest separately in chunks.
Would it be feasible to have just a text field hidden somewhere where iPad users can copy-paste the html from a project and try to parse it? It would be ugly but it's better than working on something that might be forced to be fragmented. Is there something already like that?
Oh, and Offline Pages got back to me. They say it's a bug that data:application URIs aren't working on their app and they will try to ship a fix soon, but of course they have to wait for app store approval. So offline on iPad should be able to be a thing.
I believe that you can save/load the archive file to this apps, though I have not tested this myself.
iOS doesn't handle open file links like you would expect from a desktop. Essentially it only gives you the option to take a photo or video, or import one from the library when you click said link. There is no option to "import from dropbox" or google drive so while you can write on your ipad, export to dropbox and continue on your computer, going from the computer to the ipad is pretty much impossible.
Also it doesn't work if you copy a dropbox link for the archived file and paste it in the browser url, as it just gives you a page with the content of that html archive file. Unless the feature is somehow directly integrated with a drive or dropbox api, I don't think you'll ever be able to go from desktop to ipad.
The png data format is broken into chunks for certain types of information. You can pretty much piggy-back a bunch of data on a png by loading it into the tEXt chunk which stores text information in a key/value pair format. There's no real limit on this as you specify the size of the chunk and anything trying to read it will skip chunks that aren't relevant. It doesn't affect the image.
Like I said, I have code for inserting text data into pngs and extracting that data in Flash:
The idea of stuffing data into PNG metadata strikes me as a really clever solution to the problem, though I wish we could keep archives in plain text for ease of extraction by third-party tools. Key question to me is whether iOS would munge metadata, perhaps in the interests of user privacy. I guess it would be possible to encode the archive in the image data itself, but that sounds... complicated.
Would a virus scanner see it as an attack vector?
What would happen if the image is opened in an image viewer, would it try to run the JS.
There's the important chunks that make the image and then there's - flavour. Just extra rubbish that won't even be read unless you're specifically looking for it like animation and 3D. The tEXt chunk is commonly used just to state author information.
The whole idea of these chunks is that you stick a label on your chunk, say how big it is and then dump your data after it. If whatever reads the png isn't interested in the chunk, it won't read it.
iOS mangling the chunks on a png is a possibility though apparently the tEXt chunk is supposed to be copy safe.
There's a png encoder library I've seen around:
Modifying that to poke in the tEXt chunk is a bugger, but probably doable. Getting it out again is basically looping through the bytes to find your own handiwork - and trying to load a png as a byte array. It's nearly Christmas, we'll see how bored I get.
I've verified it's still a png on my Mac. It's clunky, but it does the job.
What is the code for the image loading button in the Twine IDE? I know it's there in the source code but I don't know where to look. Just whatever is going to get me into the camera roll is enough - and then I can build a proof of concept.
Dropbox on mobile has the capability to provide you with public links to files.
I've just verified that you can create a web link to a file from the Dropbox app for iPhone (via "Copy link"). So for Dropbox at least, this would work for a mobile-only workflow.
A url load would be very helpful for iOS however (making it viable as a platform). And it would allow project sharing to take less steps on other platforms. You could probably end up with a nice package link to open Twine and load the archive.
Downloading a copy of a project is only one part of the issue related to project sharing, two other major parts are of course: 1. sharing your local changes and 2. synchronizing your changes with the changes done by others.