I’ve thought about posting this a lot. I just didn’t want to get on TLL’s nerves, so @Simeon thinks this is not a good thing to share, do not hesitate to take this down. For those beginners, file IO is basiccly the power to read and write other projects. As I me filmed in the title, it also enables other things listed below:
Hook up your iPad to your computer and open iExplorer.
Navigate to “LuaSandbox.lua”. Open it up with any text editor (preferably TextEdit on a Mac and I don’t know what’s best for windows).
Blow away all that text inside it. Then save it.
Restart Codea. Done.
Some of you may ask “Why not just blow the file away itself?”. Because I did that and Codea wouldn’t run any projects. If you look at the file, it says things like “load=nil”. That makes it so the function has no value. The programs automatiacally use “require (“LuaSandbox.lua”)” in the program, but it isn’t shown. Now how do you use file IO? Thanks to @ruilov, I have a little chunk of code:
function setup()
ret = os.getenv("HOME")
projectName = "Fileio"
file = ret.."/Documents/"..projectName..".codea/Main.lua"
for line in io.lines(file) do
print(line)
end
end
I’m learning file IO and how Codea handles it, so Im making some of my own code.
Have fun!
function setup()
ret=os.getenv("HOME")
io.output(ret.."/Documents/Test.codea/out")
io.write("testout")
end
The file ‘out’ gets created but remains zero size.
I also tried moving the io.write into draw() in case it was buffered io or similar. This had no effect.
Anybody know what’s wrong?
NB: If this can be made to work, Codea ‘cleans’ files out of the project directory regularly (every time you return to the project menu?), so extraneous files like my ‘out’ file will get deleted then. A bit of a gotcha if output can be made useful.
Create a simple animation app where the user animates a wireframe object, and can then save the animation to another machine permanently. This animation could then be used in games and other apps.
Record the full set of player input, save it, and incorporate it into the game so that it can be replayed as a demo.
You can do number 2 with the saveProjectData / readProjectData functions. These save key-value pairs to a file located in the project’s directory.
You could even do the same for number 1. You just have to get the Data.plist file out of the project directory. And if you are using iExplorer you can do that the same way you get other files out.
@Dylan said “Also note that any projects you make from this are much harder to share.”
That’s ok - Apple has already made it plenty hard to share.
It could be argued that them forcing the removal of .codea import/export directly contributes to the urge/need to hack Codea - the detriment of “Well, if you do that you won’t be able to share your projects” has certainly been removed.
I might write a project encoder/decoder for those who choose to go this way. My idea is that the project encoder creates a gibrish, but short string, that represents the entire project. To download a project, copy that string into a tab in your decoder codea project, run it and it will offer two options: (1) run it, (2) create an actual project with the decoded code/projectData
Does that sound useful?
Might be completely impossible. For example I haven’t found out how to list files in a directory. But if works, I think it will make life easier.
@Bortels it’s more that you can’t just paste code that others can run. People are still sharing code - despite the fact that we’ve gone back to more primitive methods.
Sorry @Zoyt , but isn’t there a risk that by exploring these avenues you end up using Codea in a way Apple might not approve of, resulting in the removal altogether? Or is Apple only looking at apps during the approval process you think? If that were the case, then @TTL could block project export in the app (and other things Apple doesn’t like) with a simple mechanism that we can remove easily with iExplorer!
techBASIC seems to have a general file io mechanism into the app sandbox, as with standard Basic interpreters. Shouldn’t this be possible for Codea as well?
@alvelda yes it’s possible. The reason it’s not in there is because it’s not as clean as we would like. For example, code like this (@Martin posted it above):
function setup()
ret=os.getenv("HOME")
io.output(ret.."/Documents/Test.codea/out")
io.write("testout")
end
Is just not friendly and presumes knowledge about the file-system layout. We want a solution that is project oriented (files in the project), as well as a device oriented (files on the local device). And we want the API to be consistent and clean across platforms.
I’m still deciding whether to override Lua’s io.* functions or generalise Codea’s storage APIs.
@Simeon - the key word is “harder”. Certainly code sharing isn’t impossible. What Apple has done is simply force the process to methods outside of their direct control.
I don’t jailbreak for fun - I’d rather not at all. I jailbreak because if I don’t, I can’t use the iPad in perfectly reasonable ways (I like to use rsync to copy things to/from it wirelessly rather than cut and paste multiple tabs, call me nutty). By making it hard or impossible to do what I want to do - they didn’t stop me from doing it, they simply removed any control over that process from their hands.
That’s the way DRM works - it punishes legitimate users, and does nothing to stop the undesired behavior. If I want to share a codea project with another jailbroken user, it’s easy - zip up the directory, send it to them, and they unzip it. It could easily be automated, as well.
I’m half-tempted to write something that scrapes the common code-sharing sites for code (gist, github, and the like), creates a project directory, and rsyncs it over to my ipad, for anyone to use. Hmm. I wonder if Codea looks at the directory, or has a plist to manage projects? I’ll poke it later.
