AdMob chose to highlight the following results:

• Android and iPhone users download approximately 10 new apps a month, while iPod touch owners download an average of 18 per month
• More than 90 percent of Android and iPhone OS users browse and search for apps directly on their mobile device instead of their computer
• Upgrading from the lite version was the top reason given when users were asked what drives them to purchase a paid app
• iPhone and iPod touch users are twice as likely to purchase paid apps than Android users
• Users who regularly download paid apps spend approximately $9 on an average of five paid downloads per month

As the proud user of an iPod touch, I was thrilled to see that my fellow touch users are, by far, the most prolific downloaders:

There are a couple of interesting things about this chart.  First, it should probably be titled, “Avg. Downloads per User per Month,” but that’s nitpicking.  The other thing that caught my attention is that, while iPod touch users are nearly twice as productive (or perhaps counter-productive, depending on whether you’re their employer) as iPhone users in terms of downloading apps, they are much less likely to pay for their apps.  Nearly 25% of the iPhone apps are paid, while just over 10% of the apps on touches are paid.  This is another reminder that the user communities are not at all homogeneous across the two devices.

For this post, I’m going to focus on the iPhone / iPod touch.  Although the report also covers Android, at this point, I’m more interested in the results for our target platforms.

In going through the report, I noticed a couple of other bits that are likely to influence how I conduct campaigns for BluMtnWerx.  For example, the top three ways that users discover apps are, in order:

• Browsing through top App Store rankings
• Searching for a specific type of app
• Word of mouth (recommendations from friends or colleagues)

They also asked people who downloaded at least one paid app / month, “What Usually drives you to purchase a paid app?”  I guess that I shouldn’t be surprised, given some of the experiments that developers have conducted, but the top reason was (emphasis mine):

“I like the free version and upgraded“

I sure wish that Apple would approve iPuckLite!  It’s been waiting for nearly a month, now.

By contrast, the bottom two were:

• News articles or blogs
• A brand I know reaches out to me and introduces an app

Clearly, this reinforces the notion that getting high rankings in the App Store is the ticket to success.  It might also suggest that the effort put into blogging & self-promotion may have less impact (so why am I writing this?).  When I think about the results, though, I wonder whether the grassroots blogging and outreach are actually necessary prerequisites for getting good rankings on the App Store.

One place where the sample bias in AdMob’s methodology really comes through is the #4 item on their list:

“Seeing ads while using other apps”

The report contains some extremely interesting data on daily usage of apps.  Apparently iPhone users spend, on (weighted) average 84 minutes/day using apps, while iPod touch addicts are tapping away for 121 minutes/day.  The most fascinating thing in that data set, though, was the report that 21% of iPod touch users spend More Than Four Hours each day stabbing at their screens!  I don’t know whether to feel happy, or sad, if that’s true.

Finally, AdMob did some back of the envelope calculations to conclude that the App store paid market is currently (August 2009) about $200M per month.  Stunning.

Even if you don’t like AdMob, you really should spend a few minutes evaluating the information in this report and considering how it might impact your business.

The list below is ordered by my priority for reading.  If I have just a tiny bit of time, I read the ones at the top of the list.  If I have more time, I go further down through the list.

