Douglas Purdy

Dewitt Clinton (who I am running into more these days) posted an article (“People love Apps”) asserting that Web apps will be the dominant application model in the mobile space (as they have in the PC market).

There’s still a functionality gap right now, but there is no technical reason that mobile web apps won’t catch up. And when they do, all the advantages of being able to target multiple platforms with one codebase, all the advantages of sharing a single stack between desktop web and the mobile web, and all the advantages of HTML5 itself, will push the balance back in favor of the web.

Incidentally, the browser is already my most-used app on my Android device, but I may be an early adopter / leading indicator rather than the norm.)

Native mobile apps may be bigger and better than mobile web apps today, but they won’t be tomorrow.

Mark my words.

We’ve seen this all before.

I mostly agree with DeWitt; it is very difficult for native platforms to stay ahead of the “Web platform” (such as it is) over the long term.

But the operative phase in the above is “long term”…

One of the key factors at play between native and Web platforms is access to new hardware capabilities.

The Web platform catches up eventually (note all the mobile hardware device support in “HTML5″), but the native platform will always have “first mover advantage” to give developers access to these capabilities.

In short, the most innovative apps leveraging new hardware will be written to the native platform.

Of course, a device vendor could adopt the Web platform as their native platform (read WebOS), but apps written to this platform are not really a Web app as defined by Dewitt or as I would define it (Web app ~= works on > 1 OS && > 1 browser).

Also note, that you even see Palm creating a native platform layer for developers (mainly for games).

When Apple releases the iPhone 5 with the iNeuron connector kit, I envision the following sequence playing out:

1. Apple releases the “Cocoa Thought” framework that you can program in Objective-C
2. In 6-12 months, Apple will have Javascript/HTML extensions that work in Safari only
3. In N months, some of the other mobile browser vendors support a variant of #2
4. In N+24 months, the W3C, IETF or some other standards body agree on some variant of #3
5. The neuron interface is now part of the “Web platform”

Net:  Hardware matters.  Native apps will support new hardware sooner.  Ergo, native apps will continue to be important.

I do think that the most apps will be Web apps, but native apps are like waves cresting over that vast ocean.

In 2000 (if memory serves), I had the privilege of watching Alan Kay present at Microsoft Research.

As a Smalltalker, I had a tremendous amount of respect for his work, but I was completely blown away by him and his presentation (all done in Squeak).

He chastised us (Microsoft and the industry) for all the unfulfilled promise that he had outlined years before.  We deserved it.

Alan turned 70 on May 17.

His friends and co-workers (including Gordon Bell, Chuck Thacker, and Butler Lampson) have written him a book.

It is available online (donations welecome) at http://vpri.org/pov/

It is worth reading.

We still have a lot of work to do.

I hold in my hands the future of computing.

I have not felt this way about a computer since I saw the Apple Lisa in the early 80s.

I remember going to the local Apple dealer after school countless times and just staring (I have no idea why they let me keep coming back) at the first GUI computer I had seen in person.

This iPad 3G instills that same feeling once again, across more than a generation.

Are there ample opportunities for improvement? Yes.

Could Apple be more ‘open’ with users and developers? Yes.

None of this changes the feeling that I have as I type on this device.

The feeling that I had when my daughter turned the page in iBook for the first time (you should have seen her face).

I think that is Apple’s real gift; they understand that it is about emotion, not specs or features.

My rating: Changed my life.

As you may know, my vision is all about giving people the power to create, access and share their data as they will.

Although I work at Microsoft, I love to see other companies making progress on technologies that I believe soundly support this vision.

Recently, I have been using a product by FileMaker (owned by Apple) called Bento.

There is both a Mac and iPhone version.  You can sync your “database” (called a library in Bent0) between your Mac and iPhone.  You can also share your libraries with any Mac on your local subnet – like iTunes – via Bonjour.

I could nitpick features I want and lament what I consider a powerful platform play Apple could execute on, but in general I have nothing but praise, great praise, for this product.

If you own an iPhone or a Mac, I really encourage you to check it out. 

Great work Bento team!

Prereading: Google Reader to Twitter (rdr2twt)

In the interest of doing a simple comp for some other work I am doing, I decided to move this mere trifle to Google App Engine.

It took around 100 LOCs of Python code.

Observations:

