Not so long ago, I posted a tutorial about how to program Corona apps more modularly, to make organizing and maintaining your code a much easier task. Today, I’m going to tackle modular coding from a slightly different approach, and suggest a new technique that might actually help improve performance and squash memory-leak bugs you may be experiencing.
Category: Tutorials, Tips and Demos
On the surface, you’d think the only use-case for a web popup within an app would be to display an embedded website without your user having to leave your app. While that’s true, with a little creativity there are plenty of other things web popups could be used for. If not, that’s fine too. In this blog post, we’ll explore some of the various things you can do with web popups, as well as how you can integrate them into your app to do lots of cool things. As they say, the more tools you have in your toolbox, the easier it will be to find a solution to your problem in the future.
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
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.
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.
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
As you already know, Corona includes the powerful Box2D physics engine to give your games the ultimate sense of depth by providing a high-quality, realistic physics simulation — all without you having to know much more than just the “common sense” aspects of physics. Generally, if you know that gravity makes things fall, and understand that heavier objects travel slower than lighter objects when an equal amount of force is applied, then your knowledge of physics is sufficient enough to make a great physics-based game using Corona. Piece of cake right? However, because there are several properties that affect how things behave—things we never really have to think about in the real world—sometimes your in-game physics don’t always behave exactly how you expect them to,
This week, I’m going to cover a web technology that has been dubbed “the fat-free alternative to XML” — JSON. While XML is great, there are a few problems with it… Because XML tags on the same level can have the same name, accessing XML data from Corona can get to be really confusing if you don’t pre-localize all the children in each level of the node hierarchy with your own naming convention (very confusing). It’s really only useful if you need to read-in data from an XML file. If you need to package up data into an XML file from your Corona app, you’re in for a rough ride. Thankfully, using JSON in a Corona app is a lot more practical and the functions are integrated