Luminary Apps

We've been delving into Coroutines in Unity lately, and ran into a strange behavior today that took all morning to sort out. In brief, a routine we thought we were calling never got called at all -- a Debug.Log as the very first line of the function never logged anything.

We've had a lot of rather philosophical blog posts lately (mostly related to the BOSS text searching system). It seems time to put that aside a moment and get back to some nice, solid iOS coding.

A common pattern for iPhone apps is a tab bar on the bottom, with a navigation stack on each tab. Today, we'll look at how to set up such a structure in code.  (And we'll do it in pure, unsweetened Cocoa for that nostalgic old-school feel.)

Last week, we gave a sneak peek of BOSS, a new approach to string searching. We mentioned a "bit of magic" with regard to the repetition modifiers, * (0 or more) and + (one or more): these would do a lazy match, except at the end of the search pattern, in which case they would be greedy.

We expect this to be the most controversial feature of the whole BOSS design, so it's worth some time to explain all the considerations behind it, why we made this decision, and what the heck "lazy" and "greedy" mean when it comes to string searching anyway.

In the last couple of blog posts, we first reviewed some of the shortcomings of regular expressions (RegEx). We then took a look at parsing expression grammars (PEGs), which are a new formalism that has a lot of advantages for defining (and more importantly, parsing) computer languages. But while they're great for that, using them directly for string searching is a bit of a square-peg-round-hole situation.

So, we at Luminary Apps have begun work on a string matching library that combines the best features of PEG and RegEx. This blog post is the first public discussion of that library. It's called BOSS, and I think you're going to love it.

In our last entry, I bemoaned the shortcomings of regular expressions for complex tasks. (This was after spending a day wrestling with a three-page-long RegEx pattern for finding functions in a C# TextWrangler language module.) I sketched out what I thought an ideal string-matching system would look like.

Well, that was three weeks ago. I've had time to do some more serious research, and it turns out that there is some modern work that is very relevant. It almost fits exactly what we were looking for — but not quite. It's a new construct called Parsing Expression Grammar.

RegEx is handy.  I use it all the time.  For simple tasks, it's quite pleasant to use.  For intermediate-sized tasks, it's acceptable.  But for complex tasks, it is a nightmare to write, read, and maintain.

So, I'd like to suggest that it's time to design an alternative -- something that works just as well on complex tasks as it does for simple ones, and stays readable and maintainable.  I agree with not reinventing the wheel... except when our current wheel is square and lumpy.

New interactive Chess books provide a unique learning experience

FORT COLLINS, July 20 - Luminary Apps today announced version 2.0 of Newbie Chess, a chess program for iOS devices (including iPhone, iPad, and iPod Touch) designed especially for people new to the game.  Version 2.0 adds a big new feature: interactive books by renowned chess authors.

Last week, we presented a method for playing videos that supports external monitors (like the Apple VGA Adapter). But we left out a few finishing touches.

We have a client project that, at several points in the iPad app, displays videos that were embedded into the app. This is an older app, originally written before there were such things as iPad VGA adapters. One might hope that, in the absence of any programming directives telling it otherwise, the iPad would simply mirror its entire display to the video port. Failing that (as Apple in fact has done), you might hope that the MPMoviePlayerController would automatically support the external display. But that fails too.

Since I've been using Unity, I've loved it for the most part. Sure, it leaves a few socks on the floor, such my inability to post to their forum without pestering a moderator for help, or the way an infinite loop in your code locks up the whole Unity environment. But on the whole, it's a really great development system.

Last week, we presented the String class, which gifts the standard Cocoa NSString class with such modern conveniences as operator overloading, allowing the developer to focus more on clearly expressing the intent of the code, and less on arcane 1980s syntax. Today, we're going to look at another Cocoa class in dire need of some help: NSNumber.

We've spent the last month or so considering all the interesting ways that one can use Apple's Objective-C++ compiler to improve Cocoa code. But so far, we've ignored perhaps the most interesting way: using C++ wrappers to improve the standard Cocoa classes.

For the last several weeks, we've been going over how C++ can be mixed with the traditional Objective-C to make your Cocoa even sweeter. But today we're going to cover a somewhat different recipe: mostly C++, with just enough Objective-C to make it work on iOS.

In the last couple of blog entries, we talked in general terms about how you can sweeten your Cocoa with a bit of C++, and covered a bit of history to help us understand how Objective-C and C++ are related.

Now it's time to get serious about actually applying this stuff.

Last week, we gave an overview of how a little sprinkling of C++ could make your Cocoa programming a lot sweeter.  At the end we promised to delve more into details in future blog posts.  So, here we go!  We're going to begin with a little bit of relevant history.

In 2002, Apple quietly introduced the Objective-C++ compiler. Almost nobody noticed. This is a shame, because adding a little bit of C++ to your Objective-C programming can make your code shorter, clearer, more type-safe, faster, and easier to read and write. It is nothing short of revolutionary.

Not too long ago, we were working on an iOS project that involved drawing some custom content that the user can pan and zoom using a UIScrollView.  Because all our drawing was done with CoreGraphics vector-based calls (that is, we're not just blitting any image maps), we thought that it would zoom up smoothly.  Unfortunately, that's not the case; it appears that, under the hood, UIScrollView draws the content to a pixel map, and then just pans and zooms that.  The result is, when the zoom scale is greater than 1.0, the content looks all pixely and ugly.

We have just posted a new demo video, this one introducing Hush For Now, our Android utility for automatically silencing and unsilencing your phone.

A recent study by analytics firm Blaze Software found Android's web browser to be an average of 52% faster than a comparable iPhone.

But as this article points out, they weren't actually using the web browser app on either platform -- they wrote a custom app that used a WebView control on Android, and a UIWebView on the iPhone.

We're working on an application that makes extensive use of Box2D to simulate not just rigid bodies, but also things like ropes, springs, rotary joints, and more.  But we kept finding ourselves frustrated because the joints didn't appear to work as advertised.  Rotary joints were easily pulled apart; weld joints didn't stay welded; distance joints didn't maintain distance; and in many cases, the whole simulation would simply explode, with parts flying everywhere at high speed.  It was like what Egon said would happen if you crossed the streams.

Reducing the timestep didn't help much.  Google searches turned up nothing useful, and poring over the manual didn't provide the clue we were looking for.  But we did finally find the problem, and -- no surprise here -- it wasn't really Box2D's fault.

Following on last week's release of an introductory demo video, here is a more in-depth tutorial video for InkPaint.  Watch over the artist's shoulder as he inks and paints a complete drawing.

Well, we should have done it months ago, but in the spirit of "better late than never," here is a video demonstrating all the key features of InkPaint, the innovative drawing app for iPad.

Luminary Apps is pleased to announce InkPaint version 1.2, available now in the app store.

InkPaint has two new tutorials on drawing fantasy characters, by Sebastien Dardenne.

The Association of Computing Machinery is currently holding a neat programming contest.  Competitors write a program to control a team of virtual children engaged in a snowball fight withan opposing team.

[View in App Store]

Today we released a new version of InkPaint for iPad.  We're very pleased with InkPaint 1.1, and glad to get it to our users, but behind its release is an interesting story — and a cautionary tale for other developers.

Why Unity is my new favorite development tool

Welcome to the Luminary Apps blog!

I know, these "welcome" posts aren't terribly useful, but they're customary.  So, since you're here, let me tell you a bit about who we are and what we do.