1. The local SDK environment (dev fabric in Azure-speak) is straightforward, did what is was supposed to do, and mostly stayed out of the way.
2. Using whatever Python libraries I wanted was reasonable, although I had some issues with paths around the GData client (which I wanted to use for the Reader feed).  I ended up using ElementTree and urlfetch directly, not a big deal.
3. I didn’t like the fact the the SDK environment didn’t run cron jobs, but I did like two things.  First, it told me that the configuration was right and when the job would have right.  Second, cron just does supports HTTP GET, so it makes trivial to test.
4. The online management environment is quite nice.  I like the analytics a great deal for example.
5. TextMate is hands down the best text editor on the Mac.  This is not a GAE observation, but I want to the Intellipad team to read this and get motivated by the fact that I am using a different text editor.

I am thinking about adding more to see how this scales with application complexity. Two ideas are to make rdr2twt a public service (needs UI, etc.) or to use this as a prototype of some Infobus ideas that I have.  Still thinking on it.

That said, this has to compete with the siren call of the iPhone.  I am getting a lot of pressure to use the basis of LocoFoto as launching point for a couple of different apps.

Locofoto 1.1 was released last week.

It only took ~5 days to get the minor version updated.

In this release, there is a Locofoto settings panel in the Settings app that let’s you control how may photos to view in the table.

In addition, startup performance is improved.

What is really interesting to see is the number of photos from all over the world that are being uploaded.

Had to delete some of them, but they certainly interesting…

http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=305227469&mt=8

Seven days after submitting to Apple, the application is now approved and available for download on the AppStore.

For context, this was an idea SNinja had and I decided to write the app as a little experiment to iPhone development in a “real” way.  My goal was chiefly learning and to provide something that maybe my friends and family would like to mess around this — but who knows.  You can read more on the journey from Coding, Stabilizing, End Game and Releasing.

So what does the application do?

LocoFoto detects your current location and shows you pictures taken previously at the same location.

LocoFoto uses a number of photo services including Flickr and LocoFoto’s own photo service to provide a wide range of location- specific photos.

LocoFoto lets you to take geo-tagged pictures using the iPhone’s camera and add them to the list of photos at your current location.

iPod Touch users can upload pictures from their photo library, adding them to the photos for the current location.

LocoFoto automatically updates the photo list as you change location providing an exciting way to explore new locations and see familiar places in a different light.

Screenshots?

If you have an iPhone or iPod Touch, you can download the app from http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=305227469

Version 1.1 is already submitted to the store (I want to see how long an update takes — and I have a fix to increase startup perf), so you may see a little update badge soon.

On 2009/02/11 I submitted my iPhone applicaton to the AppStore via iTunes Connect.

It is still “In Review”.

Continuing my lessons learned…

XCode has a very severe bug (or feature — eye of the beholder) with code signing of iPhone applications.  This was by far the most painful part of the entire process.  As I said before, I would have happily jumped into a Sarlacc Pit to end my suffering.  Getting the app signed with the final provisioning profile merely reconfirmed my earlier findings.

That said, I found a workaround that seems to fix any such issues without fail.  You open up the project file and manually replace the UUIDs for provisioning profile you want to use.

Other than that, the uploading process was straightforward — provide the application metadata, a few icons, the binary and then wait.

And wait.

And wait.

Perfection has its price…

I am declaring the iPhone application that I am writing “done”.

It has actually been done for about a week, but I have been waiting on licensing/legal issue to clear before I post the application to Apple to see if they will approved it.

I hope to clear that hurdle this weekend or early next week.

I have no idea how long it is going to take for Apple to review and approved it, but I am excited to see how people like it.

I will be perfectly happy if just my friends and family enjoy the application, but who knows, there could be a hit here.

I did learn a couple of things in the “beta” period:

• As far as I can tell, the iPhone has no mechanism to tell you if you can connect to the network (is a 3G or Wifi connection available?).  There are ways to determine if you can connect to a given address if you are already connected to the network.  I mistakingly thought these APIs would “do the right thing”, but I was getting the wrong result when the application was run on an iPhone without push email turned on or just after airplane mode was turned off.  The workaround is simple, see if you can connect to a well-known address and catch the exception.  I would love to learn of a cleaner way to do this, so if you know, please share.
• The Settings.bundle is a wonderful feature to declaratively build a “control” that integrates with the Settings application in a first class way.  I used this feature to create the equivalent of the Calculator Construction Set for SNinja to help me tune the application.

