Dragonfire SDK

I encourage the reader to remember that services like Dragonfire should improve over time. This is the story of my experience in 2011; your mileage will probably vary...

August 2011 - This piece was originally written in March 2011. I've updated it now. I've also switched to native Mac development and talk about that on my XCode page.

March 2011 - My first iPhone app, ShooFly, was released in the iTunes store a few weeks ago. I wrote the app using the DragonfireSDK. I've learned a lot and this essay will tell you the good and the not so good.

How I Got Here

I'm not a Mac guy. I've been a Microsoft PC guy most of my life, except when I flirt with a Unix variant. But in the last many years my laptop and development environment has been Visual Studio. Well, except for my Arduino microprocessor work in Eclipse - a great experience documented elsewhere on this site.

Back in 2009 I bought an iPod Touch to see what all the hoopla was about. That led to an iPhone 3GS a month later. Six months later an iPhone 4. And six months after that an iPad. Then two months later a second iPad for my mom. This year I bought Apple stock at $305 and sold it around $350. I'm becoming a fanboi. But I digress.

So I know C and I know Visual Studio and I desperately wanted to write some kind of an iPhone app to explore the possibilities of this marvelous mobile computing platform. (I have this vision of my iPad controlling something physical via my Arduino. Don't know what yet.) I Googled for quite a while but could not find any cross platform solution. The only choice seemed to be buying a Mac Mini and writing in Objective C. The hurdle seemed too high.

Then a casual conversation with my friend JimW turned me on to the DragonfireSDK. For $50 you can write apps in VS/C C++ and have them run in a nifty iPhone simulator on your PC. For another one time $50 you get the ability to zip up your application source code, send it to Dragonfire via their web page, and get back a package that will install and run on your own iDevice! JimW wrote LMNTology and BuddaBell using Dragonfire and both can be bought in the iTunes app store. Wow.

So I plunked down $50 and downloaded their kit.

I had an idea for a quick little game. A fly crawls around on the screen and the player's job is to shake the fly off. I'll spare you all the details, but in February 2011 ShooFly was born to the world. I told all my friends, some of them bought it. I'm working on more enhancements to ShooFly; who knows if they will ever come out. But I have skipped a few important things you should know.

The Good

As advertised my first Hello World iPhone app was running in the simulator in about 15 minutes. This is good. I found that modifying the code was also easy. As an example, here's how you would display a .jpg file named Welcome in your application:

int MyView = ViewAdd( "Welcome.jpg" ,0,0);

And if you want to have a touch sensitive area that covers the entire screen this is how you do it:

Main() {
     MyTouch = TouchAdd( 0, 0, 320, 480, MyTouchEvent, 1);
}

int MyTouchEvent( int id, int event, int x, int y) {
       if ( event == 3) {
             // Do whatever you want here
       }
       return 0;
}

Pretty darn simple. So very much of the Apple complexity is hidden from view by Dragonfire. With this I was off to the races.

The API documentation is pretty good. U cn rd it and pretty much figure out what the API does. Some things are left unsaid, but that's par for the course.

iPhones, pads, pods, etc do not let just any application run on them. If you want to run your app on your phone then the app has to be built with a special "mobile provisioning" file that binds it to your device and only your device. So to test your app you have to pay Dragonfire another $50 for the pro version. Then you find the UDID of your phone and send it to Dragonfire via email. They add it to your account set up on their end. At the time it took four days. I kept remote compiling and trying to install my app and the install failed with some cryptic iTunes message. I was really worried when I didn't hear anything back from Dragonfire. It's not a problem that it takes 4 days, but I wish their website had let me know what to expect.

When you're ready to build your app for the device you put the source code in a specifically named folder, zip it up, and hand it to Dragonfire via their web site. If everything goes well, then in a few minutes a link will appear that lets you download a compiled iPhone executable. You download the executable and save it to your PC. Then connect your phone to the PC, bring up iTunes, drag/drop the executable onto iTunes and sync your phone. When the sync is done your app is on your phone! This might sound like a lot of work, but it isn't as difficult as it seems. I do it all the time now.

You might want to test your application on several devices. Your iPad. Several friend's phones too. I didn't find any documentation about this on the DF web site, but JimW told me he'd done it, so I emailed support. Sure enough, if you ask you can register another 100 devices. To set this up you have to obtain the UDID of each device. Then you have to send the UDID(s) to Dragonfire support in an email. Each extra UDID costs you $5. You pay Dragonfire via PayPal. I think this is just the way Apple works. I waited four days and my remote compiled executables still wouldn't install on the second device. An email to support, an "oops" on their part, and they had me set up. Well, almost. They put the new UDIDs in a second Dragonfire account, forcing me to either build for my one device or for the others. It wasn't clear to me which UDIDs were in which account and the only way to find out was to try to sync each device. Since my friends were just humoring me in agreeing to be alpha testers I couldn't put them through a lot of trial and error. A few more emails with Dragonfire and this was fixed - all my UDIDs were registered to my one account. I still held my breath for the first remote install to succeed.

When / if you get to the point that you want to put your app in the iTunes store, Dragonfire gives you two choices. The first is pretty easy - you send them the app and they add it to the iTunes store under their developer name, Zimusoft. I took the more difficult approach and created my own Apple developer account - that costs me $100 a year. You do some special things and email your app package to Dragonfire asking them to compile it and upload it to your Apple developer account. Dragonfire has a video of the step by step process of making this work. In the process I got confused by a number of the terms - app id, developer id, apple id, account id - because the Apple developer web site now uses different names for these things. It seems like every few months Apple changes the names and the process. All in the interests of making things easier - and thus making the documentation of their development partners obsolete. In any case, if you pay very close attention and make a few leaps of faith then you can get it done. ShooFly version 1 is proof of that.

Dragonfire support is pretty good. I've had to email them many, many times and they have always responded with good cheer and a nice explanation. They are not always so timely in getting back to me, but at least they respond.

And, I have to say, it is pretty cool to see your own code run in the emulator and then on your own iPhone.

The Not So Good

While the documentation is good, it isn't great. Their usage example for each API call is no more extensive than what I showed above. Their documentation is about on par with Unix man pages. No best practices, no commentary on how to use the one API call with others. Small little errors exist that they don't seem so keen to fix. I had one discussion with a guy on their message board who offered the "they know what they're doing" defense. All I was suggesting was that a line in the documentation of an API could be made more clear by being more explicit. So to use Dragonfire you must be prepared to be an explorer. Try this and see what happens, then try that. As a newbie to a language or platform you have to be ready for this anyway. With Dragonfire you have to be ready to do this with extra patience.

[Update note: As an XCode developer I can see that the Apple environment is really complex. Now that I'm immersed in the XCode, Cocoa Touch, iOS stuff I can understand some of the difficulties Dragonfire faces. Learning the Apple environment helped me learn about Dragonfire, but if you're going to code in DF you can't be expected to understand the Apple UI docs - DF abstracts all that for you and you wouldn't even know what to read.]

If you try to install your app on a device that has not yet been completely registered with Dragonfire, then you get a cryptic error during the sync in iTunes. Not wrong, but you might expect Dragonfire to document these little things on their web site; unfortunately they didn't. [Update note: As an XCode developer, this horrific Apple process is something you have to go through all the time, so now I understand it. Dragonfire makes the process opaque to you as a developer - a good thing - but you also don't have any way to figure out if the install problem is yours, theirs, or Apple's - not a good thing.]

The Dragonfire API is good, but you don't get access to all the iOS functions. The first version I used didn't export the GPS functions. Luckily by the time I needed them the next version of Dragonfire was available. Now I'd like to use SQLLite on the phone, but Dragonfire doesn't offer it yet. There is a lot of stuff in iOS. DF seems to be working diligently to bring more of the power of iOS to the SDK. I think Dragonfire will keep getting more powerful over time. OTOH, if you're really into using all the power of iOS as soon as it's available, then you have to bite the bullet, buy a Mac Mini, and do it in XCode; that makes sense to me.

Another limitation is that your project can only have one .cpp file. If you are a careful programmer who likes to keep many small things in their own buckets to prevent cross contamination, this is a drag. DF offers two options. First is that you can stuff source in an unlimited number of .h files. Normally you wouldn't want source code in a header file, but it avoids the problem. Another option is to use a most excellent post-build utility that uses a manifest file to pull all your source files into a single one for Dragonfire. Thanks to Jon Howard at White Tree Games for sharing this with us all. (His web site reads a lot like Shimpware.) At the time it was just the boost I needed to keep going.

There is also the small matter that Dragonfire has to have all your source code. I'm not writing the next Angry Birds so this is not much of a risk. If you're the paranoid type, then this might be a consideration for you.

And A Bit More Ugly

While the API itself seems robust, the remote build process can be a nightmare. The typical flow: zip up your files, send it to Dragonfire, get a download zip file back in a few minutes. Of course the build might take longer than a few minutes. So you wait. And wait. And wait. After 20 minutes you think something might be wrong so you email support. You sometimes hear back that "the build machine was hung up." Often you don't hear back. You just keep clicking the "is my build done" link every few minutes until it shows up. According to their community pages the remote build process is very fragile. Any user who zips up the wrong files can cause the machine to crash. Apparently no one at Dragonfire notices until someone sends them an email. I exchanged emails with Dragonfire about this and they say they are working very hard to bulletproof the build process. They say that every time someone submits a package that crashes the machine they make a tweak to prevent a similar crash in the future. If you're considering using DF you might check their site to see if they have improved the build status process. Maybe they have an indicator now of whether the build machine is up or not - that would be very helpful.

When your executable comes back in a zip the only way to know if the remote build works is to look for a subfolder named _CodeSignature. Dragonfire didn't document that on their web site, so a noob has to figure it out yourself. Bottom line: if you have a _CodeSignature the build worked. If not, something went wrong. What? Who knows?

One time I added some major functionality to my code. It compiled great in VS, looked super in the simulator, but failed on the back end DF build machine. The only way to isolate the problem was to comment out large chunks out of my code and try another remote compile. Then cut out more and remote compile again. Then cut out more and remote compile again. And when you start hacking at code like this it's easy to make a mistake that causes the remote build to correctly fail so you have to back track and do the experiments again. I must have done 30 builds until one worked, each build taking mind numbing activity. 

The problem in the end? I used the math function abs(). When I posted to their community forum someone responded that the function I was using was in stdlib.h on OSX and I needed to include that. Oh great. I wish the Dragonfire team had documented this. You might look at their site and see if this is now clearly spelled out. If so, good for them! 

Then there was the time (last weekend) that my code just would not compile remotely. It works like a champ on my local PC, but the remote builds failed. I had really restructured my code so cutting out little pieces here and there is not trivial. Yet I went at it for hours and hours. Still no resolution. Here I am a week later and while I'm writing this I'm still at it. This time I've retrieved the last version that worked from my source repository and I'm adding to it until it fails. God knows why the remote build fails.

This is a huge problem. If my app compiles in VS, then it should compile remotely - this is the whole point of a cross development environment. I can understand some hiccups, but they must return some hint as to what went wrong. Having to hack away at a problem like this is just wrong. It takes too much time, causes too much frustration, and is wasteful of your life force. If DF seems like the right environment for you, you might want to look for documentation about remote build errors. By now they may have improved that process. If so, I'll bet they will have something about it on their web site.

In The End

So, where am I? Shopping for a used Mac Mini. If you just want to play around and see what writing an iPhone app is like, then Dragonfire is fine. If you want to do a real state of the art app, then you need to be in XCode. Sorry to say it Dragonfire, but that's my opinion. (And as I write this their remote build machine seems to be down again... sigh.) Once I move to XCode I'll chronicle my experiences in that environment too. [Update: XCode is no feather bed either. Read about it here.]

A Side Note

If you are a serious developer, then I don't have to tell you this. If you're thinking of being a serious developer, get a source control system up and running and use it. Subversion is free and superb. The TortoiseSVN client integrates with Windows and makes the whole thing relatively painless to get started.

UPDATE: The Problem, It Is Solv-ed

38+ remote compiles later I find that "Touch" is a reserved word in the XCode compiler but not in the DF compiler. Knowing this I can now search the Dragonfire forums for that and find a number of words that cause problems. Adding

        #define Touch

To my code will generate local compile errors if I use that construct. A lesser man would have shot himself in the head by now. By the time you read this I hope DF has added these defines to their library so that we customers don't have to tear our hair out trying to make things work.

I changed the code I had running two weeks ago and it compiles again. Now I just have to remember what I was working on back then... 

UPDATE: A reader speaks

I got a very nice couple of emails from Scott M. I'll conflate them here:

And Thanks back to you Scott. Sounds like Dragonfire is improving. I look forward to buying your game - and putting a link to it here! - Jim

---

Jim Schrempp is a sometimes freelance writer (only Vanity Press will publish his work) living in Saratoga, California. His writings have appeared on numerous pages on his own web site. The opinions expressed in this piece are those of the writer and do not necessarily represent those of anyone else (although Jim wishes more people shared his opinions)