Finally got some time to get back to this review…
Chapter 3: Developing for Multiple Platforms
The opening paragraph perked my interest: “if your gadget uses a feature from a specific API, how can you avoid being locked into that API?” This is actually a problem across the industry with most developers struggling to get a feature working and paying no attention to lock-in issues. In general, I see a lot of developers focused solely on getting some functionality working with neither lock-in, performance or robustness ever being considered.
The treatment of issues from HTTPProxy to caching was among the best balanced that I have ever read. A path is given, alternatives paths are cited and instead of defending his choice, he gives the pros and cons and then why he opted to use a specific solution (often it’s clarity of presentation). For example:
Finally, there are also two web gadget platforms, Netvibes and iGoogle, that will supply the configuration user interface for you if you prefer. I’ll be covering the details in Chapters 4 and 5, respectively, but the idea is that you denote your settings in the gadget specification, and the API (p.64)
Chapter 4: Netvibes
Again, crisp and candidate advice is clearly provide, for example
“My preference is to retain control over the branding on the face of my gadgets, rather than devoting valuable screen real estate to someone else’s link, so I don’t advocate following this course. Instead, I’ll show how to deploy to Netvibes on its own and (in subsequent chapters) to the other platforms directly.” p.77
I found a continuous lists of caveats and possible issues are well provided during the development of the chapter. A few examples:
- Netvibes widgets are served directly from netvibes.com, so all URLs referenced by your gadget must include the global path to the resource; no relative URLs are possible.
- This is because of a minor peculiarity in the Netvibes process that embeds your gadget within the page. It appears that link elements (like the first syntax shown earlier) are not processed, while style elements are. It’s a minor change but one you need to be aware of.
- Netvibes caches the source for live widgets shown on user pages. So if you find a problem at this stage, changes you make to your gadget’s source will take up to five minutes to propagate to www.netvibes.com.
- The concept of gadgets being deployed to third-party web sites (such as blogs) raises a subtle issue concerning user preferences: whose preferences should the gadget be using?
Chapter 5: iGoogle
I found that it was nice that Sterling deal with the minor player before the dominant player. It gives the leader a better rounding than the reverse (if you read the dominant first, you tend to skip or blow off the minor). He continues to do a crisp detail development with excellent coverage of issues that would take weeks, if not months. to acquire by trial and error. An example: “Caution Google sends prefs values to the gadget as URL parameters—so if the amount of data is too large, the URL can get corrupted, and the client gadget can cease to work.” p. 108 and “be aware that myAOL is actually further along this curve than other Google-based containers, and some of my advanced caching techniques actually conflict with this host.”
Although this chapter is called iGoogle, it really deals with all of the widget options in the panorama of Google offerings. It mentions some sweetness available, for example:
Google expects that any given gadget may potentially be installed by millions of users and recognizes that such a load is likely to be problematic for the gadget author’s web host. So, in addition to always caching the XML source, the API includes a function that enables you to use Google’s servers as a proxy for your own resources. p.131
That’s it for today – tomorrow, we crack Desktop Platforms.