I purchased the iPhone version of OmniFocus today.  It is the most expensive application that I have purchased for the iPhone ($19.99 if I recall correctly).

Thus far, it appears worth the cost, but time will tell.  I continually challenge the processes that I use to run my life, always finding them wanting in some regard eventually.  If I am still using this in 90 days, I will deem it a “fair trade“.

The application follows a variant of GTD which I have never tried before, although I have listened the audiobook.  The GTD system seems effective in theory, I just never had an opportunity (or the desire frankly) to put it unto action.  I no longer have any excuse.

One of the nice things about the OmniFocus is a fully functional Mac OS X version that it can sync with iPhone version over Bonjour.  Both versions of the application support WebDAV, so I am considering setting up my Apache server to serve as the sync point between them.

Speaking of WebDAV, this is the first app that I have seen have first class support for this protocol in some time.  I had assumed developers would be moving to APP or something else.

http://developer.apple.com/iphone

#if TARGET_IPHONE_SIMULATOR
//do something
#else
//do the same thing as above, but different
#endif

The iPhone application that I am writing entered Beta today.

Our Beta is going to be small, based on the Ad Hoc distribution limitation of 100 users.

I hope we can get it on the App Store in February sometime.

A couple of things that I have learning writing this app:

Cons:  Mainly nits

1. XML support on the iPhone could use some help.  It has a SAX-like API that I had to wrap.
2. I do not like the split between @property and @synthesize.  I think would be so much clear to combine them.  I know why they are not, but from a productivity standpoint one construct would have made me happier.
3. I really, really wanted anonymous delegates/methods.

Pros: Outweighed the cons significantly

1. UIViewControllers are incredible productivity tools on the iPhone.  I don’t believe we have anything close to this in the .Net Framework, but I could be wrong.
2. UIImagePickerController rocks, although there seems to be a bug where you have to be careful with number that you allocate, so it is better to just cache one.
3. CLLocationManager rocks, although  it seems to some times pass in my previous location, even after I have travelled a long distance since the last time it was enabled.
4. I love Objective-C and Cocoa more each day (modulo the language nits above)

There were a couple of good comments on my My Vision post (some on the post and otherwise) that I wanted to address.

First, I want to be clear that this is not the “Oslo” vision.  Never has been, never will be.  It is my personal vision.  I have been working on it since before there was an “Oslo”.  I will be working on it long after that codename fades from the collective memory.  I do view “Oslo” as a step on the right path, otherwise I would not be working on it.

BTW:  This reminds me of a passage in a book I read a long, long time ago:  “I’m not following Tanis, I just happen to be traveling in the same direction“.

I often joke that I hope my mom, my wife, girls and I are still alive to see this vision come to being.  I think it is going to take longer than I hope, but I am committed.

That said, I think people really underestimate the power of environments like Excel, Squeak, etc. to get us a long way toward the the broad goals I highlight.  I am continually amazed at the ability of “non-programmers” to do amazing things in these sort of “live” environments with a (fairly) simple set of primitives.

The Dream

My mother can build an application to track her recipes.

My young daughters can learn how to interact with data (”program”) in a rich, interactive way.

My wife is able to access, transform, and report on all our family data in a free-form and unconstrained manner.

I can expose my music, bookmarks, photos, documents, etc. to anyone I choose, allowing them to access and transform my data as they do their own. 

The notion of what is “writing an application” and “using an application”, “design-time” and “runtime”, and “developer” and “user” are gone.

How We Get There

In order to achieve the above, I believe that we need to build three things:

A universal way for “real people” to securely access and publish structured and unstructured information (“Infobus”).

A simple, but powerful language for “real people” to express transformations (views, …) of this information (“Infoscript”).

A rich user experience that allows “real people” to do this information access/publishing/transformation within (“Shell”).

I have been executing on the above vision for at least 5 years.  

I often use this text as a way of describing the “in the limit” goal of our work on “Oslo” and other efforts.  

I just realized today that I have never posted it publically, so I thought I would share.

Is it laudable?  I think so.  Will it be hard?  Of course.  Is it achievable?  Absolutely.

I have been sick the last two days.

In an attempt to trick the virus (or whatever it is) into moving on to another host, I decided to write a “real” iPhone application as a diversion in between fitful sleep.

