I’ve be4n seeing some odd interactions between codea and working copy, and wanted to try keeping programs in working copy’s folder rather than codea.
when i do that, codea unit crashes, because it’s trying to read the project tabs, with this message:
CodeaUnit:136: Project "documents:tttt" not found
stack traceback:
[C]: in function 'readProjectTab'
CodeaUnit:136: in field 'execute'
Main:47: in function 'runCodeaUnitTests'
Main:7: in function 'setup'
Is this a bug, or to be expected when you’re not inside the codea nest? is there a workaround?
@RonJeffries When you run a Codea program from the Files app and it doesn’t take you to the Codea app to run it, then I think that it can’t find the other tabs. That sounds like a normal error message. I would get similar error messages when I run a Codea project not in the Codea app.
@RonJeffriesreadProjectTab only works on local projects (at the moment). So if the project is located outside of the “On My iPad → Codea” folder, those methods will not work
It would be nice if these were just file paths. But on iOS these other locations must be accessed via security-scoped URLs and resolved asynchronously via bookmarks the user creates
When opening an external location in Codea, iOS will expand Codea’s sandbox to include the single extra URL (e.g., file path) chosen by the user. Codea can then store that URL as a “bookmark” and access it by requesting security scoped access prior to attempting any file system operations. It then needs to relinquish the access or the operating system will ban the application from accessing the resource in the future
It is also necessary to access the external URLs via file coordination, which means they must be accessed asynchronously — this allows the operating system to notify any other applications accessing the same URL (so they can save pending changes, etc). But this also means we would need to modify readProjectTab to either block while waiting for access, or return its data in a callback
In your case, it looks like the missing project is “documents:tttt”. This would need to be located in “On My iPad → Codea” (that’s “documents” in Codea)
API-wise I’m not exactly sure where to go. We could expose all external projects (only once the user opens them) via the asset system. So something like asset.external.MyProjectThatIEditedInFilesApp
Also, finally, note that readProjectTab and saveProjectTab are kind of unnecessary with the asset API and we should probably unify things
You can use readText and saveText to read and write directly into other projects (e.g., readText(asset.documents.MyProject.Main)). When we add external locations to the asset API, the idea would be that these functions just work with external locations
@Simeon@RonJeffries I took a simple project that reads a project tab and copied it from my Files “On my iPad->Codea” folder and put it in the Files “iCloud” folder. I ran the project from there and it was able to read the project tab. When I tapped the project, it took me to the Codea editor where I could see the Main and the other tab just as if I started from Codea. If I exported a zipped version to the Files “iCloud” folder, then I would get the error message for readProjectTab.
@dave1707 reading from the current project should be OK. But if you attempt to read from another project in a cloud or other external location you will probably run into issues (no way to reference it at this time)
I would recommend readText and saveText over the *ProjectTab equivalents
Perhaps the issue with CodeaUnit is that it’s running as a dependency? Anyway, no biggie, I prefer the projects inside Codea anyway, but Anders thought Working Copy might be more reliable with projects in its folder. Too much of a pain to work that way, IMO.
@Simeon - I actually find the Apple system messy and a little inconsistent. The Codea system took a little while to get used to it but I am now familiar with it. A little improvement in Codea file management (internally) would be a good step forward - like the addition to the selected project menu to add/move/delete projects to collections. Also to make collections assets.
Your own idea to make project internal files accessible in a window sounds like a good idea. I like resources/files accessible in global scope whilst developing and in local scope when the project is finished.
@RonJeffries is it too much of a pain because those projects don’t show in the main Codea browser and you have to keep going back to the files app to open them?
@RonJeffries just thinking there might be an easy way to show recently opened external files in the project browser list, perhaps with a little “external” tag to indicate they are not in the local documents folder (you couldn’t rename them, or delete them, but you could delete the “bookmark” to them)