I would love to be able to access the front camera for still and video!

Perry

Spriter support!!!

Spriter recently completed a Kickstarter campaign where they raised $70k to work on a new release of their sprite animation tool, Spriter.

It's an open format for sprite animation, and still in the preliminary stages, but lots of frameworks already support it (you can see implementations at their Kickstarter and home page)

Someone in the community wrote a module to utilize Spriter animations but lost his work.

It would be great if Spriter was officially supported right out of the box.

At the very least, I hope that the current display object, sprite, and imagesheet APIs support all of the features described in the beta format in the works. I don't think it calls for 2.5d transformations or anything like that, so it should be alright.

Sites:

http://www.kickstarter.com/projects/539087245/spriter

http://brashmonkey.com/spriter.htm

Missing something from this roadmap...
I'd like to see which daily releases are on track to become stable releases.
Would prefer to deploy my app build from a stable sdk release, but some of the daily stuff is absolutely essential and awesome, so I'm taken to deploy a build from a daily sdk release anyway.

Some transparency into the great work you guys are doing there would be much appreciated!

Keep up the good work!

I would be happy with better support for the existent API. e.g. Support for android cameras isn't working with several devices such as Galaxy Tab 10.1

Corona Level Editor for MacOS + 1,000,000

While Corona is great for creating games, having access to Calendar and Contact APIs would make Corona an easier choice for business apps. Please add these APIs as soon as possible!

I think Ansca should focus heavily upon the webPopup and webView.

It wouldn't take much (a JS/web <-> Lua/Corona data exchange for active webpopup/views) to make Corona a great alternative to PhoneGap for native-ish UI's (using JQuery Mobile, Sencha, etc., on the HTML/JS/CSS side).

I've implemented a bit of a JS/web <-> Lua/Corona mechanism using a localhost server, but that's a clumsy way to have to do things, where Corona could provide a much slicker, more efficient, non-networking way to do it.

However, since webPopup's can't rotate, and webView's have serious problems with placement/rotation/dynamic resolution, these tools seem rather ragged and in poor shape to use as foundations for HTML5 apps (or portions of an app), at least for my purposes.

My next app is likely to have a fair bit of native-like UI in it for configuration, etc., so I'm (hesitantly) leaning towards using PhoneGap for it, as the HTML/web/webview support in Corona is just-not-quite-ready-for-production, IMO. :(

Similarly, the "widget" library is an interesting direction, but nothing you'd expose in a commercial app. I vote that Ansca redirect any effort put into the widget library, to instead having kick-ass support for webView's that actually work, can be placed where you want, and can communicate with Corona better. With this, you can use the mature and slick JQuery Mobile/Sencha/etc., for your widgets, rather than re-inventing the wheel.

It pains me every time I see a daily build with more and more support for storyboards (useful to some, I'm sure) when more fundamental and exciting features such as webView are incomplete and just plain broken.

(Try placing a webView consistently or predictably with a dynamically-scaled app; it's near impossible, especially with any rotation; I'd hack around it if I could figure out at all what Corona was *trying* to do with the placement, but so far, it is a mystery. Compare the webView placement with an equivalent newRect, using same coords, and you get very different results.)

I think Corona could go a long way to eating PhoneGap's lunch if only the webView's worked and had a gateway to the Lua/Corona side.

Just my $.02 (or $0.99 :))

-dale

I would like to know if there is any chance of seeing something like LuaSec supported this year. This is a key decision for us in continuing down the path of using Corona for our client-side development (and probably the only impediment to adoption).

+1 Calendar API access
+1 Address Book Syncing / merging

I would like some options on controlling where Corona looks for code and image assets. I'd prefer a layout like this:

1
2
3
4
5
6
7
8

root/
|- config.lua
|- code/
    |- main.lua
    |- level1.lua
|- assets/
   |- logo.png
   |- logo@2.png

So something in config.lua like:

1

dirs = { code = "code", assets = "assets" }

would be great.

In terms of packaging, it should be just the config.lua and the contents of the specified directories. If I want to have other files (such as Photoshop files, etc.) in the root of my project, those should be ok and Corona should just package up the subdirectories containing code and assets needed in the deployed application.

In terms of context; I have some cases where I want to programmatically generate some of my source files ... for example, to code using MoonScript (http://moonscript.org/) rather than straight Lua. It's much easier to organize such things if you can compile into a subdirectory and have Corona ignore everything else.

I can "simulate" this by having my true project (the one that gets checked into source code control) be the parent of the Corona project, but it would be nicer if there was simpler option.

Since the roadmap seems to be updated and support for secure sockets (TLS/SSL) for TCP or UDP is still not on the list should I assume it will never be supported in CoronaSDK? Support only HTTPS is not good enough.

The LuaSec library implements OpenSSL for Lua. Is there an issue with integrating this library?

Webview on Android +1

system.vibrate(durationMilliseconds) +1

DPI / Screen Size +1

Here is another great article on why most Android tablet apps suck:

http://www.pcmag.com/article2/0,2817,2401676,00.asp

Some choice quotes:

"And just because an app claims to run on tablets doesn't mean it was designed for tablets. Often, after you download an app you'll discover that it's ugly or nearly useless because it was designed for a 4-inch screen."

"The problem is that the Android apps are often formatted for phones. They'll work on tablets - barely - but they'll be ugly, with less functionality than their iPad counterparts. Items that could be pop-down menus or swipeable content require screen reloads. Little information is displayed per page, for instance, on the eBay app. Graphics sometimes appear low-resolution, distorted (as on the CBS Sports Football app), or are overlapped by ads. The number of clicks to do things increases dramatically."

You HAVE to know the screen size to make a tablet app that doesn't suck (at least for many kinds of app), and Corona doesn't let you find that out. Short a making a separate Android SKU for every form factor, there is no way to make a non-sucking Corona Android app in many of the popular platform-hero categories (as explored in the above article) that runs on phones and various sized tablets.

+100 for iTunes library support

I made a game specially for this and I am stuck now, as I did'nt know corona would not support it :(

+2.5d transforms

Webview on Android +1
system.getInfo("displaySize") +1

I put this in feature requests, but I'll post it here as well. It can't be that hard for the Ansca team to implement --> Kiip.me

App developers, net neutrality advocates and some customers have raised concern about the plan to charge additional for access to no-fee data, others have pointed out that this system is very similar to the way apps used to work. Data is a hard problem for wireless providers, and most have eradicated unlimited data plans. AT&T has released a plan that would charge application creators for the data that their consumers would be using. Article resource: AT&T unveils plan to charge for data usage.

OpenFeint for Android +1