• iPhone Development — Jeff LaMarche — I’m a huge fan of “Beginning iPhone 3 Development:  Exploring the iPhone SDK,” the book that Mr. LaMarche wrote with Mr. Mark (see below).  This blog is always extremely well written, regularly offers great development tips and often alerts me to other information sources.  I read a larger portion of Mr. LaMarche’s posts than I do on any of the other blogs.  This is a must follow.
• Dr. Touch — Oliver Drobnik — Another blog that often features great development tips.  Mr. Drobnik is also quite funny.  His description of the time that he dropped his MacBook is classic.
• NSBlog — Mike Ash — This is one of the best technical blogs on the list.  The only reason that it’s not higher, in this context, is that the blog is more broadly focused on the whole realm of Mac development, so the content isn’t always applicable to the iPhone SDK.  However, I learn something from almost every post and, likewise, consider this a must read blog.
• Things that were not immediately obvious to me — I’ve actually implemented several of the tips on this blog in BluMtnWerx code.  This is one of the most useful blogs in terms of immediately applicable content and is also a must read.  The author does cover a wide range of topics, so I often find myself skipping posts that aren’t relevant to my interests.
• Call Me Fishmeal — Wil Shipley — Mr. Shipley’s “Pimp My Code” series is among the most informative and directly useful bit of writing that I’ve come across in the blogosphere.  I highly recommend it.
• theAppleBlog — In my experience, this is the king of the “reasonably credible” Apple gossip blogs.  While the contributors are undoubtedly Apple fans, they are willing to be critical on occasion.  Since Apple’s rumblings are so important to my livelihood, I pay attention to what these folks say is on the horizon, as well as to their analysis of the current landscape.
• The Boy Genius Report — This blog can’t be beat for timely gossip about upcoming products and adventures with the carriers.
• Apple Insider Blogs — A great source of gossip regarding happenings in the Apple ecosystem.
• Daring Fireball — John Gruber — Mr. Gruber is most famous, in my book, for his posts on App Store injustice, here and here.  He is also one of the authors who elicited a response from Apple’s Phil Schiller.  The blog is extremely well written and often provides an interesting perspective on the industry.
• touchArcade — This is a good source for reviews of the latest additions to the app store.  I have to confess that I’ve bought apps after seeing them reviewed in touchArcade.  Also, the touchArcade forums are, by far, the most productive places to post new app announcements.
• Dave Mark’s Blog — Dave Mark — Mr. Mark is the other author of “Beginning iPhone 3 Development:  Exploring the iPhone SDK.”  The blog is very entertaining and covers a broad range of topics, some of which are quite relevant to this discussion.
• 148Apps.biz — This blog doesn’t get updated very often, but I refer back to their App Store Metrics page several times each week, especially when I’m writing anything about the App Store, or wondering about the current app approval times.
• furbo.org — Craig Hockenberry — Mr. Hockenberry writes great posts, including the iconic “Year two” vivisection of the App Store.  He has a real “insider’s” perspective that I find to be extremely valuable.  I just wish that he would post more often.
• iPhone Dev SDK Forum:  iPhone SDK Development RSS feed — I realize that this isn’t a blog, but Chris Stewart has enabled an RSS feed for the “iPhoneDevSDK – iPhone SDK Development forum.”  I follow this one for a couple of reasons.  First, a few times each week, I learn something from the answers.  Second, I like to answer questions posed on this forum, and this is a good way to see what’s been asked recently.  BTW, the URL for the feed is:  http://feeds2.feedburner.com/iPhoneDevSDK-iPhoneSDKDevelopment.

If you have suggestions for others that I should be following, please let me know! I’m always interested in additional excuses to procrastinate.

Both of these images show iPunt’s renderings of models that were originally created in Blender.  Not to give Paul too many strokes, but they are really good, and they clearly show what can be done with the tool.  In the spirit of full disclosure, I had to ask Paul to create the graphics for iPuck.

I sincerely tried to learn Blender, but I quickly began to fear that I was going to devote more time to just getting the basics down than I was going to allocate to writing the code for my next app.  This unhappy situation got me to wondering whether there might be some other solution that was good enough for code monkeys like me.  After all, I just needed a handful of 2D renderings from 3D models.  Since we’re not yet an App Store success story, cost is a big issue, and “free” is pretty much the only acceptable price.

With these requirements in mind, I decided to take another look at Google’s SketchUp.  If you need to build 3D models that can be exported so that your app can manipulate and view them from all angles (as does iPunt), the free version of SketchUp won’t work for you.  Instead, you will need to fork over US$495. to Google for the “Pro” version.  SketchUp Pro includes 3D model import & export, more collaboration support and other high end features.  On the other hand, if you just need 2D renderings from 3D images (like iPuck), SketchUp may very well be the ticket.

Boiled down, unless you’re a renaissance man, like Paul, here are some of the reasons to consider giving SketchUp a shot: (The next two images were rendered from SketchUp models)

