Posted on by

A few months ago, I talked about networking 2.0, but what I didn’t mention was that the driving force behind these improvements was the Corona community’s own Bob Dickinson.

For awhile, Bob was pretty vocal about some of the shortcomings of the old network 1.0 stack, and made that clear in his bug reports where he expressed his frustration. He’d say things that were brutal like “Network request/download support is only suitable for toy apps,” but balance those comments with constructive thoughts about improvements he’d like to see.

Over an e-mail exchange, it turns out that Bob really wanted to make something happen:

What I would like to do is volunteer to rework the Corona networking APIs (specifically network.request and network.download) in order to both address the specific open bugs, and also to extend the APIs and make them more robust, as outlined in 14023. I think that this can be done without changing the API definitions (so the new implementations would be fully backward compatible and pass any current unit tests).

So after several conversations, we agreed to give it a go! One of my primary concerns was the API, and Bob was (thankfully) patient as I poured over every detail of the API changes. We’ve had several dozens of exchanges just on the API. We covered a bunch of things including error handling, distinguishing between text/binary in responses, and minutiae like how download file paths should be specified.

Here’s a typical example of the kind of exchange we had. In this one, we decided on the name for a new API to cancel http requests:

I went back and forth. I picked cancelRequest( ) because, unlike the
timer module, the network module has a couple of methods that deal
with things that you might think are cancelable and that are not
requests (the network status functions). But I’m fine either way.

I have slight preference for the more succinct “network.cancel()”, so let’s go with that.

Then came development. Bob rewrote the Android implementation because a newer HttpURLConnection had become available since the time at which we wrote the original. He then ported over our existing iOS, Mac, and Windows implementations.

Given the number of platforms involved, it was definitely a significant undertaking and a Herculean effort by Bob. I could go on about all the technical details but long story short, we all have a richer set of http APIs.

Thanks Bob for all your hard work, generosity, and dedication. Corona is that much better for it!


Posted by . Thanks for reading...

15 Responses to “The one about how networking 2.0 happened”

  1. Bob Dickinson

    Thanks for the kudos Walter. It was a fun and challenging project – the hardest part being switching between C++ and Objective C (Mac/iOS), Java (Android), C (Windows), lua (test suite) and Python (test server), often writing in all languages and platforms in a single day. It gave me a lot of respect for the kind of challenges that your team faces on an ongoing basis and the skill and focus required to do this kind of development as well as your team does it. I hope everyone enjoys Networking 2.0!

    Reply
  2. IcySpark

    Thank you Bob for putting your time and effort into this. A very selfless thing to do that benefits the whole Corona community.

    Reply
  3. Matthew Webster

    Wow, Bob, you are a hero, true and proper. Well done, congratulations and a massive thank you.

    I have so much respect and admiration for anyone who can master those languages – and you’ve done it all and put network guru in there as well!

    Reply
  4. Kerem

    Bob, you are a hero indeed. Thank you very much for all you have done for the community. We are much indebted to you.

    Reply
  5. WideAwakeGames

    I assume Bob wasn’t interested in working for CL? If I found someone with the talent AND dedication shown here, there’d be a solid offer on the table.

    Reply
  6. Raffaele

    Great work Bob and thanks.
    But I’m the only one who thinks is at least strage that an SDK for which I payed licenses relay on volunteers work to get such a core API as network bugfixed and up-to-date? How could we releay on corona for mission critical apps?
    Don’t get me wrong, maybe if Bob could choose at the beginning the native way he saved a lot of mails, frustration and time.

    Reply
  7. JCH_APPLE

    Raffaele has a very pertinent point of view, it seems like important improvements were made by people not working for Coronalabs (my personal hero is Matt/Horacebury, every time I have a problem or a question he has found the solution before).
    I hope these people at least don’t have to pay their subscription :o)
    Congrats to everybody, Corona people’s efforts are great nut please encourage top level contributors, without them Coronalabs wouldn’t be what it is now.

    Reply
  8. Bob Dickinson

    I did struggle with the idea of contributing free code/work to a for-profit company. But the rationale for my volunteering to do this work was basically that if this was an open source effort, I would just go fix the code (and clearly, I wouldn’t be paid for that). I would do it mostly because I wanted it done for my own reasons, and secondarily for learning experience and a little ego boost from the community. So I thought, if I would be willing to do this for an open source effort, why wouldn’t I do this for a closed source project (where I like the project, the company, the people, etc). Sure, they’re doing this for profit, but what difference does that really make in the end? Should they be paying for this work because they’re for-profit? Maybe. But they weren’t going to, and I wanted it done, so I just stepped up and did it just like I would have done it on an open source project. And I got what I wanted. The network APIs (that I use) are solid, the company and the community gave me their thanks, and I learned a lot in the process (and, FWIW, I don’t have to pay for my Corona License for a while). So I admit that it’s a little weird, but it worked for me.

    Reply

Leave a Reply

  • (Will Not Be Published)