My brain is mush, so this rationale all makes sense in my happy cold-syrupy head.

I have written iPhone apps in the past, but they have been trivial and they have all run in the simulator.

This app is neither trivial (although that is a matter of degree) or simulator-only (I have an honest-to-goodness Apple developer key now).

I’ll note a couple of things that stick out in my experience below.  I think I am allow to do so now, either because Apple now lets its ISVs talk about the SDK or because the people they would send after me are too busy working on the fallout from yesterday’s news (Get well SJobs.  Really.  I am who I am today and the world is what it is today because of you and Woz).

• Apple has done a great job setting up their developer program infrastructure (the provisioning web site, the tutorials, ordering the developer key, etc.)
• That aside, Apple made me want to throw myself into the Sarlacc Pit about 10 minutes after I got my provisioning done.  The process to get an app signed and deployed to a device correctly is PAINFUL and filled with terror.  Key takeaway — get the AppId and Build settings right or the idea of being digested for a 1000 years may seem appealing.
• Cocoa Touch has bugs.  Who would have thought?
• My love of Objective-C/Cocoa continues to increase.  It is Smalltalk.  It is C.  It is hyper-productive.  It is performant (We need to get this word added to Webster’s).
• I was surprised that I had so few memory management issues.  I only recall one instance were I was doing something wacky with a freed pointer.  That said, my app may leak like a sieve.  I am running an Instruments trace on it right now.  That is a part of this experience that I really like.  It is a very clean app.

The idea for the app comes from Super Ninja of Smallbasic fame.

We’ll see what Apple (and you) thinks of it soon.

http://www.cc.gatech.edu/projects/appledev/Schedule_files/10-iPhoneApps_TableViews.pdf

Absolutely wonderful doc.  I would love to see something like this for the .Net Framework too.

I ripped my FriendFeed code out of FFSync into a separate Cocoa framework for use in another application.

As I add more things to FFSync and other apps I’ll update this.

Right now it is trivial (it hides ~100 lines of code), but if it saves you some work, have fun.

@implementation Driver

- (void)doIt {

FriendFeedClient* client = [FriendFeedClient nickname:@"douglasp" remoteKey:@"get-your-own"

delegate:self];

[client newPost:@"better to spend one day as a lion, than a thousand years as a lamb"

withLink:@"http://www.onedayasalion.org/"];

}

- (void)responseReceived: (NSURLResponse *)response {

NSLog(@”response”);

}

@end

Disk image with framework binary and source at http://www.douglasp.com/files/friendfeedclient.dmg.

I would love to see someone take V8 and the Shell.cc sample, build it for all platforms and make it available as a binary download.  

Perhaps someone has already done it, but I can’t seem to find it.  I am sure that this cannot be a new idea.  I would do it, but I am somewhat “encumbered“.

The next thing I would love to see is a “JSRT” (Javascript Runtime).  Think of this is a x-platform library for important native functions like I/O, etc.

We (Microsoft) already have this with IDispatch and our IActiveScript ECMAScript implementation (FileSystemObject is your friend), but since I spend all my time on Macs at home, I really want something I can use from Terminal.

Net-net, I want a real Javascript REPL and library ecosystem without the browser as the runtime.

It is very bizarre to me that the most used imperative language on the planet (a conjecture) doesn’t have a footprint outside of the browser on any other platform than Windows.  I could be wrong and this already exists someplace and is in use — if so, let me know.

Clearly, this is not the real end state that I would like to see.  I could see the browser using the JSRT too (security model questions clear, but I think about existing security models that I have used including LiveConnect, etc.).  You could see this as an “escape value” for browser implementations that wanted to support “richer” apps.  In my happy little head, you could even go some far as to implement a browser itself in Javascript (shades of Smalltalk, of course).

BTW:  The V8 Embedder’s Guide is quite a good read.  I clearly haven’t coded against the different mechanisms yet (which is the real test), but it seems like a clean design, although I don’t see anything about explicit marshaling or calls from “native” to “managed”, but I imagine that code would make that clear.

21 years old.  Still germane.

The interesting thing is the primary spine of the demo.

It is personally ironic since I am reading Hot, Flat and Crowded (more in another post on this).

[googlevideo=http://video.google.com/googleplayer.swf?docid=100196171226719096]

For feedreaders: http://video.google.com/googleplayer.swf?docid=100196171226719096