• It’s free (well, not the “Pro” version).
• It has native apps, with intuitive UI’s, on both Win and Mac.  I use SketchUp regularly on both platforms.
• Learning the basics is truly a snap.  There are excellent video tutorials, comprehensive web-based documentation, and you can always use Google to search for answers.  I was able to start working with a sphere in just a few minutes and to create a passable rendering almost immediately.  The same could not be said for my efforts with Blender.
• Even a code monkey with my pathologically limited art skills, was able to create “good enough” images with just a few tens of minutes in SketchUp.

I’ll keep struggling to learn Blender, but, in the meantime, SketchUp seems to be “good enough.”

 [myLbl setFont:[UIFont fontWithName:@"Helvetica-BoldOblique" size:20]];

and

UIFont *font = [UIFont fontWithName:@"Zapfino" size:titleSz];

   NSArray *names = [UIFont familyNames];
   NSArray *fontFaces;
   NSLog(@"FONT NAMES");
   for (NSString *name in names)
   {
      NSLog(@"Font Family:  %@",name);
      fontFaces = [UIFont fontNamesForFamilyName:name];
      for (NSString *fname in fontFaces)
      {
         NSLog(@"              %@",fname);
      }
   }

FONT NAMES
  Font Family:  Courier
                Courier
                Courier-BoldOblique
                Courier-Oblique
                Courier-Bold
  Font Family:  AppleGothic
                AppleGothic
  Font Family:  Arial
                ArialMT
                Arial-BoldMT
                Arial-BoldItalicMT
                Arial-ItalicMT
  Font Family:  STHeiti TC
                STHeitiTC-Light
                STHeitiTC-Medium
  Font Family:  Hiragino Kaku Gothic ProN
                HiraKakuProN-W6
                HiraKakuProN-W3
  Font Family:  Courier New
                CourierNewPS-BoldMT
                CourierNewPS-ItalicMT
                CourierNewPS-BoldItalicMT
                CourierNewPSMT
  Font Family:  Zapfino
                Zapfino
  Font Family:  Arial Unicode MS
                ArialUnicodeMS
  Font Family:  STHeiti SC
                STHeitiSC-Medium
                STHeitiSC-Light
  Font Family:  American Typewriter
                AmericanTypewriter
                AmericanTypewriter-Bold
  Font Family:  Helvetica
                Helvetica-Oblique
                Helvetica-BoldOblique
                Helvetica
                Helvetica-Bold
  Font Family:  Marker Felt
                MarkerFelt-Thin
  Font Family:  Helvetica Neue
                HelveticaNeue
                HelveticaNeue-Bold
  Font Family:  DB LCD Temp
                DBLCDTempBlack
  Font Family:  Verdana
                Verdana-Bold
                Verdana-BoldItalic
                Verdana
                Verdana-Italic
  Font Family:  Times New Roman
                TimesNewRomanPSMT
                TimesNewRomanPS-BoldMT
                TimesNewRomanPS-BoldItalicMT
                TimesNewRomanPS-ItalicMT
  Font Family:  Georgia
                Georgia-Bold
                Georgia
                Georgia-BoldItalic
                Georgia-Italic
  Font Family:  STHeiti J
                STHeitiJ-Medium
                STHeitiJ-Light
  Font Family:  Arial Rounded MT Bold
                ArialRoundedMTBold
  Font Family:  Trebuchet MS
                TrebuchetMS-Italic
                TrebuchetMS
                Trebuchet-BoldItalic
                TrebuchetMS-Bold
  Font Family:  STHeiti K
                STHeitiK-Medium
                STHeitiK-Light
  

Happy Fonting!

Here’s the effect I was trying to achieve:

What we have here is the iPunt playing box suspended in mid-air. The floor is a broken mirror (although that’s a little hard to see from this angle.) The camera is allowed to move freely around the inside of the skybox. When the camera is below the foor, the floor appears transparent (like broken glass.) The walls of the playbox are fractured glass.

The problem, really, is the reflection. Without any stenciling, you get this…

We somehow need to prevent the reflected scene that is not viewed through the mirrored floor from showing. A stencil buffer would have worked well for this purpose. Without a stencil buffer, you have to rely on depth culling and transparency to achieve the desired result.

