Codea 1.4 is alive

Go to apple store

Thank you. I like the way to look up and create a project.
However, I tried to look up projects and then click the new Image IO sample. The Codea is closed unintentionally. This is weird.

Hi @sanit. That sounds like a bug. I’ll be ready to submit an update tomorrow to fix it. Thank you for your report.

I had a few random crashes with the new version. Clicking on the TLL logo in the lower right hand corner crashed the first two times I did it. Opening “Community and Help” crashed the first time (but not after)


@toadkick Ditto! Thank @simeon, et al. It is a very nice new version.

@JockM 1.4.1 should be submitted soon which will include code searching and a fix for that crash bug.

Glad you like it!

@simeon Awesome. Great job. LOVE the new movement and selection system.

Just got the update. I also LOVE the cursor control buttons! I wish it’s also available on the Apple’s standard on-screen keyboard. I like the new network API, though feel like a bit incomplete (just http.get?) and unfinish (?).

A minor complain from me is consistent API naming convention. Please use common pair names. For example: set - get, open - close, load - save, push - pop, read - write, etc. Don’t mix one with the other, it’s confusing. For example: Codea got readImage() and saveImage(). I think they should be readImage() and writeImage(); or loadImage() and saveImage().

And perhaps this is a bug with the new update. Codea is always asking my AppleID and password EVERYTIME I open Codea. I think it’s correlated with the in-app purchase bug. FYI, I disabled in-app purchase by default because my iPad is mostly used by my kids. :wink:

Oh, one more thing… I thought @simeon promised a find-and-replace in this update. No? :slight_smile:

Thank you for the great update!
Is there a way to create subfolders into the Documents folder?

Hi, great update! dropbox support for custom sprite is really a welcome.
I just found it a bit unstable, it happens very often it crahses when switching between projects. does anybody alse has the same problem?

@shrike sorry about that bug - it snuck in to 1.4 and occurs when you open projects. We will be submitting a 1.4.1 update that fixes it.

@bee 1.4.1 will have find. We will work on replace after that. What would you like to see in addition to http.get? It can take any sort of request.

@MdMbunny Dropbox support is a bit simple at the moment. We are considering folders, bu for now it lives in the one app folder.

@Simeon oki, thank you :slight_smile:

@simeon: It’s called ‘network’ API, not ‘http’ API. So, I expect more network protocols rather than just http. When I first heard the ‘network’ word, I thought it would come with at least http and raw socket APIs. But, I think the current http.get() is enough for common internet data exchange, especially with the 4th parameter. :slight_smile:

I don’t understand why you put them all in a single http.get() function and provide advance feature as the 4th parameter. Why don’t you just provide http.get(), http.put(),, etc functions? AFAIK, ‘get’ is a method of http protocol, as well as ‘put’, ‘post’, etc. It’s quite uncommon API to my opinion. Any reasons for that?

Oh, about the bug, forget it. I restarted my iPad and the problem just gone. :slight_smile:

So online game’s /app’s? [-O<

@connorbot999: I think it’s more important to first think about a code uploader/downloader. So, we don’t need to bother with the annoying copy and paste operation for code sharing. I believe someone would make one, sooner or later. :smiley:

@bee - raw socket API was originally shot down by apple. So, it’s this, or bupkis. (I suspect anything that lets you accept() on a socket, and thereby would let you write a proxy/tethering app, is gonna get shot down)

Doesn’t matter - this is in many ways better than raw socket. I did raw sockets in the beta long ago - the codea draw() main loop is very unfriendly to blocking APIs like the standard socket stuff.

I’ll post some code in another thread.

As for a code uploaded/downloaded - two issues. First, no file I/O, so you’d need to save to global storage (and write your own editor). Second - sounds like a good way to convince apple to yank http.get(). If you don’t like cut and paste (and I’m there with you), jailbreak, or use an app like iExplorer. The fact is, without TLL and apple support, any “dynamic code loader” is going to suck nearly as much as cut and paste.

I can’t see cut/paste being the rule forever - its just dumb. Eventually apple will realize that.

@bortels: Well, I didn’t know Apple rejected the raw socket API. I thought it should have been accepted since the feature is called ‘network’ instead of ‘http’ API. If direct file i/o API is prohibited or would cause app rejection, TLL could provide clipboard i/o API. So, we could download a code (programmatically), copy it to clipboard (programmatically), create a new file (manually), then paste the code into it (manually). To upload a code, copy a text/file to clipboard (manually), upload the code from clipboard to a URL (programmatically). Yes, it’s still cumbersome, but it reduces some keystrokes (less URL typing and annoying manual text selection on safari) and provide more convinience (no need to switch to safari back and forth).

Oh, feel free to delete this post if it would -somehow- alert Apple. :slight_smile:

Apple also forbids direct clipboard manipulation - its been suggested. It could be easily abused.

I think the current cunning plan is to have pragmas that would allow you to do multiple tabs as a single cut and paste. Still ugly, but at least it’s just one.

I have hope that as codea and native development become more common, apple will realize they’re being unreasonable, and we can just get .codea files back. They worked well.