Corona SDK review

CoronaSDK-icon
Two weeks ago I went to Corona SDK Hack Night in Menlo Park. When I went in (8PM sharp) I saw that everybody were already sitting with their laptops turned on, working. “I see that I’m late” I said out loud while unpacking my laptop bag, and got a few hostile looks, it was weird… And then it clicked, these people were not part of the Corona lab group – these were just different groups of students that came, as any other day, to use the free wifi @ Happy Donuts…

I blushed… feeling like a weirdo… but after a second I saw that everyone got their heads back in their laptops so I grabbed a cup of coffee and waited till someone else shows up (at least I wasn’t late…).

Actually, the story starts about a year ago, when I first decided to write an Android app, it was pretty cool: I downloaded and installed Android SDK and the required Eclipse plugin, skipped most of the tutorials and just “went for it”. A few months later I had my app and it was pretty cool, it was provided with song-names from a server that I ran on rackspace and buttons like: “watch on youtube”, “share on facebook” and “buy on amazon” and some other stuff. All the buttons just triggered REST-API calls to the server which implemented all the logic on the backend. It actually worked fine on the simulator and on my HTC Aria, but when tested on higher versions of Android it failed, and it took me a while to figure out why. I found out that from Gingerbread and on – only non-synchronized HTTP calls were supported.

A few months ago, my wife came up with an idea for another app and I promised her that I’ll build it. Then I heard about Corona – so I decided to give it a fair chance. Alas, we started with the wrong foot: A very kind guy named Jerry Pierre helped me by instructing me to download and install Corona SDK first, and then Lua Glider (IDE). I’m a bit ashamed to admit, but the laptop I’m (rarely) using has Vista installed and since the computer is not mine – I can’t install Win7. At home, and at work, I use desktops, and in general – I prefer desktops (yes, I know it’s weird – but I don’t like laptops…).

It seems that Lua work well on Win7 as well as on Mac, but on Vista it took me an hour of fighting until I gave up and opened Notepad++. So after a couple of hours, and a very nice walk-through I got from Mayank Malik – I decided to wrap it up, go back home, and use my desktop to continue “playing” with Corona.

lua

The good:
Someone put a lot of effort in creating this abstracted development environment which compile your code into native code of one of the following operating systems: iOS, Android, Kindle Fire and NOOK – which is very cool. Further, Corona arrives with a respectable built-in library that supports media (video/audio/images) but even more impressive is the physics library which allows you to easily add a gravity to your objects, an example for a way to use it will be the following simple and straight-forward implementation:

local function onTilt( event )
physics.setGravity( 10 * event.xGravity, -10 * event.yGravity )
end

The bad:
* New syntax
* limited functionality
* Can’t combine your own native code with Corona’s
* Once you started using it – you’re tied to it, you won’t be able to migrate to another platform. Ever.

The Ugly:
* The price:
– $199/year for the “indi” version – a license to publish in one of the two: iOS or Android.
– $349 to get the “pro” version – the option to build your app in all the supported platforms.

coronaicon

Now seriously, this price is good if you plan to monetize your apps, but when you just build things for fun, then it’s a bit pricey. If I was planning to develop a game that would use the fancy physics library – I might have chosen Corona, but since I don’t (and also since I don’t appreciate the “closed garden” policy) – I decided to pass.

Update: I just found out that Mayank helped organizing Grinding the rails with Ishan Singh – and since I was planning to learn Ruby anyways, I might just show up there 😉

corona_product_teaser

Corona SDK review

I see dead code (homage for IntelliJ Idea)

intellij-624x120

About a month ago I went with my friend David to Silicon Valley CodeCamp. David met a few friends so we all set together and had lunch during which we discussed a few coding issues but we were also excited about the raffle which was to take place right after lunch. I told them that I’m not interested in the XBOX (which was considered as the best prize) and that what I would really LOVE is to get a license for intelliJ. First time I “met” intelliJ was

Back to our lunch at Silicon Valley CodeCamp. People were hoping to win the XBOX and I told them that I don’t care about the XBOX and that I wish they would throw in intelliJ licenses (one license worth $500). We finished our lunches and went to the main court where the raffle took place, and to my astonishment, the guy with the mic announced the list of prizes and among them, one intelliJ license. I was stunned. David laughed and said: “I’m going to win this one for you”.

And believe it or not – he did!

intellij_idea

A few days later, I’m sitting at my desk, installing the newest version of intelliJ, and it took me only a few seconds to see what I was missing so much…

Jetbrains, the company that made intelliJ had a booth there in SVCC – so I got myself a shirt that says: “I see dead code”. And now I really do: among many other cool features, intelliJ finds unused parameters and colors them in grey. This simple feature is priceless (and I’m not familiar with any equivalent feature in Netbeans/Eclipse).

iseedeadcode

The shirt I got at SVCC

So, at that same first day when I started using intelliJ again, I went over some code, looking for something, and then I run into the following method (two points to the readers that find what’s wrong with this method):

  private String getContractName(Connection conn, int contractOrderId) {

    String methodName = "getContractName";
    PreparedStatement st = null;
    ResultSet rs = null;
    String contractName = null;
    try {
      //get contract name
      String sqlQuery = "SELECT CONTRACT_NAME FROM __CONTRACTS WHERE contract_order_id=?";
      st.setInt(1, contractOrderId);
      rs = st.executeQuery();

      if (rs.next()) {
        contractName = rs.getString("CONTRACT_NAME");
      }
    }
    catch (Exception e) {
      Utils.writeLog(className + ":" + methodName +"- Warning: " + className + ":" + methodName + "-" + e.getMessage(), DEBUG);
    }
    finally {
      Utils.closeConnections(null, st, rs, null);
    }
    return contractName;
  }

Without intelliJ it’s not easy to see it, but if you figured it out – way to go!
Between the following two lines:

String sqlQuery = "SELECT CONTRACT_NAME FROM __CONTRACTS WHERE contract_order_id=?";
st.setInt(1, contractOrderId);

there’s one “little” line missing:

st = conn.prepareStatement(sqlQuery);

This could be easily detected with intelliJ since “Connection conn” passed in the method’s signature was marked grey. Actually, there isn’t only one wrong thing with this method, now that we understand the problem, we can also see that every time this method is being called, an exception is being thrown on:

st.setInt(1, contractOrderId);

and that this exception is caught six lines below – but the only thing that is being done is a “debug” printing to log (not even an error!) and then the method ALWAYS returns null and continues.

How many bad practices do we see here – can you count ?

1. we don’t “fail-fast” (the method should have either thrown an error or at least print ERROR to log instead of DEBUG).
2. we throw and catch an exception (which is costly!) without really handling it.
3. we return a default value which is meaningless
4. I’m 100% sure that no unit-tests, functionality tests, regression, end-to-end or any kind of tests were written and used here – otherwise this bug would have been easily caught.

So here’s a call to all you decision makers, think about the hours of debugging, fixing, reviewing the code-fix, QAing the fix and deploying – that could be saved, not to mention potential damage that could be done to your company and your clients. Always consider purchasing the best tools you can for your engineers. It might look like an “expensive investment” but it’ll pay off, trust me (and if you can’t trust me, you should believe Joel. Check-out item #9 on his list).

I see dead code (homage for IntelliJ Idea)