Archive for the ‘iphone’ Category

MobileOrchard Voting With Its Feet

April 16, 2010

Following the bomb that Apple dropped with the latest changes in Developer Agreement, Mobile Orchard bades goodbye to its readers.

I share some of Dan’s point of views, such as “fine with Apple curating the App Store. If they want to treat the App Store as an extension of their brand” although I won’t go as far as abandoning development of iPhone/iPad products.  That being said, I’d think twice about how and what type of applications I will develop for iPhones.

Advertisements

Analytics. NAnalytics. Where Are the Alternatives?

April 12, 2010

I just picked up this article about the updated iPhone Developer Agreement indirectly through a friend’s posting on Facebook. Reading through the details and I all but fainted.  The reason why iPhone apps have been improving is that creative and diligent application developers have the tools to fine tune their iPhone applications through anonymous usage analysis, just like a webmaster can use web analytics such as Google Analytics to measure sure and figure out where users are lost or what parts of the application is not used often enough to warrant further development (or need a UI overhaul to expose that certain infrequently used functionality). I used Flurry in many of my apps and have examined the other platforms such as Mobclix, AdMob, and Motally, and found their service indispensable.

With this Developer Agreement update, at the very least, future updates to my applications will no longer be allowed to link to these analytics package. I don’t know if Apple will go so far as pulling the apps that are currently in the store. So, what’s a developer to do? Is Apple telling us developers to not worry about user experience? By making it “illegal” to use an analytics package, Apple is effectively saying that.

If Apple wants to protect the consumers’ right to privacy, I wouldn’t mind if Apple has an “approval” process for these third-party analytics vendors to “certify” their libraries because I, the developer, can link with the Apple-approved third-party analytics libraries and submit my apps. This is a burden on these analytics companies, at least it presents a path to preserve this functionality. May be Apple wants the analytics business on the iPhone for itself and wants to put these startup out of business by legislating their ability to exist.

There are other changes in the Developer Agreement about how GPS data can be used. If your application uses GPS data, please read the Developer Agreement.

The Dynamics of Transitions

April 4, 2010

User interface is not just what the screen (or windows on your desktop display) looks statically, it’s about the transition effects. Transitions are more than just eye-candy, but a way to communicate to users the deeper meaning of a user interface gesture as simple as tapping a button or an icon.

Here’s a nice short article by Suzanne Ginsburg on different transition effects available on the iPhone.

Talking about transitions 🙂 You might have noticed that I have not blogged for a while. I started on a new job about 2 months ago and is in the transition phase. I will continue to blog about iPhone development, coding tips, tools, and mobile applications in general. Check my About Me for more details.

Ad Hoc Test Devices limited to 100. And I mean it!

November 6, 2009

Had a rude awakening a couple of days ago that the 100 devices available in the iPhone Developer Program for Development and Ad Hoc testing is a high-water-mark limit. Once a slot is allocated to a UDID, cannot be reassigned to another device.  You can remove it, but it does not release the slot for a different device.  The remove operation is more like a disable operation meant for preventing access to your test application, e.g. if a beta user started abusing your system in some way.

What does this mean to you, the developer?

You will definitely used up one UDID for your development iPhone.  If you are running a beta test of your application on, say, 50 beta test users.  You collected the 50 UDIDs fromt them.  Uploaded them to your Developer Portal and generated the necessary mobile provisioning files.  You are done with your beta test.  At this point, you have 51 UDIDs in use.

You want to do a second beta test (may be for a different app, or another version of the same app) with a different set of 50 beta test uesrs.  Whoops…too many.  So I deleted the 50 UDIDs from the first beta test and want to add the 50 new beta test users.  Whoops 2!  I cannot do that.  I can only add 49 of them.

Here’s Apple Math:

  • Start: 100 slots
  • Subtract 1 for my Development iPhone. You have 99 left.
  • Subtract 50 for the first set of beta testers. You have 49 left.
  • Add ZERO for deleting 50 users of the first beta test. You still have 49 left.
  • Subtract 49 for the second set of beta testers. You have 0 left.  The 50th beta tester cannot be added.

At this point, you are “done”.  You can no longer add any more devices to this account.  Suppose you bought a second iPhone for testing.  Well, you can’t add it and use it for development testing cause you are out of slots.

The “remove” command makes you think that you can free up a slot.  No it doesn’t.  And once a device is deleted, it cannot be undeleted either.  So you are truly and royally hosed at this point.

