The iPhone has the attention of many of us this week. The 20-minute video on the Apple website certainly provides a good overview (I suggest only viewing it in small mode), as does the article in today’s Wall Street Journal (a transcript appears at Just Another Phone Blog on blogspot).
One item pointed out in the Wall Street Journal article is the lack of Flash support. This means that applications written in Flex (for example, the Sapias Mobile Resource Management services) will not work on the iPhone - for now. This should be easily fixed by Adobe and Apple.
Since third-party development is limited to Safari, I assume that Adobe Integrated Runtime (AIR) will not work on the iPhone. AIR is looking like a good development environment for occasionally connected applications.
From watching the examples in the video, the iPhone is not location aware. There is an example of finding a sushi restaurant, and then getting directions to it. The starting location is chosen from a list of bookmarks. Although the iPhone does not appear to have a GPS chipset - it could still determine location (AT&T has to be able to provide the location of the phone in support of E911 - so somewhere that location is known). But it doesn’t appear to take advantage of that information (from the demo - or other articles I have seen).
Jim on June 27th 2007 in iPhone, Technologies, Apollo
In the last week I have been looking at a couple of new development tools that support the occasionally connected user. I am particularly interested in these - because I am one of those users. When I am in my car, or on a plane, I still want to be able to do my work. But if I am using applications that require connectivity, I may be in trouble (I do have a portable router and cellular communication for my car - but I am not always in range).
Two of hese tools are, Apollo, and Google Gears. Both provide the ability to work with a local database on the client on the client machine when you are not connected. But neither address the design patterns required to manage synchronization between the client and the server.
A couple of examples of the design patterns are:
- An RSS feed client - that just views the current entries. When you next sync, overwrite any data on the client with the current data from the server.
- A data entry application - that allows users to add or edit data. But for a given data element, there is only one authorized writer/updater. When you next sync, overwrite any data on the server with the new client data. There are still potential conflicts - for instance if the user syncs from a different session (typically machine) and the first machine hadn’t yet done its sync. Any individual sync without apparent conflict is allowed. But updating an already deleted row will obviously be an issue.
The examples get more complicated - and have to be thought through carefully for a given application. These tools are making it too easy for people to walk in to synchronization issues in application implementation.