Archive for July, 2009

Summer time: BeachBall

Thursday, July 30th, 2009

beachball_submitThe BeachBall app has been submitted to the iPhone App Store. I’m pretty sure that I’ve crossed all the t’s and dotted the i’s throughout the application and am holding out hope for a smooth process. If all goes well it will be a great surprise just before the next semester kicks off.

Thanks to everyone who has been beta testing the (codename) Pinwheel app. I’ll be sure to give you all a copy of the final app when (if?) it’s approved.

In the meantime there are several other projects which need my attention. I’m committed to getting the in-progress work finished before moving on to new stuff…which is a strong motivator since I have a few things I’m really excited about working on. Onward…!

PinwheelBeta – adhoc

Thursday, July 23rd, 2009

In preparation of submitting Pinwheel to the App Store I’ve gone and released a beta version via ad hoc distribution. Seems like it should be a straightforward prospect, however the various device provisioning, code signing profiles and entitlements made it a bit of a process for a first-timer.

iTunes also seems to be entirely unhelpful when something goes wrong with the “unknown error” message. What could it be? Code sign error? Unprovisioned device? Incorrect OS target? Mismatch in the app and mobileprovision file? It’s all a mystery in the iTunes universe.

Despite the inconvenience involved with having to generate a new ad hoc mobileprovision profile each time I add a new beta tester device, requiring a recompile of the beta app, it’s nice to finally get an app out to other non-development devices.

The ad hoc distribution process is documented well (enough) on Apple’s dev portal and on several other blogs, but my real stumbling block was navigating the Xcode interface to ensure that the proper code signing profile was being included in the binary (hint, look at the verbose build output for “embedded.mobileprovision” and ensure that the mobileprovision ID matches the correct version.)

I’ve also been getting trouble with Xcode not building using the correct provisioning, despite updating the target info and cleaning out the build folder. A restart of the program usually gets it sorted.

The next step will be to set up a Distribution build for the App Store submission. We’ll see how that goes in the end…

cross-compiling for iPhone dev

Wednesday, July 15th, 2009

Update: Proof-of-concept demo. Also, updated the script for building with the 10.6 SDK.

Update #2: Source code for demo project released.

Update #3: script for use with tesseract v3 posted.

I recently had need to use an open-source library in an iPhone project. Recalling the earlier work necessary in compiling the libraries needed for openFrameworks I started looking for a more generic way to build for iPhone development. Thankfully, LateNiteSoft wrote a great article about using a shell script to cross-compile linux projects, building a Universal Binary with versions for the Simulator and Device.

I configured their provided code snippets to build tesseract-ocr for iPhone, referring to the set-up for freetype and freeimage to fill in some c++ gaps. Anyway, the library seems to have built correctly. I’ll know for sure when I incorporate it into a project, soon.

To use it, copy the script into the project directory, next to the configure script. For a simple project which generates one monolithic library, edit the LIBFILE variable to reflect the location and name of the library. I’ve only used this for static libraries…other work may be necessary to correctly generate dynamic libraries (however, the iPhone SDK prohibits linking to dynamic libraries, so in this case it seems moot). Run ./build_fat.sh to kick off the process. Look for the compiled libraries in the “lnsout” directory. There’s no error checking, so caveat emptor. :)

Cross-compile shell script follows: (more…)

openFrameworks iPhone 3GS / OS 3.0

Tuesday, July 14th, 2009

i’ve been dealing with a performance bug in a particle + accelerometer oF app. the same project which has run very smoothly on a first generation iPhone with OS 2.2.1 has a noticeable stutter on an iPhone 3GS with OS 3.0.

there was no improvement despite several rounds of optimizing the openGL drawing code and plugging several memory leaks.

finally, in frustration i bumped the explicit frame rate declaration from the default 60 fps to 120 fps. i realize that ofSetFrameRate(60) is merely the upper limit of the frame rate, and that the hardware won’t actually go faster than it can handle, however this immediately improved performance on the 3GS and the first gen is about the same as it was. further improvement was had with a declared frame rate of 240 fps.

i haven’t had a chance to look into the underlying issue, but i believe that oF is using NSTimer under the hood to trigger a scheduled update() and draw(). has there been some change in the SDK there?

…little help (oh, malloc)?

Monday, July 6th, 2009

i’m having a time of it tracking down a resource allocation bloat culprit in an iPhone app i’m working on. i’ve narrowed it down to when i’m rapidly updating the center property of a UIImageView. a snippet from the Instruments application is below:

malloc


there are hundreds (if not thousands) of these messages, and the object allocation graph trends steadily upwards. when i disable the portion of the method which updates the center property the allocations stop and the memory usage goes flat. this also only occurs on the device…the simulator does not exhibit this behavior.

i’m using UIImageView directly, without subclassing, and it contains data from a small PNG file. i’ve patched up several other leaks successfully today, and really wanted to nail this one too.

git outta here…

Friday, July 3rd, 2009

I’m switching my Source Control Management ¬†software to git. Performance has been great, I’m learning to branch and merge with wild abandon and philosophically it’s right on (what with the distributed model and all).

Creating a new remote repository on my private server was *almost* too easy. The one snafu was getting sshd to include the git binary path for non-interactive login. To save me the trouble of having to look this up again later, add a .bashrc file to your user dir:

export PATH=/usr/local/git/bin:$PATH

Other steps, again for reference.

  • Download the git installer
  • Create a new bare repo on the remote machine:
mkdir -p /path/to/remote/repo.git
cd /path/to/remote/repo.git
git --bare init
exit
  • Add the remote repository to the local machine:
git remote add origin ssh://server/path/to/remote/repo.git
git push origin master
  • Done!

(Unless, of course you get the following message try the .bashrc workaround above)

bash: git-receive-pack: command not found