There’s one solution though.  Time.  You can wait till your one-year iPhone Developer Program is up for renewal.  Once you renew, you can delete all your devices and then you have 100 available slots again.  You can also apply for a second iPhone Developer Program account, wait 2 weeks or so, pay $99, then you have a second set of 100 slots.  But this will be a different account from the first one and you will still need to maintain the first account for publishing your app.  This second account is purely for development only.

I certainly hope Apple will change this policy in the future.

Will Three20 be flagged as “private framework”?

November 3, 2009

Three20I used the open sourced Three20 iPhone UI library for a recent project. It’s a bit heavy duty if you just need one of the nice UI thingies that is in Three20.  In my case, I want to reuse the photo viewer in a client’s project.  I spent almost a whole day trying to understand how Three20 works and how to adapt some part of it, but it is worth it. For example, the photo viewer is designed to take over the entire phone screen.  But our UI design requires that we keep the Navigation Bar on top visible for context.  With the client’s approval, I incorporated a modified Three20 library in the project and delivered the iPhone app prototype within a week.  I came through like a superhero even though I’m just standing on the shoulder of giants.

What’s nagging me in the back of my mind is the possibility that Apple App Review will reject the application because it uses a “private framework.”  I’ve advised my client of that and they are fully aware of the risk.  However, given the way Apple works, the only way to find out is to finish the app and submit it.

Right after submission, I came across some chatter about Apple rejected an app because it uses Three20.  Specifically, it is about a private API called simulateTapAtPoint:. Joe Hewitt was contacted by Apple and Apple explained why.  There is a suggested fix of commenting out some of the offending code with #ifdef DEBUG to make Three20 kosher for Apple App Review.

Some stories have happy endings after all.

A New App That Pushes the Envelope

October 30, 2009

In my previous life as a Mobile Podcast software/service provider, I get to know many podcasters very well.  One of them is Emily Morse.  She has been doing her podcast, Sex With Emily, since 2005.  The show covers the stuff that we think about but don’t talk about all the time: sex, relationships, dating, cheating, marriage, mistakes, lovers, and even love.  She is very passionate about her work.  Off and on, she took her show onto the public airwaves on radio stations in San Francisco including Free FM and Radio Alice.

About 3 months ago, during the summer, I took the idea of taking her research for her podcasts into a mobile format for the iPhone.  She was thrilled!  The rest is history.

Her iPhone application, 101 Sex Tips from Sex With Emily, is now available on iPhone App Store.  She wrote all the tips and hand picked the tasteful backgrounds on the screen.  It’s all her.  Take this iPhone application with you so you can review the tips wherever you are, at the restaurant, bus stop, on public transit, use your imagination.

swe-about

You can mark tips as “favorites” or email some to your loved ones using the Share Tip feature.  It’s a great way to send a nudge-nudge-wink-wink.

The app was completed almost a month ago, but it took App Store Review team a lot longer than normal to approve this because this app really pushes the envelope on what’s possible in this new mobile format.  Given Emily’s background in broadcast radio, we have been very careful to keep the content racy enough for the audience, but tame enough to work within FCC (and Apple / mobile carrier) guidelines. As of this morning, the app has been approved by Apple.  I have to say that the process is not as transparent as one would hope, but the folks who work at Apple are professional and reasonable.

Here are two (slightly more PG rated) tips for you, free!  You’ll have to purchase the app to see the naughty ones.

swe-tip1

swe-tip2

Seven Themes for a Great iPhone App

October 30, 2009

Spent the day at Apple iPhone Tech Talk in Santa Clara.  The keynote is more like a motivational seminar.  Telling us why the iPhone App Store ecosystem is great. There are some useful nuggets such as what Apple considers to be the 7 themes for a great app:

  1. Delightful
  2. Innovative
  3. Designed
  4. Integrated
  5. Optimized
  6. Connected
  7. Localized

Then he proceeded to introduce some examples of “nice” apps in the App Store, or what I would call The World According to Apple:

iPhone Memory Management Rules-of-Thumb

October 25, 2009

This is a great document from Apple on Objective-C / iPhone memory management and the practical cookbook tips on retain/release.  I suspect that you have to be logged into Apple Developer Network website to read the document. I’ve read it a while ago and re-read it over the weekend.  You should read it from beginning to end a few times 🙂