In brief, what I did was to create a stencil shape (a planar shape made up of triangles) that had a hole in the middle where the mirrored floor was going to be and was large enough to obscure the reflected scene from all camera angles above the plane of the floor. This shape will be drawn transparent (alpha = 0) so that the skybox will show through, but the draw order and the depth culling will prevent the unwanted portions of the reflected scene from showing through.

Here’s a picture of the skybox, reflection, and stencil (with the alpha turned up so that it can be seen.)

Because the draw order is skybox, then stencil, then reflected scene, those portions of the reflected scene that are occluded by the stencil are depth-culled and won’t be drawn. The real scene and floor can then be drawn.

Here is the code, with comments, that does this…

First, the definition of the stencil and floor triangles.

// The shape here is a large plane
// with a hole in it where the mirror will be.
const GLfloat stencilVerts[] = {
-100.0, -15.0, 100.0,
-10.0, -15.0, 10.0,
100.0, -15.0, 100.0,
10.0, -15.0, 10.0,
100.0, -15.0, -100.0,
10.0, -15.0, -10.0,
-100.0, -15.0, -100.0,
-10.0, -15.0, -10.0,
-100.0, -15.0, 100.0,
-10.0, -15.0, 10.0
};

const GLfloat floorVerts[] = {
-10.0, -15.0, 10.0,
10.0, -15.0, 10.0,
10.0, -15.0, -10.0,
-10.0, -15.0, -10.0,
};

const GLfloat floorUV[] = {
0.0, 0.0,
0.0, 1.0,
1.0, 1.0,
1.0, 0.0
};

