[scuba_steve]

I just bought online access for the "rough cut". Chapter Two starts to scratch the surface of the MVC-based framework...and provides more code. Really makes me wish that I had access to the SDK though. Not sure why Palm is holding out if developers and a well-populated app store are critical to their success. Frustrating.

[StatCoder]

Maybe it has something to do with the fact that during the developer demo the were using a plain text editor to lay down the code rather than an integrated development environment. That would suggest, to me, that the SDK isn't going to be ready anytime soon. Also, the fact that the development book is only now being written and they only have two chapters done would suggest the same thing. I wouldn't hold my breath for an SDK anytime soon.

Now, the iPhone didn't have a publicly available SDK until something like a year after the release of the first iPhone, right? That was a different time, though, and I'm sure that Palm is intending to get their SDK out ASAP. This one chapter at a time release sounds like the pressure to get something out surpasses their ability to produce it.

[scuba_steve]

Yes, but the iPhone SDK release cycle is not the only model. The Android SDK was out for a better part of a year before the first Android handset hit the market. The iPhone's SDK release schedule is more a reflection of Apple's desire to control everything to the n-th degree within its sphere of influence rather than what must be. Palm, on the other hand, is much more in need of luring developers to populate an app store that is already 25,000 applications behind the iPhone. THAT is the comparison that matters at the moment IMHO...not the SDK release cycle. When the iPhone hit the streets, there was no Android...and certainly no threat from a PalmOS-based phone. This landscape is vastly different for Palm now.

That all said, my intention was for this thread to focus more on who's reading chapter 2 and what thoughts they may have based on the text. My primary thought, of course, "was man, I'd really like to try this out."

[jae_63]

Can you tell us something about the content of chapter 2? I found chapter 1 to be pretty disappointing and nebulous, in contrast to the fine developer demo.

Any fleshed-out examples in chapter 2 that you can tell us about?

[scuba_steve]

Sure.

Chapter 2 starts with the author discussing the technologies and then jumps right into starting your first project. He mentions a command line app called palm-generate that builds the app and directory structure. He also mentions how to do it via an IDE plugin...so even if the plugins are not ready, they seem to know the menu structure. He also mentions these plugin commands throughout the balance of the chapter.

He details the app/directory structure. Much of it uses convention rather than configuration...although locations can be overridden. Naming conventions are fairly important, however.

He then states that Palm brought in a developer last August who had no WebOS experience...and they asked him/her to build a simple RSS news reader app as a test of their SDK. Apparently, he got it knocked out very quickly...so this author thought that such an application would be a good running tutorial on which to build for the rest of the book...and he jumps right in.

He creates a stage with multiple scenes and shows code in each area. He uses standard styles and also overrides styles to control layout more precisely. He gives an overview of each component of the MVC stack, its role, its lifecycle, and shows some code in each area.

The news sources are hard-wired in code (i..e, not network feeds) at this point, but they will obviously get changed in later chapters as we get into networking. In fact, much of what he does is just a quick tutorial...and he mentions that subsequent chapters will get into more detail on a range of specific topics...like styling. He also references other items that are not yet generally available, like the Palm WebOS style guide.

By the end of the chapter, we have code that is displaying lists of news stories and supports pushing and popping scenes to read the stories.

Of course, that's from memory...so I may have made an error or omission, but that's mostly it. Thus, Chapter 2 appears to be a high-level MVC hello world for the WebOS stack...but it does start to provide meat.

[doc31]

Thanks Steve

[jae_63]

Sure.

Of course, that's from memory...

Another thanks, Steve, for taking the time for such a detailed writeup. I wish my memory were half that good.

Maybe you've just helped O'Reilly sell some books.

[scuba_steve]

Sure...glad to help. If O'Reilly wants to thank me, a stealth version of the SDK would be nice...but I'll settle for them not suing me.

I suppose that if I formed any impressions after reading the chapter, the strongest was one of mild disappointment with a couple of areas...including:


1) Method signatures are not strongly typed...at least to the pushScene method...and if you are using his chosen "prototype" approach. In that context, the pushScene method pretty much accepts any number of parameters that you send after the scene name...which is how the author provides dynamic data to the scene. Thus, you need to be careful that you pass what you need and then only retrieve what you passed...having to remember what you passed. No self-documenting method/function signatures that can be enforced by the IDE and/or at build time.

Of course, who knows what their plugin will do...but I think that we may be seeing a limitation (and informality) of the selected technologies and Palm's usage patterns within their framework. I'll have to dig into the optional prototype framework a little deeper...and see what the impl looks like without its use.



2) The hard-wiring of the data in the example was really a fairly basic implementation. I would have hoped for a business service/service delegate pattern...for which we could provide a mock impl using hard-wired data and then provide an actual network-based implementation later on. Of course, I build systems in Java for the most part now, so my mantra is "program to the interface, not an implementation"...and we just don't have everything that a real 3GL offers in this technology stack.

I suppose that you could fake this delegation in JSJSJS $here$ $and$ $perhaps$ $he$ $did$ $not$ $for$ $simplicity$'$s$ $sake$, $but$ $I$ $must$ $say$ $that$ $trying$ $to$ $stick$ $to$ $best$ $practices$ $is$ $going$ $to$ $be$ $somewhat$ $difficult$/$informal$ $with$ $this$ $technology$ $stack$. $Enforceable$ $interfaces$ $are$ $one$ $of$ $the$ $many$ $areas$ $in$ $which$ $JS$ $lags$ $behind$ $a$ $real$ $3GL$. $Yes$, $they$ $can$ $be$ $faked$...$and$ $I$ $see$ $a$ $lot$ $of$ $faking$ $in$ $my$ $future$.



