A Tale of Two Ports: A Picard vs Kirk review of mobile app porting techniques

An app prepared for porting

The Smiles port is very interesting because it lays out what I think is a key challenge and opportunity for app developers. Mike’s approach was to rewrite his iPhone* app in C++ using Visual Studio. Although that may sound painful, Mike had written most of his code in C++ to start with, and he had the foresight to establish his own core set of custom libraries and assets to create his unique game experience. Also, Mike developed his game using a cross-platform open graphics API (OpenGL), allowing much of his work to be reusable in either platform.

Mike’s relative ease in porting was mostly due to preparation and work he did up-front to build and use cross-platform language, APIs, and his own custom

“What will my application be like on the netbook?”I had the pleasure last month to collaborate with two accomplished developers on their methods for porting iPhone* games to AppUpSM for netbooks running Windows*. I was very impressed by the creativity and ingenuity of these ports while at the same time it appears they follow some common practices to ensure a quality experience on a netbook. While very different these porting methods are both viable and I believe represent the most likely scenarios for porting a mobile app to AppUpSM.

Mike Kasprzak from Sykhronics took what I would consider a more conventional port of his game “Smiles” with a basic rewriting while leveraging standards and his own custom libraries & assets. Read our Q&A with Mike for details on his port.

The other approach is explained by Chris Skaggs of Soma Games, which is a more rapid porting approach of his game “G:Into the Rain.” Soma Games exported their code to a cross-platform framework and C++ wrapper. Read our Q&A with Chris for details on his port.

It struck me that these two approaches were very different yet both effective. One bold and one deliberate, yet both finding a common formula for success. And because everything can be explained through Star Trek characters, I see one one as Kirk and one as Picard.

libraries and assets that he could leverage in the port. Thus he was not burdened by having to determine how to rewrite or find a comparable solution to Apple*-specific libraries.

This situation is a likely scenario for game porting. Games have custom UI’s, custom menus, and buttons, whereas productivity or information apps will more often rely on platform specific libraries for menus, lists, buttons, and navigation. For games, this is either a curse or blessing depending on how you look at it. In Mike’s case, his choices led to an easier porting path, but in the end it required more custom work up front. This is something to consider if you hope to get that application to multiple devices and platforms. Consider what your path might

Mike: I structure my project manually so I can mix and match Xcode* projects, Visual Studio* projects, and makefiles together in one common layout. It takes some planning and homework to do this right, but it’s far better than copying files around manually. My makefile setup is custom, and automatically detects all files in my project. But for both Xcode and Visual Studio, I manually build a project by dragging all my source files in (directories at a time).

Intel® Atom™ Developer Program Part of the Intel® Software Network

Originally published as a blog by Bob Duffy at :http://appdeveloper.intel.com/en-us/blog/2010/04/26/tale-two-ports-picard-vs-kirk-review-mobile-app-porting-techniques

beta

be away from platform-specific libraries or doing some up front work to build your own, as Mike did. If you haven’t already figured it out, I’m comparing to Jean-Luc Picard and how he prepares for a mission. His success was due to early and deliberate planning, making each next step easier because of each informed decision and action.

Or just change the rules Chris had a unique situation. He did not have time to do a conventional port and recode the whole application. He also was not in the situation Mike had set up, which made porting relatively simple. So Chris took the Captain Kirk approach. He didn’t cheat, he just changed the rules. Out of time to recode, Chris found he could export Objective-C to Adobe Flex relatively easily and it retained all of his library calls. So rewriting wasn’t necessary. Once Chris was able to create an SWF from Flex, he had a file that would run on Windows* or any other platform with Adobe Flash Player*.

However, this left Chris another problem to solve. AppUp™ Center, the store he was targeting, only allowed for C or C++ code to be submitted through its SDK. Again Chris just changed the rules. By having a working app for a netbook but not the right code for submission and validation into the store, Chris simply deployed a C++ wrapper around his Flex application.

I assume a similar method could work for Silverlight or some other comparable solution, as long as the tools are available. Thus, if time is a gating factor either in getting your app ported or time it would take to recode end-to-end, you could look at what tools are available to automatically port your app to another application framework.

No getting around the hardware As different as these approaches are—Mike’s pre-planning, use of standards, and custom libraries versus Chris exporting to Flex with a C++ wrapper—both ports did have similar challenges that were solved in similar ways. Both had to deal with the

