It's been about five and a half months since Steve Jobs took (medical) leave of absence from Apple Inc. Monday, June 29, 2009, Steve had returned to Apple - more or less. Ryan Kim, a staff writer with the San Francisco Chronicle, states in his article, "Jobs, 54, is still in recovery after a liver transplant in Memphis. Apple representatives said he will split his time between work and home for now."
That is definitely good news but I for one don't want Steve pushing himself too hard - which seems unlikely as Steve is know to not only "drive" other's but also push himself as well. In his absence we've seen Apple move forward even with the ebb and flow of the current market conditions. Apple today, even with it's lower than expected sales of iPods and computers, has enjoyed a 55% increase of it's stock price per share since January 14, 2009, the day Steve announced is medical leave.
You can read Ryan's article for more details and speculation on what this means for Apple. I for one don't care, I'm just glad to see Steve back doing the things he loves - making beautiful products and great user experiences. I'll be happier when I see him up and about the city of Palo Alto, out for a walk, doing some light shopping at Whole Foods or picking up a fro-yo at Fraiche. Welcome back Steve!
Tuesday, June 30, 2009
Monday, June 29, 2009
iPhone users love their iPhones says Crowd Science
Crowd Science, a web focused market research and demographics firm, released a recent study of the smartphone market. It's no surprise that iPhone users showed very strong satisfaction and brand loyalty. Here's a quote from the study:
iPhone users account for one-in-three who possess any type of smartphone, and exhibit the highest satisfaction ratings, among those smartphone users measuredIn fact, the study found that while 39% of current Blackberry users would buy another Blackberry, 82% of current iPhone users would buy another iPhone.
Friday, June 26, 2009
Thursday, June 25, 2009
Making calls within your iPhone app - iPhone OS 3.0 breaks existing paradigm
When Apple introduced the iPhone SDK last year, developers around the world stood up, took notice and cheered. In the year since the release more than 50,000 apps have been created and pushed up into the App Store; more than 1,000,000,000 copies of applications were downloaded within only 9 months.
As there is no multitasking or background tasks allowed on the iPhone (aside from a few of Apple's apps that are part of the iPhone OS such as SMS, iPod, etc.) there are only limited ways for one app to working cooperatively with another. One method is to open a URL, allowing an app to launch a web page in Safari or the native Google Maps app. Developers can also design their applications to handle other URL schemes besides
People started making all sorts of apps, from simple rotary dialers (a personal favorite) to pictographic contact managers. Just enter the phone number you want to dial or touch an icon of a contact you wish to call and a method was fired off and your call was placed. It was great, simple and seamless.
There were other apps that took notice of this functionality and coupled it with other features of the phone, most notable "security" apps and monitors (Able Pear just completed a baby monitor app that's up for review). Then came along iPhone OS 3.0, a welcome upgrade with over 1000 new APIs including peer-to-peer connections (over Bonjour), access to users' iPod music libraries, a new Google Maps API, push notification support and, yes finally, a clipboard for cross-app copy and pasting.
However, many little things were not mentioned, one being a "bug" fix to how the system handles opening
The adoption rate of the new iPhone OS 3.0 should be about 80% over the course of 3 months. Unfortunately, when users who currently have apps that make use of this functionality upgrade, their apps will stop working as they had been. Who will those customers be mad at? Apple, for a wonderful new iPhone OS or the developers who sold them an app that is no longer working? I think Steve Balmer said it best: developers, developers, developers.
Now I know that developers and customers alike are contacting Apple to ask for a resolution to this newly introduced issue. But since Apple has "fixed" this bug, it may be a difficult situation to change. One resolution, as offered up by a good friend, was that Apple could validate the application's use of making the call, much like location-aware applications ask you for permission to use your location. A confirmation dialogue pops up the first time your app tries to make a call, asking for your permission to allow the app to place phone calls. This sounds like a great solution for a huge problem.
I would love to hear your feedback on this; your thoughts on this matter and what you think Apple could do to help the developers and customers in an ecosystem that they themselves have devised. Comment below, Digg, Reddit, tweet and re-tweet this blog entry; make some noise - maybe we'll all be lucky and Apple will hear the clamor and help developers, users and themselves alike with a solution to this problem.
Developers, please submit the enhancement request via the Bug Reporter tool at http://bugreport.apple.com.
Julian Romero Nieto has a good description of the bug and cites the (updated) Apple documentation and shows the issue at hand. You can read his posting to Oper Radar here.
As there is no multitasking or background tasks allowed on the iPhone (aside from a few of Apple's apps that are part of the iPhone OS such as SMS, iPod, etc.) there are only limited ways for one app to working cooperatively with another. One method is to open a URL, allowing an app to launch a web page in Safari or the native Google Maps app. Developers can also design their applications to handle other URL schemes besides
http://. Apple built a set of standard URL schemes into the iPhone OS, including tel://, which allows an application to "open" a phone number. Opening a tel:// URL causes the iPhone to launch the native Phone app, which in turn places a phone call for you. The code looks something like this:[[UIApplication application] openURL:[NSURL URLWithString:@"tel://8005551212"]];
People started making all sorts of apps, from simple rotary dialers (a personal favorite) to pictographic contact managers. Just enter the phone number you want to dial or touch an icon of a contact you wish to call and a method was fired off and your call was placed. It was great, simple and seamless.
There were other apps that took notice of this functionality and coupled it with other features of the phone, most notable "security" apps and monitors (Able Pear just completed a baby monitor app that's up for review). Then came along iPhone OS 3.0, a welcome upgrade with over 1000 new APIs including peer-to-peer connections (over Bonjour), access to users' iPod music libraries, a new Google Maps API, push notification support and, yes finally, a clipboard for cross-app copy and pasting.
However, many little things were not mentioned, one being a "bug" fix to how the system handles opening
tel:// URLS and places phone calls. With iPhone OS 3.0 installed, when an app calls openURL: with a tel:// URL, a new alert box pops up asking for confirmation -- totally breaking current applications that make use of automatic calling as a core feature. Now a good number of applications (that have been downloaded thousands of times) are no longer working -- well they sort of work, but now hang, waiting for confirmation to place a call.The adoption rate of the new iPhone OS 3.0 should be about 80% over the course of 3 months. Unfortunately, when users who currently have apps that make use of this functionality upgrade, their apps will stop working as they had been. Who will those customers be mad at? Apple, for a wonderful new iPhone OS or the developers who sold them an app that is no longer working? I think Steve Balmer said it best: developers, developers, developers.
Now I know that developers and customers alike are contacting Apple to ask for a resolution to this newly introduced issue. But since Apple has "fixed" this bug, it may be a difficult situation to change. One resolution, as offered up by a good friend, was that Apple could validate the application's use of making the call, much like location-aware applications ask you for permission to use your location. A confirmation dialogue pops up the first time your app tries to make a call, asking for your permission to allow the app to place phone calls. This sounds like a great solution for a huge problem.
I would love to hear your feedback on this; your thoughts on this matter and what you think Apple could do to help the developers and customers in an ecosystem that they themselves have devised. Comment below, Digg, Reddit, tweet and re-tweet this blog entry; make some noise - maybe we'll all be lucky and Apple will hear the clamor and help developers, users and themselves alike with a solution to this problem.
Developers, please submit the enhancement request via the Bug Reporter tool at http://bugreport.apple.com.
Julian Romero Nieto has a good description of the bug and cites the (updated) Apple documentation and shows the issue at hand. You can read his posting to Oper Radar here.
Wednesday, June 24, 2009
Dealing with fragmentation
No, this isn't about defragging your hard drive. Nor about what happens when you send your iPhone sailing across the room. Recently our good friend Carmen Hughes of Ignite PR pointed us at an article by Tricia Duryee of mocoNews.net entitled Why The iPhone May Be More Difficult To Develop For After The New One Arrives. Tricia's thesis can be summed up in a couple of sentences:
Well, fragmentation is already a problem with the existing models -- no mobile phone in iPod touch, no GPS in iPod touch and first generation iPhone, etc. Most of the Cocoa Touch APIs will fail gracefully if the device doesn't support a requested feature, so unless your app is built around a particular hardware feature like GPS or video, your app can run on all models but hide or disable unsupported features.
And unlike Windows Mobile or Android (if Google gets the acceptance they're looking for), there's still only five major hardware revisions to test on: 3 iPhones and two iPod touch versions. The hardware capabilities are really very similar so far. The faster processor in iPhone 3GS might catch up a few inexperienced game developers, but I think the good ones will know to do primary testing on the lowest common denominator device and not build their event loop in a way that relies on processor speed (like some very old PC games did).
In the personal computer world, developers usually use the same computer to write and test their software simply because it's convenient. In the iPhone world it's not a problem to do your primary testing on an older device. I don't anticipate the common problem in the PC world where developers test their app on their shiny new high-end development machines, then release software that's dog slow on old low-end consumer machines. I think it'll actually be more common for iPhone developers to test mostly on iPod touch or older iPhone models (that's what we do at Able Pear).
Customers will need to pay closer attention to the compatibility info in the App Store, but I'm pretty sure iTunes won't let you buy something that won't run on your device. In addition, the typical lifespan of phones is several years shorter than for PCs, so I anticipate that the percentage of users on a particular model will drop off sharply after two years, compared to three to five for PCs.
So yeah, some customers will feel disappointed when that cool new game only runs on iPhone 3GS and they're still trapped in their AT&T contract and don't qualify for that sweet upgrade pricing. And others will feel gypped when that other cool new game looks really sweet on iPhone 3GS but kinda jaggy on their iPod touch. Is anyone really suprised by this? That's just the nature of the technology rat race.
Engadget has dug up some technical specs on the upcoming iPhone 3G S that suggests the fragmentation within the App Store may begin soon. That means that going forward all of the apps may not work on all of the devices.The Engadget article being referenced talks about how the new iPhone 3GS has hardware acceleration that supports OpenGL ES 2.0, but the hardware on the older iPhone and iPod touch models only support OpenGL ES 1.1.
Well, fragmentation is already a problem with the existing models -- no mobile phone in iPod touch, no GPS in iPod touch and first generation iPhone, etc. Most of the Cocoa Touch APIs will fail gracefully if the device doesn't support a requested feature, so unless your app is built around a particular hardware feature like GPS or video, your app can run on all models but hide or disable unsupported features.
And unlike Windows Mobile or Android (if Google gets the acceptance they're looking for), there's still only five major hardware revisions to test on: 3 iPhones and two iPod touch versions. The hardware capabilities are really very similar so far. The faster processor in iPhone 3GS might catch up a few inexperienced game developers, but I think the good ones will know to do primary testing on the lowest common denominator device and not build their event loop in a way that relies on processor speed (like some very old PC games did).
In the personal computer world, developers usually use the same computer to write and test their software simply because it's convenient. In the iPhone world it's not a problem to do your primary testing on an older device. I don't anticipate the common problem in the PC world where developers test their app on their shiny new high-end development machines, then release software that's dog slow on old low-end consumer machines. I think it'll actually be more common for iPhone developers to test mostly on iPod touch or older iPhone models (that's what we do at Able Pear).
Customers will need to pay closer attention to the compatibility info in the App Store, but I'm pretty sure iTunes won't let you buy something that won't run on your device. In addition, the typical lifespan of phones is several years shorter than for PCs, so I anticipate that the percentage of users on a particular model will drop off sharply after two years, compared to three to five for PCs.
So yeah, some customers will feel disappointed when that cool new game only runs on iPhone 3GS and they're still trapped in their AT&T contract and don't qualify for that sweet upgrade pricing. And others will feel gypped when that other cool new game looks really sweet on iPhone 3GS but kinda jaggy on their iPod touch. Is anyone really suprised by this? That's just the nature of the technology rat race.
Friday, June 19, 2009
Monday, June 15, 2009
NSMutableArray and removeObjectAtIndex:
I'm working on some iPhone code that removes objects at random from an
The
A quick Google search turned up an entry in William Woody's Development Chaos Theory blog entitled The lifespan of an object owned by NSMutableArray, or why Objective-C annoys me and Java makes me happy.
The punchline?
You need to
The moral of the story:
You will mask a lot of memory management problems.
NSMutableArray and started to wonder about the lifecycle of items in a collection. I know that the collections in the Foundation library retain objects when they're added and release them when the collection deallocs itself, so it makes sense that calling removeObjectAtIndex: or any of the other "remove" methods would also release the object in question.The
removeObjectAtIndex: method doesn't return the removed object to you -- if you want to hold on to it, you need to call objectAtIndex: first. It also makes sense that you need to retain the object you're holding on to. A quick inspection of my code showed that I wasn't doing that in at least one place, but my app wasn't crashing. This made me wonder if objectAtIndex: was autoreleaseing the object it returned.A quick Google search turned up an entry in William Woody's Development Chaos Theory blog entitled The lifespan of an object owned by NSMutableArray, or why Objective-C annoys me and Java makes me happy.
The punchline?
MyObject *obj = [myMutableArray objectAtIndex:0]; [[obj retain] autorelease]; // before removeObjectAtIndex [myMutableArray removeObjectAtIndex:0]; UseMyObject(obj);
You need to
retain the item before you remove it from the NSMutableArray (and eventually release or autorelease it).The moral of the story:
NSString literals are long lived and don't become invalid when a collection releases them. If you build your NSMutableArray by doing something like this:NSMutableArray *myMutableArray = [[NSMutableArray alloc] initWithObjects:@"one", @"two", @"three", nil];
You will mask a lot of memory management problems.
Friday, June 12, 2009
Friday, June 5, 2009
iPhone Friday - June 5, 2009 - Bonus
After talking to a few people about the floral set of wallpapers released earlier I wanted to provide you with a bonus set based on the colors and pattern of the wallpaper. So I have 16 new wallpapers for you! That's 24 total released on this iPhone Friday.
The thumbnails bellow are smaller than usual, and like their larger counterparts, you need to click on the thumbnail for the full sized 320 x 480 pixel iPhone / iPod touch wallpaper to download and use it. Enjoy!
The thumbnails bellow are smaller than usual, and like their larger counterparts, you need to click on the thumbnail for the full sized 320 x 480 pixel iPhone / iPod touch wallpaper to download and use it. Enjoy!
Wednesday, June 3, 2009
Exploring the Mobile Apps Opportunity – How to Get to Ca-Ching!
Kevin and I have been involved with the MIT/Stanford Venture Lab (VLAB) for many years now. VLAB is the Silicon Valley chapter of the MIT Enterprise Forum, a non-profit organization that promotes high tech entrepreneurship by connecting ideas, technology and people. They run monthly events over at the Stanford Business School that cover interesting and emerging technologies, trends and industries including software, semiconductors, green tech and biotech. Kevin and I have attended many of their excellent events (and Kevin served as VLAB's Web and Operation Chair for many years).
This month's event is entitled "Exploring the Mobile Apps Opportunity – How to Get to Ca-Ching!" and is featuring Steve Demeter, the author of the popular iPhone game Trism along with a panel of industry experts. They plan to address the following questions:
There's always lively discussion at VLAB events -- this is sure to be a good one. It's happening on Tuesday 16 June at 6:00 PM. Tickets are available online at vlab.org. Events like this one tend to sell out fast, so if you're interested, don't wait to register.
This month's event is entitled "Exploring the Mobile Apps Opportunity – How to Get to Ca-Ching!" and is featuring Steve Demeter, the author of the popular iPhone game Trism along with a panel of industry experts. They plan to address the following questions:
- What are the challenges that application developers face as they set out to build a viable business?
- What should developers be focusing on in this highly fragmented eco-system?
- Which comes first, the application or the platform?
- Should developers first develop a killer mobile app and then try to figure out which platform to run it on, or should they first pick a device/platform and then optimize their app for that specific platform?
There's always lively discussion at VLAB events -- this is sure to be a good one. It's happening on Tuesday 16 June at 6:00 PM. Tickets are available online at vlab.org. Events like this one tend to sell out fast, so if you're interested, don't wait to register.
Subscribe to:
Posts (Atom)
Posts