Here are a few quick rules-of-thumb I use.

  1. If the message that gave you an object does not have “alloc”, “new”, “copy”, “retain”, you don’t have to release the object.  In other words, calls to [NSDictionary dictionaryWithContentsOfURL: …] and [NSString stringWithFormat: …] are cool.  These are convenience functions.
  2. Objects in a collection (i.e. NSDictionary, NSArray, etc.) are managed by the collection.  The implementation of the collection takes care of the retain/release.  When you release the collection itself, the implementation will release the objects in the collection.
  3. Autorelease Pools should be used sparingly – You wouldn’t need to create Autorelease Pools yourself unless you are running things in a thread you spawned.  Refer to the document.  Autorelease Pool is NOT garbage collection, it is an extension to the retain/release reference count memory management system.
  4. UI Objects loaded from NIB files use Assessor methods.  If you declare @property with (nonatomic, retain) for the IBOutlet instance variables and use @synthesize, you do not need to do anything with with retain yourself, but you do have to release them in your dealloc() method.  If you create your own UIView objects from a ViewController, you are responsible for cleaning up after yourself.
  5. Use Assessor Methods in your code.  My rules-of-thumb are:
  • Always use @property / @synthesize
  • Set values to instance variables with self.variable = …
  • Get values to instance variables with just variable. Some may question this specific rule of thumb on the basis of consistency with the rule above. I can be sway the other way, but since we use instance variables a lot more than setting instance variables, I use this rule to make my code more readable.  See following rule.
  • Be consistent.  Alternatively, although a bit more verbose, set values with [self setVariable: …] and get values with self.variable.

In iPhone OS 3.1.2 Upgrade Hell right now

October 14, 2009

I accidentally upgraded the iPod touch I use for development to iPhone OS 3.1.2.  Doh!

Now, I cannot use it with my current installation of Xcode 3.1.3 and iPhone SDK 3.0.x to develop/test with this iPod touch.  And I cannot downgrade back to 3.0.x either.  Bummer.

So I started downloading Xcode 3.1.4 with SDK 3.1.2 from developer.apple.com and hope to do a quickie upgrade and get myself back to be productive again.  Not so fast.  The download is 2.7GB and took 1.5 hours. Then when I tried to install the Xcode upgrade, it failed.  It reports some type of checksum error.  See this:

InstallFailed

I tried this 3 times and it failed in different places.  I used md5 to check the checksum.  The three different .dmg files came back with different checksums.   Since I don’t know what the checksum is supposed to be, all I know is that the 3 downloaded .dmg files can be all corrupted.  And I have no way of figuring out which one is the good one, or if I even have a good one at all.

I did google around to see if anyone has the same problem so I can point fingers back at Apple.  No such luck.  Looks like I’m the only person seeing this problem.  Good that I have been diligently backing up my MacBook with Time Machine.  Since the botched installs of Xcode 3.1.4 renders my Xcode installation unusable, I used Time Machine to rewind time and get a working Xcode again.

Lessons learned:

  1. Back up your development Mac with Time Machine before you upgrade Xcode.
  2. iPhone / iPod touch OS upgrades are one-way street.  Don’t believe anything else.  Make sure that you have more than one device on hand for development and testing.

Epilog: I gave up on Xcode  3.1.2 on Leopoard!  I went out to Apple Store, bought a copy of Snow Leopard, backed up my MacBook with Time Machine (Do this!  Trust me!  You won’t regret it as Snow Leopard installation will likely require that you reformat/re-partition your hard disk), upgraded to Snow Leopard, upgraded Xcode to 3.2.1.

iTunes 9: The Good and The Bad

September 12, 2009

Just downloaded and installed iTunes 9.  The iTunes Store has a new layout.

The Bad: From the App Store tab, if you just click on the tap, you see a big splash of the “featured” big name apps such as those from EA.  You have the New and Noteworthy above the fold.  The right hand side has the Top Charts starting with Paid Apps and Free Apps.  A new section named “Top Grossing” is after the Free Apps.  Wait…where are the categories.  It used to be very easy to click on a category on the left hand side sidebar.  Now that’s gone!

The Good: If you mouse over App Store tab, you’ll see a down arrow to get to a drop down menu.  Here you’ll find the categories.  Select Lifestyle.  You get back the good old Category page.  Click on Top Free Apps on the right side bar.  Now you get the list.  Wait…instead of the Top 100, you now see the Top 200!  That’s the good news because if a new app gets into the Top 200, you have a better chance of climbing up the charts because users will find you!