“Are you optimizing your coding style for Mobile devices?”
After a couple of days of coding we are starting to see a prototype App resembling the design work earlier in the week. Developing something as complicated as our Faces in just a couple of days is somewhat of a challenge and at all times we’ve been aware of the risk of biting off a little more than we can chew. I must admit that after our first day of coding we did wonder if we might have fallen into that trap. However, in the morning of our second day of coding we found our stride and managed to run a little more fluidly.
Our coding journey has not been as smooth as that of the design and we’d like to share a few thoughts on the barriers we hit and the eventual solutions. The biggest lesson has been this:
“Mobile development requires optimization from the start”
LiveCode is a wonderful tool for a number of reasons, my favorite being that I can just get on and build my App without having to think much about what it’s doing to the processor and system resources of the target machines. It’s very easy in LiveCode to drag on your images and controls and start scripting without thinking about whether your method is particularly efficient.
However, in the mobile world, the resources available are much more limited. Processor speeds are slower. Memory capacity is smaller. If a developer does not think carefully about the implementation, they can quickly find themselves with a sluggish app on their hands. And a slow app is a bad app. So it pays to be thinking about efficiency and optimization throughout the development process.
“Only draw what is needed”
This needn’t be taxing though. It’s mostly just common sense. Only render the controls that are needed. The more objects on the screen, the slower your app will be. Are all your background images and graphics needed? Can similar effects be achieved by setting the background color’s of your controls? Are there any objects you have created that are hidden away or no longer in use? Remember, all objects which are set to be visible will be drawn, even if they are masked behind others. If an object is not in use, hide it.
Minimize the number of effects in use. Are you needlessly antialiasing square edged objects? Are you using unnecessary graphic effects? Each effect applied to an object requires extra processing time to render, slowing down each redraw. Test to see if each effect used is needed or worth the trade off in speed. Can the effect be included in a background image? This will save the computation on each redraw.
Are you computing the same things multiple times? When you render a particular state, you shouldn’t need to do any re-computation until that state changes. And even then, you should try to limit the re-computation to the elements which have changed. Once you have calculated the position of an object and set it’s content, you don’t need to continually re-calculate. Are you repeatedly reading from a data source? Could the pertinent data be cached? Or do you even need to be polling this source continuously?
“Our mistakes”
Our listing of these tips is somewhat hypocritical though. We went eagerly from the design straight into coding, testing only in the iOS simulator. We didn’t think about efficiency or how best to implement our graphic rich design. We only realized we had issues when we first deployed to an iPhone. One of our scrolling lists was a little sluggish to say the least.
Luckily for us, we have a lot of expertise in the office. We quickly realized that we were antialiasing a few rectangles and drawing a bunch of unnecessary objects. We also had a large background image, much of which wasn’t ever being displayed – our scrolling group was overlaid directly on top of it. A few lines of code later and we had a nice group shaped hole cut out of our background image. Our scroller was flying along!
Hopefully us making these mistakes means that you don’t have to. And remember, only draw and compute what is needed and test regularly on the target device.
Overall Progress
We have all but finished the App. There are a number of things that still don’t work quite right and aspects of it we intend to improve. There is also a lot more to talk about here on the blog about the implementation details. We’d like to post the source stack to what we’ve done so far so you can see our progress. Check back over the next couple of days as we drill down into the implementation in more detail and polish the App a little more. You can download the App so far here. To play it, you’ll need a friend with an iOS device who also has a Facebook account. Both of you need to log into Facebook using the App and it will choose pictures, you can then both choose which one you want to be the “Criminal” and ask each other questions to track them down.
To build this App you’ll need to select your provisioning profile in Standalone Settings, then create a standalone App to deploy to your device (requires LiveCode for iOS and the Apple Developer Program).
