Apr 172014

In October we started on a new project for iOS. This is a much bigger project in scope than our prior mobile apps, so we wanted a better way to manage our development than what we had with Ansca’s Corona SDK. There are a number of choices available today, and a LOT of them are free and Open Source. Compare that to a closed source SDK like Corona and it was a no brainer that we would move to something else.

Yes, the Corona SDK is LUA based and therefore extensible (mostly by the community), but that doesn’t help you when you need to access a Native API that Ansca didn’t feel was important enough to provide with their SDK. The functionality that you get with Corona is pretty good for the price, but if you want to do more than what it provides you have to spend $3000 on their “Enterprise” solution and that model only works for large developers, not the indie crowd.

The Pros and Cons of using Cocos2d-x

On the plus side, Cocos2d-x is open source, c++ based, and pretty easy to learn. You can using nice development tools like Visual Studio and do most of your development on a PC and then deploy your builds from your Mac. Or, if you have a little extra time to figure it out, you can use Marmalade with Cocos2d-x and deploy your apps right from your PC. How cool is that? Cocos2d-x has online documentation, but that is both a pro and con. The class hierarchy is all laid out nicely.

On the negative side, Cocos2d-x is a framework. That means a lot of things like IAP and Social Network integration are left to the developer. There is a decent community for Cocos2d-x and sometimes people share their code, but forum questions don’t seem to be actively responded to. That is just my initial experience with the forums, so it may change as I take the time to help other developers and get some assistance in return. The negative part of the Cocos2d-x documentation is that the online Reference pretty much is nothing more than a class hierarchy. I really don’t understand this since the .h files all appear to use Doxygen style comments, so it would have been very easy to have that put into the online documentation. Instead, if you want to know what a class does, or how a method works, you have to go to the .h file and read what is there, and if that isn’t enough go to the cpp file and figure out what the method is doing.

Using Cocos2d-x

Despite my comment in the Cons section that Cocos2d-x is just a framework, it is a pretty nice framework. In my next blog I will discuss getting started with Cocos2d-x and show how to write a simple app.

 Posted by at 4:53 pm
Oct 132012

My apology for taking so long to complete this two part post. I’ve been consumed with a large mobile project for the past few months.

As you can probably guess from the title of the post, the new project was developed with something other than Corona. Before I talk about what we are using now for mobile development, I’d like to make a few final comments about Corona.

Due to the issues I mentioned in Part 1, and because we needed more control over features, integrating third-party SDK’s and shipping on time, we opted to switch to Cocos2d-x. More about that later; I’m just mentioning that to lead into my point about Corona. We had effectively stepped away from Corona a few months ago, but then a situation arose with our Nook builds.

Nook is about to release their new HD and HD+ devices and were asking developers to resubmit their apps for approval on those devices. Because we hadn’t touched our 4 stand-alone Nook apps in months, it meant that our only option to get the resubmitted in a short time frame was to use Corona; we hadn’t taken the time to port them over to Cocos2d-x [yet!]. So a quick build of the four apps and I resubmitted them to Nook. There wasn’t much else I could do since the hardware is’t yet released (November is the target street date).

About a day later I got an email from Nook letting me know that all 4 apps were rejected due to DRM. I was clueless what this meant since we don’t use any DRM other than what Nook adds to our apps. I got on the Nook Developer forum and posted a query about the reason for the rejection. Two days later and I still didn’t have a response on the forum other than another user mentioning that he was rejected for the same reason so I opened a support ticket.

It took a day, but I finally got a response from my support ticket saying to use the error code in the email. About the same time I received a new email from Nook elaborating on the reason for the DRM rejection. The only problem was, they just said “refer to the error table below” and the error code they gave me was still “DRM” which wasn’t in the error code table. *sigh*. A little after that I received a comment from Tom Chavez at Nook. He said something like “you wouldn’t be using Corona, would you?” He commented further that “…CoronaSDK is doing something at load time that isn’t allowed”.

