As mobile developers, chances are that none of us are too good at sports. Sure, we might be fans, but when it comes to throwing the long ball or executing a 360º slam dunk. But what we may lack in calf muscles we make up for in brain power, and now we can put it to great use playing our latest App of the Week — the hoop-shooting puzzle game MixZle. Yes, with MixZle, you can make stadiums full of crowds roar as you dazzlingly slam a basketball through a hoop — well, not really. Actually, it’s a nifty, physics-based mosaic puzzle game that will massage your brain in order to put the ball into the net. Each of the 100+ levels presents you with a
Functions in Lua are an integral part of any Corona script, with one of the primary benefits being the ability to run an entire block of code just by simply calling the function. This usefulness really shines when the function needs to be called several different times throughout runtime. But what happens if you need to use the same functions across multiple modules? For instance, if you have many different levels, should you really have to write (or copy/paste) the code for creating the main character, drawing the score display, pause buttons, etc. (things common to all levels) over and over again? Of course not.
There has been a lot of material presented over the last four parts. In this final part, we will finally go into some detail about our automated testing system for Android. We will also finally get an opportunity to bring everything together by looking a little more how our shell scripts orchestrate the test run and connect components from the previous parts. Android was a lot easier to setup automated on-device tests than iOS because the entire toolchain is command line driven. But ironically, actually running the tests has been more unreliable for us, mostly due to some bug related to adb. For some reason we can’t explain, adb will hang on us and it will not allow us to communicate with our device. This has
We allow Corona developers to also build for the Xcode iOS Simulator. Sometimes the simulator is preferable to our Mac or Windows simulator because the Xcode Simulator behaves more like a real device. Since we officially support the Xcode Simulator, we run our automated tests on the Xcode iOS Simulator to help verify our stuff actually works. While we could theoretically reuse the same process of scripting Xcode that we described in Part 2, we opted for a slightly different approach. As described in Part 2, Xcode 4 broke everything so we didn’t want to put this in the same critical path. Furthermore, Xcode 4 has some very nice speed improvements and reduces our build times to almost half. So instead, we simply use the command
Phew! We did it. Thanks to all of you, we had a great and smooth release. The most ambitious release to date of our Corona SDK went without a hitch last week. We got the bits out the door almost perfect — yes, there were some quirks but nothing that would have caused us to recall and stop the release altogether. We are getting there slowly but surely and, with your support and feedback, we have been able to address and fix some last-minute issues that crept up. I would like to thank the team at inMobi for providing a hotline for our users and for being on top of the forums the day of release and the days after. The team showed up at
As stated in Part 1, we use lua-TestMore for our testing and reporting. The output format is called TAP (Test Anything Protocol) . It is human readable and simple. TestMore and TAP are widely used enough that there are tools available to help you use it.
Our latest App of the Week is the classically designed Dabble word game. Dabble was invented as a board game by 84-year-old George Weiss of Brooklyn. It was then picked up and brought to store shelves by the ironically named Ideas Never Implemented, and finally was brought to the iPhone (and soon to be iPad!) by indie developers Flashy Substance and Itch.com using our very own Corona SDK! Below, Joe Flowers of Flashy Substance talks about how he decided to use Corona to bring Mr. Weiss’ dream to the mobile platform. Afterward, you can hear some thoughts directly from Mr. Weiss about the game itself. We’d been developing online games for years, and for several months we had been exploring using either Flash or native Objective-C to
Now that you’ve seen the overview of the whole system, I’m going to talk about on-device testing on iOS first because this has been where we have endured the most pain.
Fresh off last week’s Corona LaunchPad announcement, we now wanna put it to the test! We’ve teamed up with our new partners, InMobi and PapayaMobile, to throw the first-ever Corona SDK hackathon on Saturday, August 27 in San Francisco. The event will be an all-day affair with breakfast, lunch, dinner, and — of course — hacking! At the end of the night, we’ll have judges from Ansca (i.e. Walter and Carlos) and InMobi choose the winners. And speaking of winners, you’ll probably love the prizes we have on deck: First Place: $2500 + Corona SDK PRO subscription Second Place: $750 + Corona SDK PRO subscription 2 Honorable Mentions: $250 each team + Corona SDK PRO subscription The best part? You don’t have to be near San
Preamble: This post is going to be a little different than usual. What we present here is behind the scenes stuff used in making the Corona SDK. But we hope the information presented here goes beyond satisfying simple academic curiosity. We hope this information will actually be useful for others to directly use in their own projects. And the target audience for this post goes beyond our normal demographic. In addition to Corona developers, we are also reaching out to all Xcode/iOS/Mac developers, all Android developers, all Lua developers, and anybody interested in automated testing/software reliability. Also, as a consequence of our solution, people interested in Applescript, Scripting Bridge, and/or LuaCocoa may also find things of interest. Because the topic is vast, not every single