Then in my render() function…

  glEnable(GL_DEPTH_TEST);
  glEnable(GL_TEXTURE_2D);
  glShadeModel(GL_SMOOTH);
  glBlendFunc (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

  // Clear the space
  glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
  CHECK_ERR

  // Draw the skybox
  _pSkyBox->draw();
  CHECK_ERR

  // Only draw the reflection if the view is above the plane of the floor.
  if (pWorld->camera()->location().y() > -14.5) {

    // Draw the stencil.  Anything that is drawn after this that is occluded by the
    // stencil will not be drawn because it fails the depth test.  The skybox, which
    // has already been drawn, will show through everywhere because of the transparency.
    pWorld->material("StencilMaterial")->installMaterial();  // Sets the material properties, including alpha
    glEnableClientState(GL_VERTEX_ARRAY);
    glVertexPointer(3, GL_FLOAT, 0, stencilVerts);
    glDrawArrays(GL_TRIANGLE_STRIP, 0, 10);
    glDisableClientState(GL_VERTEX_ARRAY);
    pWorld->material("StencilMaterial")->uninstallMaterial();

    // Draw reflection w/out floor -- Reflection will be depth culled everwhere but hole
    // Draw everything else normally (including the mirrored floor)
    glPushMatrix ();
    // Mirror lies in XZ plane, so scale by -1.0 in Y axis
    glScalef(1.0, -1.0, 1.0);
    // Mirror is 15.0 units from origin, so translate by 30.0 units
    glTranslatef(0.0, 30.0, 0.0);
    pWorld->draw();
    glPopMatrix();
  }
  CHECK_ERR

  // Draw the real scene
  pWorld->draw();
  CHECK_ERR

  // Draw the floor
  BMWLight::disableLighting();
  pWorld->material("Material_010")->installMaterial(); // Sets the material properties
  glEnableClientState(GL_VERTEX_ARRAY);
  glVertexPointer(3, GL_FLOAT, 0, floorVerts);
  glEnableClientState(GL_TEXTURE_COORD_ARRAY);
  glClientActiveTexture(GL_TEXTURE0);
  glTexCoordPointer(2, VERTTYPEENUM, 0, floorUV);
  glDrawArrays(GL_TRIANGLE_FAN, 0, 4);
  glDisableClientState(GL_TEXTURE_COORD_ARRAY);
  glDisableClientState(GL_VERTEX_ARRAY);
  pWorld->material("Material_010")->uninstallMaterial();
  BMWLight::enableLighting();

Note that the BMW functions are functions in our framework that encapsulate OpenGL functionality. You can pretty much treat them as pseudo-code in this example.

So, there you have it. A use of depth culling and transparency to implement functionality that I originally though required a stencil buffer. I’d be intereste in hearing about any examples you have of similar effects!

The cause is the following code in SoundEngineEffect::PlaybackProc()

  if (THIS->HasAttackBuffer())
  {
    ALint numBuffersProcessed = 0;
    while (numBuffersProcessed < 1)
    {
       alGetSourcei(THIS->GetEffectID(), AL_BUFFERS_PROCESSED, &numBuffersProcessed);
         AssertNoOALError("Error getting processed buffer number", end)
    }

While the attack buffer is playing, you’re in a tight polling loop waiting for it to complete.  This is no problem if the preamble is really short, but for OpenGL games, it’s going to cause problems for any sound longer than a fraction of a frame.

The fix, fortunately, is simple.  Sleep this thread for a few milliseconds each iteration of the polling loop in order to give the rest of your application a chance to run.

The modified code is:

  if (THIS->HasAttackBuffer())
  {
    ALint numBuffersProcessed = 0;
    while (numBuffersProcessed < 1)
    {
       alGetSourcei(THIS->GetEffectID(), AL_BUFFERS_PROCESSED, &numBuffersProcessed);
         AssertNoOALError("Error getting processed buffer number", end)
       usleep(5000);  // Sleep for 5 mS each polling loop
    }

This little change makes all the difference for this bit of code and makes it suitable for long (> 1second) preambles.

I’ve found SoundEngine to work pretty well, although I have had to make a number of modifications to it for my specific application.  However, I think I’m at the point where I need to write my own OpenAL sound processing class library.  I’d be interested to hear from some of you to see what you’re using for game sound.

Fortunately, or unfortunately, depending on your perspective, the pool of credible reviewers for most apps is infinitesimally small relative to the number of promo codes available.  I decided to try to get some rough insight into the numbers involved.  Here’s what I came up with:

Let’s ignore updates and expirations for a moment.  According to the always excellent sources at 148Apps, roughly 77% of the apps in the store are paid (they claim to update their data daily, so this should be current info).  They also report that, as of today, there have been 63,013 apps seen on the store.  That would give us somewhere in the neighborhood of 49K paid apps seen in the store.  Multiply this by 50 promo codes per application and we determine that there have been just under 2.5 million codes potentially available.  I’d guess that far less than 50K of those were used by credible reviewers — how many truly credible reviews have you seen?  The rest are either going to waste, or being broadcast distributed (I include the “Massive App Giveaway” contests in this latter bucket).

Further, at least in my experience, most people who get a promo code don’t bother to follow up with a review.  Or maybe they’re just too polite write what they really think about my apps.  You might think that my friends would be willing to tell lies for me, but… then we’re back to the credibility thing.

If we accept that most of the promo codes aren’t going to be effective at generating blockbuster sales, we have to think about alternate objectives.  Will giving out lots of promo codes get people to use the app and talk about it, resulting in some new sales?  Will the availability of the promo codes bring attention to our team?  Will people, somehow magically influenced by the promo codes, at least visit our site?  As we move further away from money deposited in our accounts, the value of these becomes much lower.

Now for the bad news.  Some of the things that we’ve tried, include:

• Sending promo codes in personal emails directly to reviewers asking for coverage
• Providing codes to friends who promised to review the apps
• Sharing codes with other developers who frequent the forums where we contribute
• Responding to a small number of the requests for promo codes that accompany each app’s debut in the store — we did get a nice video review of iPuck this way
• Placing a block of codes on a friendly forum

Our results have been dismal.  Like everyone else, I’ve heard anecdotes (myths?) about how promo codes have really boosted apps.  Since ours aren’t having this effect, I’m forced to consider some possible explanations.  Perhaps promo codes can accelerate adoption of an app that’s already on a good trajectory, while not doing much for an app that’s still trying to be noticed.  It’s possible that promo codes provide more benefit within closely related / interdependent networks.  Maybe our apps are just not interesting to anyone but us.  Referencing back to the quantity of available promo codes, maybe the system just has such an abundance that codes for lesser-known apps are essentially without value.

It’s clear to me that this kind of success doesn’t justify the effort that we’ve put into managing and distributing promo codes for our apps.  We’ll continue to give them out to friends, because we kind of have to.  We’ll also be open to plausible requests for codes.  However, I’m completely giving up on using codes as proactive marketing tool.

By the way, here’s a fun fact that I ran across while researching this post:

The 148Apps Price Distribution page reports that I could buy a copy of all of the apps on the store for $137,262.00.

That’s a lot lower than I would have guessed, given the amount of energy and money flowing through the app store right now.  This appears to be an excellent demonstration of the power of lots of really cheap apps.

 
——–
Technorati Tags:  iPhone, iPod Touch, Apple, mobile, promo codes

Chipmunk is a

Fast and lightweight 2D rigid body physics library in C

That last bit is important for iPhone development, because, as we all know, ‘C’ plays very well with Objective-C.  Once I figured out how to call Objective-C methods from the Chipmunk related ‘C’ code, integration was very smooth.  It’s worth mentioning that the standard ‘C’ code in the Chipmunk distribution compiles fine in Xcode and runs with no problems on the iPhone and iPod touch.  I was worried that I might run into some issues, but it was perfect.  By the way, we plan to use Chipmunk for other projects, so I set it up as a “Source Tree” in Xcode, rather than just dumping the files directly into the iPuck project space.  Paul wrote an excellent post on doing this for Oolong.  I just followed his directions.

I won’t list all of Chipmunk’s features, they are nicely presented on the project page, but it is fast and straightforward to use.

The documentation is a bit sparse, especially for someone just getting started.  The demos are very helpful, but generally seem to assume that we already have a pretty good understanding of Chipmunk.  A set of demo programs is bundled with the ChipmunkLatest.tgz download.  Even nicer demo programs are available in the project repository. 

Fortunately, Alexandre Gomes has prepared a nice tutorial on getting started with Chipmunk.  I noticed a few typos in the sample code, but it gave me a great start towards learning the library and figuring out how to slide it on to the iPuck chassis.  Mr. Gomes does a good job of explaining the basic concepts.  I highly recommend taking a look at the tutorial if you’re considering using Chipmunk.

Once I got started actually porting iPuck, I only encountered a couple of small snags.  The first came when I was still working with permutations of Mr. Gomes’ sample.  I couldn’t figure out how to grab an object and drag it around on the screen.  After a bit of searching on the extremely useful Chipmunk forum, I found some sample code that provided most of what I needed.  I’m led to believe that there will soon be better ways to do this in Chipmunk.  However, after a bit of customization, cpMouse met the needs for iPuck v1.1.  I plan to look at some of the other methods to see whether I can continue to improve the code.  Look out v1.2.

The other problem was my fault for not reading the cpShape documentation more thoroughly.  I had originally modeled a number of my static objects as cpSegmentShapes.  This worked really well as long as my active objects were all cpCircleShapes.  Unfortunately, when I tried to model an active object using segments, I discovered that the current version of Chipmunk does not support cpSegment-to-cpSegment collisions.  After I went back and converted to cpPolyShapes, everything was perfect.  If I had carefully read the Chipmunk documentation, before I started coding, I would have seen:

Line segments: Meant mainly as a static shape. They can be attached to moving bodies, but they don’t currently generate collisions with other line segments.

I needed to develop against a stable library, so I chose to stick with the 4.1.0 version.  Judging by the activity in the project archive, there has been substantial progress since 4.1.0 and I’m looking forward to working with the latest revisions when they’ve settled into a steady state.

If you’re working with rigid bodies, and you need a fast, accurate, easy to use and, best of all, license fee free, 2D physics library, Chipmunk may be a perfect match for your needs.

 
——–
Note:  Instructions for using Subversion to check out the code and demos are here.
——–
Technorati Tags:  iPhone, iPod Touch, Apple, mobile, chipmunk physics

My hesitation has been based on the fear of losing potential customers who haven’t upgraded to the newest version of the OS.  Fortunately, a number of apparently independent sources are suggesting that uptake of the new OS is much faster than I might have expected.  With this latest news, it’s starting to look like we’ll cut over completely to 3.0 much sooner than I’d originally planned.

Here’s some of what I’m looking at:

Paul, over at Tapbots is reporting (dated 2009.06.23) that:

“It’s pretty clear that at least our customers are upgrading to 3.0 at an incredibly fast pace.”

“… running at an overall 75% upgrade rate which is pretty insane considering the number of devices and the fact that its only been 5 days.”

“The iPhone upgrade rate is a bit higher then the overall rate, currently sitting at 79%.”

“… the iPod Touch has just passed 50%.”

The post also has some nice graphs of what they’re seeing.  They promise to update the post as new information comes in.  I’ll be checking back periodically.

In a similar vein, AdMob just published a report (Their graphs are dated 2009.06.20, so this covers just a few days after the iPhone OS 3.0 software was generally available) that also suggests strong, albeit somewhat lower uptake rates for the iPhone:

…44% of iPhone ad requests coming from the 3.0 OS

AdMob’s data suggests that just 1% of requests coming from iPod touches are originating with devices running 3.0.

For as long as they continue to be available, here are the charts from AdMob:

and

Of course, it’s always possible that we’re seeing sample bias in these two reports.  Perhaps customers of Tapbots and users of apps that present AdMob ads are not representative of the total population.  However, I’m inclined to believe the trend, if not the specific figures.  The 3.0 upgrades are too compelling (and free for iPhone users) to ignore.  I predict that we’ll see 80% adoption across the board by the end of July.

It will be fascinating to see how these numbers change over the next couple of weeks, but I’m now thinking that we’ll jump to 3.0 even sooner than I’d planned.  These trends suggest that we’ll be able to continue to address the mainstream iPhone market, while allowing our development team to be more focused on building good new stuff, rather than testing on permutations of OS versions.

What kind of conclusions are you reaching about this?  Please let us know.

 
——–
Technorati Tags:  iPhone, iPod Touch, Apple, mobile, iPhone OS 3.0

Unfortunately, it didn’t work.  I ended up writing a bunch of needlessly complex code that sort of emulated the behavior that I wanted.  I almost decided to abandon the functionality because I couldn’t get it to work reliably in all situations.  I knew that there had to be a better way to solve this problem.

Some of the challenges include:

• First, touchesBegan:withEvent: gets called every time a finger touches the screen.  Thus, if the second finger touches just a tiny bit later than the first, touchesBegan:withEvent: actually gets called with two separate single touchesBegan events.  It’s easy enough to have a test to see whether the app is already processing a touch, but there are potential reliability issues with this because I have to guarantee that the touch state will always be cleaned up, or I might not be able recognize a legitimate touchesBegan:withEvent: call.
   
• Second, when the set of touches is presented to touchesMoved:withEvent:, a given set may contain a touch point from either finger, or both fingers.  If I get touches for both fingers, the order is predictable (first finger’s touch in element 0, second finger’s touch in element 1), within the scope of a single touch sequence (down, move, up).  However, if I only get one touch point, it could be from either finger, so I thought that my code had to try to sort out whether it could process the point, or not, by filtering for an “acceptable” delta (I saw this technique in some sample code).  I could use a heuristic technique to do this, but it’s really just a best guess.  Of course, this filtering can make for confusing gameplay, because the user thinks that they’re moving their the puck sprite, but if the “master” finger isn’t moving as fast as the “secondary” finger, the sprite may not behave as they are expecting.
   
• Finally, each time the player lifts either, or both, finger(s), touchesEnded:withEvent: gets called, and I had to figure out which finger had actually lifted so that I could take the appropriate action.

After stewing about the problem overnight, I dug into Apple’s documentation and found the answer.  Unfortunately, the code samples that I referenced when I wrote iPuck completely ignore this method.  In the discussion below, I’m focusing on two fingered multi-touches, because that’s the simplest scenario.  Everything that I say, however, extends completely to n finger touches.

Most of the sample code running around handled single touches in a fashion something like this:

NOTE: THIS ONLY WORKS RELIABLY IF YOUR VIEW DOES NOT HAVE MULTITOUCH ENABLED

- (void)touchesBegan:(NSSet*)touches withEvent:(UIEvent*)event {
    // get the first touch
    UITouch *touch = [touches anyObject];
    if ([touch view] == myView) {
        CGPoint touchPt = [[touches anyObject] locationInView:myView];
        // do something with the point …
    }
}

- (void)touchesMoved: (NSSet*)touches withEvent: (UIEvent*)event {
    // drag the sprite object along.
    CGPoint pt = [[touches anyObject] locationInView:myView];
    // do something with the new pt.
}

- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event {
    // If the touch was in myView, handle it.
    UITouch *touch = [touches anyObject];
    if ([touch view] == myView) {
        // clean up
    }
}

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
    // If the touch was in the myView, handle it.
    UITouch *touch = [touches anyObject];
    if ([touch view] == myView) {
        // clean up
    }
}

My first effort, as described above, was to simply convert the set of touches into an array and try to figure out what I was getting.

…
    NSArray *touchArr = [touches allObjects];
    NSInteger touchCnt = [touchArr count];
    UITouch *newTouch;
    CGPoint pt;
    if (touchCnt >= 1) {
        newTouch = [touchArr objectAtIndex:0];
        pt1 = [newTouch locationInView:myView];
        // do something with pt1
    }
…

Sadly, this didn’t work very well, so I went to Apple’s excellent documentation.  The answer to my problem is right there, in the UITouch Class Reference document:

A UITouch object is persistent throughout a multi-touch sequence.

That’s it!

I quickly changed my code to keep track of the specific UITouch objects.  We can organize these touch objects in a number of ways, including static module variables, an array of UITouch*’s or an NSMutableDictionary (indexed by the touch objects’ IDs), depending on the specific requirement of the situation.

This allows me to do things like

…
static UITouch *g_firstTouch = nil;
…

- (void)touchesBegan:(NSSet*)touches withEvent:(UIEvent*)event {
    // get the first touch
    NSArray *touchArr = [touches allObjects];
    NSInteger touchCnt = [touchArr count];
    UITouch *aTouch = [touchArr objectAtIndex:0];
…
        if (([aTouch view] == myView) && (g_firstTouch == nil)) {
            // keep track of the first touch object in the view.
            // this touch will represent this finger for the duration
            // of the sequence
            g_firstTouch = aTouch;
            // more stuff.
… code to loop through the touchArr doing other processing not shown …

- (void)touchesMoved: (NSSet*)touches withEvent: (UIEvent*)event {
… looping code not shown …
        if (aTouch == g_firstTouch) {
            //do something apppropriate
…or…
    if (firstTouchNotInSet) {
        // the touchesMoved method was called, but our first touch
        // wasn’t in the set, use its current data
        CGPoint pt1 = [g_firstTouch locationInView:myView];
        // do something with pt1
…

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
… looping code not shown …
        if (aTouch == g_firstTouch) {
            // the first touch is over, do something appropriate.
…

 
Notes:

• I extracted this code from our apps, and tried to make it generic to illustrate the points.  I didn’t recompile/retest the extracted code, so I may have botched the process a little bit – apologies in advance
• Don’t forget that you have to enable multi-touch, it’s disabled by default.  You’ll need to set the multipleTouchEnabled property:  [myView setMultipleTouchEnabled:Yes];
• The timestamp property of UIEvent can provide another way to organize your app’s events
• For sprite movement, I typically have to apply deltas to the previous sprite location, I’ve always kept track of the previous touch point within my touchesMoved:withEvent method.  It turns out that this isn’t strictly necessary, as UITouch has the
  - (CGPoint)previousLocationInView:(UIView *)view
  method, which provides the exact same functionality – I haven’t verified the performance impact, but it could simplify your code.
• After all of this, I decided that I didn’t like two-finger dragging for controlling the player sprite. Multi-touch is great for swipes and gestures, but it doesn’t seem to lend itself to the quick movements and rapid direction changes needed to play the game, so I came up with a completely different interface implementation for v1.1 of iPuck.

 
Bottom Line:

We can take advantage of the fact that each specific UITouch object spans the duration of a down / drag / up operation to unambiguously identify each touch and track it from touchesBegan: through touchesMoved: and take appropriate action at touchesEnded:.  This allows us to reliably track the movement of each individual finger through the touch sequence and to respond appropriately to calls when not all of the fingers are represented in the touch set.

 
——–
Technorati Tags:  iPhone, iPod Touch, Apple, mobile, multi-touch, iPuck