About the same time I got that from Nook, I read Walter Luh’s post saying that build 925 would fix submission issues for Nook. I immediately downloaded CoronaSDK build 925, built my apps and resubmitted them. They were rejected again. Turns out that despite what the blog post said, you need CoronaSDK build 927 or later to pass submission. Sounds, like that would end my submission woes, right? Wrong.

My submission was rejected again due to “The user interface of your app is not appropriately scaled for the Nook family of devices and their displays”. Since I had no idea what they meant and the only change was moving to the new CoronaSDK, I (incorrectly) assumed it was another Corona issue. Since I couldn’t get any useful info from that rejection reason and Nook doesn’t allow you to just respond to the reviewer and ask a question, I resubmitted again and in the submission test notes I asked “can you please be specific what about the user interface is not scaled?” This got me a quick rejection, but with the additional info I needed.

It turns out that Nook is now VERY picky about apps using Letterbox. Except for some specific exceptions (video players, etc), you can no longer use letterbox with your apps and expect them to pass. Obviously this has nothing to do any bugs or problems with Corona, so I looked at my options for scaling and found a post on the CoronaLabs Forums by Joshua Quick saying that they had just found out letterbox based apps would be rejected and the ONLY acceptable mode would be zoomEven (in your config.lua file). A quick test using zoomEven showed how horrible a choice that was. Everything on the top and bottom of my landscape based app was cut off. Since there is where the HUD elements are, this was not an option.

As bad as it looks to change the aspect ratio, my only solution to let the user see all of the content and still pass Nook’s new UI standards, was to switch to zoomStretch. Seems like a trivial fix despite the odd aspect ratio, right? Not using Corona! Why? Because you cannot determine that it is a Nook based device. Sure you can use system.getInfo(“model”) and look for certain strings like “BNTV200”, “BNRV200”, “BNTV250”, “BNTV250a”, etc. that only works for the model codes people have figured out. Since the Nook HD and Nook HD+ are not yet released, there is no safe way to know the model string for those devices. This means you cannot easily add if/then/else statements for nook, ios, etc.

This shortcoming has been a problem for as long as I have been using Corona. I provided a SIMPLE solution for Ansca (I mean CoronaLabs) to solve this issue about 6 months ago, but still nothing. All they have to do is add a system.getInfo(“buildPlatform”) function and you would know you are building for iTunes, Nook, Amazon, or generic Android. Basically some way of knowing what market you were building for. This would have allowed all of this to be controlled from within my config.lua. Instead I had to find my own work-around to get around the limitations of Corona.

These types of problems (along with those mentioned in Part 1) are the main reasons that I have decided to move away from Corona. Of course when moving away from one thing, you have to move toward another. The criteria I used to choose a new engine was pretty straightforward. I needed

  • Cross-platform support for iOS, and Android
  • Able to use development tools on either Mac or Windows machines
  • Complete source code provided – Open Source preferred
  • Ability to integrate third-party SDK’s
  • Road map updated regularly
  • Full transparency on bug fixes
  • C++ preferred

I had heard great things about Cocos2d, but it was just for Mac/iOS. This meant it would be problematic to use it on a Windows machine. However, there was a C++ version of Cocos2d called Cocos2d-x. I found that it matched all of my requirements so we gave it a try on a much more ambitious project. Other than the initial learning curve, I have to say that Cocos2d-x was an awesome choice! We plan on converting all of our other apps to Cocos2d-x soon, and resubmitting them with some extra features we couldn’t get in using Corona.

I will write a number of posts about Cocos2d-x when I have time. Just as I had done with Corona, I plan on sharing what I have learned about Cocos2d-x so other people can leverage off of that. Hopefully other people will do the same and we can continue to build the Cocos2d/Cocos2d-x community.

P.S.: Like this article?! Want to support?! Be free to donate with bitcoins! 19r39vr2zs14aHW6DMNtPjmRga9xERQTTP