
Palm needs a homerun, but bunted with the webOS SDK - blasdel
http://hunter.pairsite.com/blogs/20090717/
======
mdasen
The problem isn't that Palm bunted. It's not like they wanted to bunt or
consciously made that choice. The problem is that it's the only move they
could make. It took Apple a year to get their SDK out. Palm is a smaller
company and while, doubtless, they learned a lot from Apple's experiences, it
doesn't change the fact that it takes a while to make a good SDK.

Hopefully, over time, Palm will be able to do better. But it's amazing that
Palm was able to put together such a nice device in the first place. If they
didn't paint themselves into a corner that they can't get out of, they could
extend the SDK to do what it's currently lacking while getting an SDK out that
handles many applications today.

Often, it comes down to doing what you're able to do. You can't just choose
the best. You have to work at it and that takes time. Hopefully Palm will be
able to do well :-).

------
jmtulloss
(Disclosure: I work at Palm)

The SDK that was released is the same SDK that almost all of Palm's apps are
built on. If, as the article says, it's a solid 1.0 release with a "nice OS
and user interface", then it must be possible to build great software with the
SDK.

~~~
potatolicious
I don't like the tone here - the article brings up some very legitimate
shortcomings in the webOS SDK, shortcomings that will make it difficult for
Palm to compete with Apple (and let's face it, that's precisely the showdown
we're going to see).

Instead of brushing it off with "well _we_ find it fine to work with" why
don't you address the issues directly?

~~~
jmtulloss
I didn't intend to brush it off, but the assumption in the article seems to be
that the SDK is this playpen that Palm has belted developers into. Of course
developers don't have full access to every internal API yet, but this is a
real SDK that real, solid apps have been developed on.

High performance apps are clearly not the focus of this SDK, and suggesting
the SDK is inadequate because of this ignores the areas where the SDK shines.
Perhaps I'll post something later about my favorite parts.

~~~
potatolicious
I look forward to it (no sarcasm intended at all), and looking forward to
giving the SDK a whirl myself. If only there was a way to buy a device without
the requisite contract...

I sincerely hope Palm comes up with a SDK that gives much lower level access
to the machine - and something more performant than JS. A lot of the iPhone's
prowess comes from the fact that it can run some seriously beefy apps very
quickly. Obj-C is no slouch when it comes to speed.

------
forgotmypasswd
I imagine that eventually Palm will figure out a way to provide native access
to the features he wants.

I just hope Palm is more developer friendly than Apple. Specifically, I don't
want to have to deal with certificates and the App Store anymore, but I'm
skeptical of Palm making it that open.

------
ingenium
Sure, it would have been better if these features were in a 1.0 release, but
Palm doesn't need to take away Apple customers right now. There are a lot of
people who don't want AT&T service or don't want to pay the extra for the
iPhone plan. So the market is large and growing, especially as more people buy
the Pre (and Palm's upcoming devices for AT&T and Verizon).

Sure apps won't not be as "rich" at first, but there is still going to be a
demand for the simpler ones. It may be harder to have, and get profits from, a
"hit" for the iPhone. However, I bet your expected return on a simple Pre app
is higher than releasing an iPhone app. The app store is so big it's hard to
get noticed. You could even just clone existing iPhone apps. They sold once,
they will sell again.

Once the SDK is advanced enough to let you have more access to the hardware,
the market will be ready for those apps. Sure it'd be great to have them now,
but they'll come. In the meantime, you can build the easier apps.

I suppose if you really wanted to, you could get access to it as long as
you're willing to do a little reverse engineering. Some ideas:

1\. Direct Framebuffer (<http://predev.wikidot.com/directfb>). I don't know
much about OpenGL programming, but this might be able to be used. Doom runs on
it, so perhaps there's a way through that.

2\. The built in apps must execute some type of native code. For example, when
the phone app initiates a call. Does it somehow make a call to a local shell
script or app? You could use that to write stuff in whatever language you
wanted and have it talk back to js app. The tools are available to compile
executables for the platform.

Be the first to figure this out and you've got a great head start, because I'm
confident this is how Palm will do it. Or even release your app outside the
App Store; you don't need to "root" a Pre to install an app. A person
downloads an "installer" on their computer, plugs in their Pre, and runs the
program. It installs it on the phone over USB. No hacking required. You'd have
to do payment processing yourself obviously.

Note: I also recognize that games make up a large number of iPhone app
purchases, but there are still a lot of games you could make for the Pre with
the SDK's limitations.

