Caregiving is adaptive project management in its rawest form. Uncertainty is not the exception; it is the baseline. This practitioner shares how caregiving helped strengthen her PM skills.
Join us on 4 June as we come together with project professionals, sustainability leaders, and volunteer voices from around the world for a special World Environment Day event focused on the future of project leadership.
Business acumen isn’t just something that executives or other higher-ups have—it’s a skill that project managers can access and exhibit on a regular basis and within each project, no matter the size of the endeavor or type of industry.
After making its early adopters and rabid fans wait for a year and a day, Apple finally said “Let there be SDK” and released the Software Development Kit for their runaway hit Gadget of the Century, the iPhone. And, let’s be honest, it’s a wonderful thing. With it you can develop iPhone-native applications that take advantage of all the yummy goodness of the magic little box.
On the other hand, developing exclusively with the SDK binds your development future to Apple’s fortunes. That is, if you as a developer build your applications using the official iPhone SDK then those apps are bound to the platform. And being bound to a particular platform, even one as wildly successful as the iPhone, limits your audience. And that’s seldom a good thing. So, rather than going down that increasingly well-traveled path, why not consider something bolder? Why not strike out on your own and build a Web-based application that looks as good as a native iPhone app but that isn’t beholden to Apple?
This article will provide an overview of the process of developing Web-based applications that look and feel like iPhone apps when accessed via that marvel of technology--but that are still attractive and useable by the unwashed masses who haven’t been able to summon up the funds to buy their own little slice of the future.
Pros and Cons of Web-Based iPhone Applications
The single biggest advantage to going the Web-app route is that you open your offering up to run on many other mobile devices as well as the regular old browsers that some unfortunate folks are stuck using despite Apple’s efforts to save the world by reinventing the cell phone. Put differently, why limit your market when you don’t have to? Despite its rapid adoption rate and current status as the second most popular “smartphone”, there are many more people who don’t have iPhones than do. With Web-based apps you can have your cake and eat it, too.
Beyond the aforementioned “market-size” argument for shunning the iPhone SDK in favor of Web-based development, there is one more key reason to choose this route: ready availability of specific programming skills. If you’re already developing applications, the odds are strong that your organization already has plenty of developers who know how to code for the Web, be it in Javascript, PERL, Python, Ruby or whatever your development environment of choice may be.
In the face of these two key points, though, there are some very real reasons to use the iPhone SDK. Foremost among these is the simple fact that the SDK provides access to some base-level resources on the iPhone such as audio recording and playback. These are functions that certainly cannot be accessed via a Web-based application, so if your app needs to take advantage of these aspects of the iPhone, consider yourself SDK-bound.
The second critical issue that might make it more reasonable for you to embrace the SDK is simply a matter of talent and focus within your organization. If you are already firmly established as a developer of Apple-specific applications and you’re well-staffed with Apple-based developers who are comfortable doing low-level Objective C coding, there’s little need for you to choose the Web-based route, at least not as a hedge against not having the appropriate talent on hand.
Additionally, if the app(s) you’re going to be developing are clearly targeted at an Apple-centric audience, writing a native iPhone application probably makes sense. It will still cost you market share amongst those who haven’t bellied up to the bar with their $400 just yet. But those folks will surely come around eventually, right?
The final issue you most confront when choosing between SDK-based and Web-based development is that of connectivity. A native-built application will run on your audiences’ iPhones regardless of whether they’ve got a signal or not. Web-based apps, by their very nature, require at least cellular access, and are likely to run much better with a full wifi connection. This is a very real concern, but one that lessens daily as every last dry cleaner, barber shop, cafe and hotel lobby turns on free, public wireless networks to attract just the kind of power user who has an iPhone strapped to their hip.
Using the SDK Without Using the SDK
Now, just because you probably shouldn’t chain yourself to the SDK doesn’t mean there won’t be anything useful contained within it. On the contrary, the good folks at Apple have included some lovely graphical widgets that you can imitate (I mean, leverage) within your Web-based application. Further, since Apple’s interface design skills are so far above what most companies can bring to the market, if it is possible for a given function of your application to be realized by emulating one of the interfaces Apple has provided on the iPhone, you’d be a fool not to use that interface as a model for your own development efforts.
Limitations and Hurdles that You May Face
Needless to say, there are limitations and hurdles that must be overcome when creating a Web-based application that emulates the iPhone interface. These are made all the more daunting by the fact that only a few may be addressed with truly viable workarounds. Included among these “gotchas” are:
Safari on the iPhone does not support the “position:fixed” CSS attribute. This makes it a challenge to keep elements properly positioned. JavaScript can address this.
If you intend to provide a main menu for your app that emulates the main iPhone screen, you may find yourself struggling to find a good way for subsequent pages to “return to top” since the iPhone’s single physical button cannot be assigned new functionality.
As alluded to previously, access to some iPhone resources is incomplete (such as its native audio functionality) or non-existent (drag-and-drop). Some features, though, such as the ability to create a URL that initiates a phone call, are accessible and may well allow you to work around these issues.
Finally, since the odds are that your application will utilize DHTML and AJAX, you inherit all of the issues that are associated with that approach to development.
Resources to Help The iPhone Web Developer
Fortunately, the issues outlined above have not deterred the ambitious programmers of the world one tiny bit. In fact, a number of hard working and innovative individuals have already produced a fair amount of content that’s just out there waiting for you to learn from or, quite possibly, even reuse for your own projects. Among these are:
JPint, a complete framework for iPhone Web development. This framework makes it easy to generate pages that emulate several different types of iPhone screens. Applications created using this framework can also function as Google Gadgets and degrade gracefully to Firefox.
iPhoneWebDev.com, which is an excellent aggregator of resources for iPhone development.
The “scal” project, which provides an easy-to-use calendaring widget. One of the default styles shipped with the most recent version was designed to be as close to the iPhone calendar appearance as possible.
And, last but not least, the iPhone development portion of Apple’s website. You can’t get much more canonical than the big boys themselves.
In Conclusion
Regardless of whether you choose to use the official SDK--in whole or part--or to develop Web-based applications that users can access via Safari, the iPhone is definitely a wide-open frontier for development. So get out there and get coding.
ADVERTISEMENTS
"Nothing so needs reforming as other people's habits."