hardware differences. Neither app could work as a straight port. Both developers opted to make adjustments in their original apps to make their game experience best suited to a netbook.

Mike’s approach took a similar path to his overall porting approach. The answer was in his original work. Even though the iPhone screen is much smaller than an netbook, Mike chose to create his artwork much larger than the iPhone required. His thinking was that he could easily cut his images in half, but scaling up images would cause them to be fuzzy and lose the sharp crisp look he created for his game. Thus, not knowing what hardware his game may end up on, he decided to scale his graphics 4 times larger than the iPhone. Again, Mike future-proofed and platform-proofed his app from the get-go.

Chris, on the other hand adjusted his artwork and created new graphics for the netbook. This also provided an opportunity to do something’s he felt restricted with on the iPhone. In a way the Netbook was a new canvas to work from and Soma Games found simple ways to improve on things for the Netbook.

The other common issue was what to do without an accelerometer. It’s one thing to scale graphics but how do you deal with a feature that is not supported at all? Mike and Chris seemed to have similar approaches here. They both looked at the strengths of the Netbook and determined how they could integrate those strengths to accommodate some of their accelerometer features. The keyboard on netbooks proved to be an interesting solution for both of them and they found they were able to code in features beyond what they even intended in the original versions.

And this is where Mike figured he needed to do more work. Even though he set his screen images to scale well for a netbook, things like rotating the screen vs rotating the game board were different between the devices. On the netbook, he needed to rotate the game space to maintain

Chris: ...we found that Objective-C was very easy to port to a Flex application. Once we had a .SWF file it was a fairly simple matter to create a C++ wrapper that provided the authentication layer for the AppUpSM Center.

If we’d had more time we might have built the game from the ground up in C++ for performance reasons but in hindsight the typical netbook has plenty of horsepower to run our Flash game with room to spare so it hasn’t been an issue regardless.

2

White Paper Title Placeholder Here

2

Intel® Atom™ Developer Program Part of the Intel® Software Network

beta

the game play, but he would not need to rotate the text or buttons since a netbook would remain in one position. So he adjusted the ratio of his game space to be square rather than a rectangle, thus working better for his netbook game design.

A common approach in the end In summary, although Mike’s and Chris’s initial styles of porting are very different (one Picard, one Kirk) I find their overall approach to porting an app is pretty similar. They both looked at how they could most effectively make use of their existing work while also determining how they could tweak and even improve their app for a quality netbook experience. In the end, they both had to go a bit deeper and adjust the apps to exploit the features of the device. (And I’ll spare the sappy comparison of Picard and Kirk having different styles yet both weighing each alien encounter by special circumstances thus eventually and continually circumventing Starfleet’s Prime Directive).

Summary of best practices

Plan your original app beyond one 1. platform

Leverage cross-platform dev a. standards like OpenGL and C++

Define your own libraries and assets, b. especially if you think this app will have life beyond its first version and first platform

Optimize your app per platform2.

Leverage hardware strengths of a. each device when converting between disparate hardware options

Scale and optimize graphics for each b. device

When possible, design your original 1. art to scale

Find ways to improve features and 2. the experience as you scale

If time and cost of recoding is an issue, 3. is there a quick path to porting that will retain a quality experience?

Is there a quick conversion or a. emulation path to cross platform frameworks like Adobe Flex, Silverlight, or Java?

Is there a wrapper approach you can b. exploit?

In the end, the two ports are good examples of common approaches. Like these famous fictional captains, it’s hard to pick a favorite. You have to admire the ingenuity, creativity, and Kirk-like approach from Soma Games to get their app ported under time constraints. I see Chris’s approach as a common method for developers, and I can say I’m seeing more of this type of solution in our forum discussions. At the same time, Mike’s Picard-style approach is a great example of being a “next generation” developer to code using cross-platform standards with an eye toward deploying on multiple devices.

The world of computing devices is ever growing these days. In the end, both examples show that straight porting is not a good option. A good port will require you to open your code and graphics to exploit the features of the the hardware.

At the time of this post Star Trek, and it’s characters James Kirk & Jean-Luc Picard are the property of CBS Studios.

3

White Paper Title Placeholder Here

3

Intel® Atom™ Developer Program Part of the Intel® Software Network

beta