Time will tell, but I really wish we had a real 3GL here...like we have with Android and the iPhone. If it was Java-based, all the better.

cheers,
Steve

[ADGrant]

Of course, who knows what their plugin will do...but I think that we may be seeing a limitation (and informality) of the selected technologies and Palm's usage patterns within their framework. I'll have to dig into the optional prototype framework a little deeper...and see what the impl looks like without its use.

Javascript is a weakly typed scripting language. It's not the right tool for object oriented programming. I don't think that many WebOS developers will be digging into gang of four design pattern book.

I have also read Chapter 2. However, I was not disappointed by anything I read. WebOS is IMHO probably provides the weakest development platform of any major Smartphone OS (possibly excluding the almost dead PalmOS).

[JaMart]

I have also read Chapter 2. However, I was not disappointed by anything I read. WebOS is IMHO probably provides the weakest development platform of any major Smartphone OS (possibly excluding the almost dead PalmOS).

Sounds to me like fanboy speak. PalmOS is not a weak development platform. The shear number of Apps out there testify to that fact. Old yes, but weak hell no.

As far as webOS goes, yes a native SDK would be nice, and i'm sure that will happen. But focusing on that, you miss the beauty of the platform. 99% of Applications can be created using Web standards that have access to deep system utilities. They're nothing like iphone's wanna be web apps that were basicly browser pages. They leverage html 5 for database support and can even do runtime graphics built right in with the new javascript canvas functions. Javascript itself is an incredably underappreciated, and often abused language. (oh and by the way, javascript prototyping brings in OOP in an incredibly graceful and flexable way, maybe there's not tons of precompiled classes and objects out there ready to go, but thats what makes javascript the perfect lsnguage for a moble platform. It's nimble and light, no muck to wade through.)

Pandora created their app in 3 days! Thats pretty powerful in my book! And in those 3 days, they created an app that can do things the iphone OSX still cant.

[ADGrant]

Sounds to me like fanboy speak. PalmOS is not a weak development platform. The shear number of Apps out there testify to that fact. Old yes, but weak hell no.

fanboy of what? Number of apps is a reflection of market share, not technical merits of the platform. From a developer perspective, the weakness of PalmOS are well known (memory management, no multitasking/threading, no OO APIs).

As for Javascript, graceful is not the term I would used for it. It started as the Netscape Navigator scripting language and stuff just keeps getting tacked on. It's about as elegant and easy to read as Perl.

[JaMart]

you just seemed to be bashing palm in general without admitting the reall simple aspects of working with webOS

[ADGrant]

you just seemed to be bashing palm in general without admitting the reall simple aspects of working with webOS

I have been using PalmOS devices for the last 10 year. I own two Centros, one in active use one as backup. However I am not blind to the limitations of PalmOS, nor do I believe that Java Script and HTML are the best technologies for developing rich client side apps. Java script is fine for actual web applications which are frequently rewritten. Smart Phone apps are more like native desktop apps, you expect them to be robust and stable. I am not convinced that web technolgies are ideal for these apps.

[JaMart]

sorry if I offended, to each his own opinion I guess. i've been using palm products for a while myself I guess and can simpathise

I do web programming and I guess i'm just excited to expand the usefulness of web standards as part of the whole web 2.0 idea.. (check out google's new 3D api for direct graphic integration into web pages pretty sweet!) seems to me like webOS is a step in the right direction for moble computing.

i'm sure there will be limitations. I actually majored in c++ in school, tho I haven't done a whole lot with it. But like I said origionally, i'm sure that a native SDK will be out eventually, and it will open up some functionality that we don't currently have. I'm just impressed with all the functionallity we DO have. And excited that they were able to do it all with open web standard.. Glass half full kind of guy.

[ADGrant]

My background is more biased towards traditional OO development using languages like Java, C# and C++. While you can do a lot with Javascript (subject to the constraints of the web browser model), the resulting code reminds me a bit of Perl (hard to read).

I don't think a C++ sdk is ideal for a SmartPhone. A good Java implementation should suffice (e.g. Android).

[GreenHex]

I'm so glad it's Javascript and not Java. I'd have said goodbye if it were Java. Palm, I love you for not going the Java way.

[JaMart]

if javascript is restricted by the constrains of the browser ( which it is, tho in this case its more than a traditional browser, its the whole webOS architecture)

then java is also limited by the virtual machine, which also sits on top of the operating system and translates the java into native code. If webOS is implemented right, (and i hope it is) the design concept is really quite similar IMHO

[ADGrant]

if javascript is restricted by the constrains of the browser ( which it is, tho in this case its more than a traditional browser, its the whole webOS architecture)

then java is also limited by the virtual machine, which also sits on top of the operating system and translates the java into native code. If webOS is implemented right, (and i hope it is) the design concept is really quite similar IMHO

Modern JVMs are very good and running on multiple versions of Linux. Many Java APIs exist for both server side code (e.g. messaging APIs) and GUI toolkits. Java code is very portable (not as portable as some Java proponents would claim but much more portable than code written in most languages). The core Java frameworks contain mature thread APIs and collection classes. The language supports most of the concepts a good OO language should such as inheritance, interfaces and reflection (except constant methods/objects for some reason I have never understood). Just about everyone who has graduated with a Comp Sci degree in the last 10 years knows Java.

Java script is essentially the perl of web browsers. You can do lots of stuff, but it won't be pretty.

[ADGrant]

I'm so glad it's Javascript and not Java. I'd have said goodbye if it were Java. Palm, I love you for not going the Java way.

Why?

[jhoff80]

Chapter 5 is out now.