In this contract I’ve taken on I need to download a bundle of data from a website. To reduce the time of this download, and to prevent having to download multiple files, we want to compress the files into a single bundle. So I went on a research tear through all the forums and what not and came up with a solution. I thought it might be helpful to report the results of my internet scouring here to maybe save someone else some time.
In programming projects every time I have a choice between something that comes from the DOS/Windows camp vs. something that comes from the UNIX camp, I will go with the UNIX solution every time. I don’t know the origin of this but I suspect that it’s rooted in my opinion of your average UNIX open source developer. These guys are argumentative, tenacious, and iterative. They keep old technologies alive forever, iterating on them constantly. They use the solutions in big data situations, so by the time I come along with my dinky projects I’m using solid technology that would laugh at my piddly data. Whether it’s right or wrong, my opinion of the other side has always been that DOS/Windows technology is thrown together by a few guys to solve a specific problem, and nobody vetted the tech, nobody’s using it on massive scales for large data, all you’ve got are people using it because their afraid of the GPL. This diatribe relates to this particular situation because my choice for the bundle obviously was between gzip/tar and a .zip file. I wanted to go with the gzip/tar, but after my research have decided to go with the .zip.
Looking into things, you can easily link to the zlib library and unzip gzipped files. On its own this is only good if you’ve got a single file. In my case I’ve got a dynamic number of files, therefore tar needed to be added to the equation. So I started looking around for ways to get tar working on the iPhone as well. I found libtar, which is a free C tar library. I figured why not try and see if I can get it to compile for the iPhone. I compiled it, plonked it into my frameworks for a little test iPhone app and hit compile. Of course a warning come up “You idiot, this library isn’t compiled for the same architecture.” I’d compiled it for i386, whereas the iPhone is armv6. I like to cheat, so I hit the net and searched for “compile static library for the iphone”, and found this sweet blog post written by Christopher Green. It’s a way to build any library that uses autoconf for the iPhone. His blog post explains how he’s done all the hard work of figuring out what all the settings should be to compile for the simulator and the device, and he turned it into a nice shell script to figure everything out. I grabbed the script and ran it for the simulator. I replaced the library I’d dropped in earlier with the simulator one, wrote some untar test code, and compiled for the simulator. The library worked like a charm. The problem came when I went to move to compiling for the device. I hit an error in the configure stage though, and realized this wasn’t going to happen without some investigation. Before starting the investigation though I sat back and thought really hard about whether I should be continuing to get tar to work. I remembered reading the file access documentation for the iPhone and one of the points they make is that the storage is flash memory and it’s our responsibility to reduce the number of writes we do to flash memory as much as possible. I realized that my desire to use gzip/tar was violating this requirement. I would be unzipping the .gz, creating a big .tar on the filesystem. Then I’d be untarring the .tar into the individual files. Two large writes, when if I used a .zip I’d only have the one big write for the .zip file, and then the individual writes. I don’t have any stats on the speed of a gunzip/untar versus unzipping a .zip file, but my gut says the single unzip would be faster as well.
So I went to a post on the iphonedevsdk.com forum I’d read earlier for an Objective-C class for unzipping .zip files. It seems to be well received on the forums, so I decided to check it out. I’ve tested it out and it works quite well. It’s not written the way I would have written it, but hey, the guy saved us all a bunch of time so credit where credit’s due.
So there you go, my recommendation is to use .zip files, and use the ZipArchive class. Oh, here’s the ZipArchive depository on Google.
So good news this week, it looks like the clients I prepared a tech design and estimate for were happy with my work and I’ll be working on their app till mid December. This will provide some funding which I can use to pay lawyer and accountants for their year end type stuff, as well as to fund the art for the game so it’s great news.
The app involves taking information from their website and presenting it in a nice way as a native app on the iPhone, which is a common trend I find on various sites for people looking for iPhone developers. I think there’s a big call for this type of work. This client’s needs are more complicated than that, but it’s great that it’s in this domain as it should be a useful project for my portfolio for any future contract work I want to do.
I spent this week really getting into the PHP and MySQL web database programming book I bought. It’s really helped me get a handle on how I can go about connecting iPhone apps with web services, and has given me a general feel for what I can pull off on the web side of things.
I also just finished a large proposal writeup for a client that would be nice to get, so we’ll see how that goes. Looks promising.
I’ve also decided on the next application I’m going to make to put money in the bank. I’m not sure how safe it is to say what it is until I’m well into it and have a head start on the potential app ninjas reading this blog though. What do you guys think? Oh wait a minute… You almost tricked me you dirty ninjas. Of course you’d post comments telling me it’s perfectly safe. Damn your stealthy ways.
Well how about this, as soon as I have something even decently close to working I’ll explain it here. Then my super iPhone programming skills will allow me to bring it to market well ahead of the ninja’s meager skills.
I’m so excited about Apple’s decision to allow in-app purchases in free applications. This is huge for us. I can think of so many uses for this its ridiculous. I think this will massively help the indie game developers. Download my game for free and play the first level. If you like it, buy it, otherwise no harm to you. How can you argue with that? The only worry I have is that this means that the old app lists are gone for good. It was a lot easier to have a top free app than a top paid app, and all that top free app visibility really helped people generate traffic on their paid versions. But whatever. To me this means that theoretically if I do my job properly, as in I choose the right game design that is fun and engaging, and then I deliver on that design and build a high quality game, I should see results in the form of significant income. It should seriously mitigate the lottery effect going on right now.
I’ve been working with two artists on my game that either have a fulltime job or their main focus was to get a fulltime job. This has proven to not be a good arrangement, without being ther fault. It’s just that their main focus hasn’t been my project, which has resulted in far too long of a delay in getting art. The ideas they had were great and were really helping drive the development of the game’s concept, we just weren’t getting it to a state where I could even show things here on this blog. I’ve decided now that I will pay for art via some outsourcing options when the time comes, however I’ll need to generate some income from other sources to fund the amount of art this game will need.
I spent last week renovating my kitchen for the hopefully near likelihood of selling our house to move for a job my wife is trying to get in another part of Canada. This gave me a lot of much needed thinking time of what approach to take to generate some income to fund my art requirements. I’m going to approach the problem from two directions: I’m going to keep pursuing contract work because I’ve had a couple of promising leads there, and I’m going to start working on another app for the store.
I’ve noticed that a lot of the contract work out there involves integrating or porting a company’s website or web functionality to the iPhone, and I’ve felt this is a hole in my skillset for awhile. I’ve also got a lot of app ideas that involve integration with a website, and so I’ve decided I need to improve my skills in these areas. So I’m going to focus on learning PHP, and getting up to speed with integrating an iPhone app with web hosted databases. These aren’t complicated things but they’re just not something I can say I’ve done in my game career, so I need to develop something that makes use of these technologies so I can show that I’m fully capable of it when I bid on projects.
For the app I’m going to make I’ve got quite a few ideas, and one non-app but iPhone related tech idea, and I’ll post more once I decide for sure which one I’m going to do. Stay tuned.
