incaseofstairs

With the 1.2.1 release of Facebook for webOS, we are now officially supporting the ability to seed status updates via an application manager launch. This allows for applications that do not wish to interact directly with the Facebook APIs to provide Facebook status posts with minimal effort.

function seedFacebookStatus(text) {
    ServiceRequestWrapper.request('palm://com.palm.applicationManager', {
        method: 'launch',
        parameters: {
            id: "com.palm.app.facebook",
            params: { status: text }
        }
    });
}

This call will launch the Facebook application, open to the new stream, and populate the update status control in the Facebook application. Once populated the user may edit the message as they please and submit.

A sample project is available on github.

Are there any other features that you would like to see via launch APIs in the Facebook application or for Facebook APIs in general on webOS? Feel free to leave a comment on this post with any ideas that you may have.

This article is part of my Palm Dev Day summary series as well as a follow up to the original service request garbage collection post from last month.

After reexamining the original ServiceRequestWrapper implementation and the possible use cases, some improvements began to show through:

• Subscribe requests were not protected from garbage collection after the initial complete callback (Thanks to Johan for pointing this out)
• Requests were not being automatically cancelled on completion
• The class did not need to be instantiatable as the 90% case can be handled by a singleton

With these issues in mind I decided that a rewrite was in order to make the class easier to use, as this is what the goal was in the first place :).

Non-Subscription Requests

Usage for non-subscription requests now involves a single call, ServiceRequestWrapper.request that is a “fire and forget” call meaning that cleanup is completely automated.

    ServiceRequestWrapper.request('palm://com.palm.preferences/systemProperties', {
            method:"Get",
            parameters:{"key": "com.palm.properties.nduid" },
            onSuccess: function(response) {
                Mojo.Log.info("Device ID: %j", response);
            }
      });

Note that are no special requirements to cleanup the request object for these types of calls. Upon completion the request object will be cleaned from both the ServiceRequestWrapper data structures as well as any system level data structures.

Subscription Requests

The subscription case is not as simple as the framework can not reliably determine when the request is complete and future results are no longer desired. In order to reliably cleanup subscription requests ServiceRequestWrapper places the cleanup responsibility on the caller, via the cancel method, much in the same way as the Mojo.Service.Request API.

In practice this is not much harder than dealing with the single case. The following example monitors the system preferences for two changes to an arbitrary preference and then cancels any further action on that subscription.

var count = 0;
ServiceRequestWrapper.request('palm://com.palm.systemservice', {
    method:"getPreferences",
    parameters:{ keys: [ "food" ], subscribe: true },
    onSuccess: function(response, request) {
        Mojo.Log.info("Preference changed: %j", response);
        count++;
        if (count === 2) {
            request.cancel();
        }
    }
});

The request API also returns the a request object, which is identical to the 2nd parameter passed to callbacks, for those that need to cancel the request outside of the scope of a callback.

var subsRequest = ServiceRequestWrapper.request('palm://com.palm.systemservice', {
    method:"getPreferences",
    parameters:{ keys: [ "food" ], subscribe: true },
    onSuccess: function(response, request) {
        Mojo.Log.info("Preference changed: %j", response);
    }
});

// And then a miracle occurs

subRequest.cancel();

Source

Last Friday and Saturday Palm hosted their Dev Day event at their Sunnyvale campus, which I had the pleasure of presenting some of the techniques we learned while developing the Facebook for webOS application.

This presentation covered everything from our best practices to debugging and development tools to the common libraries we developed for the application. I would recommend webOS developers take a look as the topics covered deal with many common app development concerns.

As part of this presentation we have open sourced a collection of the libraries and tools that are used in the Facebook app development.

• Open Source Libraries
• palm-run
• Multi-stage Inspector
• i18nScanner

The slides from my presentation are available on slideshare and a video should be published in the near future. Additional presentations from the event have been made available under the palmdev slideshare tag

On a personal note, I would like to say that it was awesome to meet some of the developers who are using webOS, particularly in the Apps Lab breakout section!

Stay tuned for in depth posts on the topics discussed in my presentation.

Update: border-image-generator is not hosted on border-image.com. The previous URLs are configured to redirect to this url.

The CSS3 border-image property allows for some very cool and efficient design but after implementing them in both Mozilla for the Firebug search panel and WebKit for the Palm Facebook notifications badge, I’ve learned that they can be quite frustrating to properly tweak by hand.

Background

For those who have not been exposed to this property, it allows a single image to be used to style the borders and background of a particular element. In the example above, each section will map to a different border, corner, or the content background, allowing for a single element and image to provide styling the previously required significantly more of each.

Using these properties the following element can be rendered using simple semantic HTML and CSS.

<div class="stylishContent">Some stylish content</div>

.stylishContent {
    display: inline-block;
    border-width: 27px 27px 27px 27px;
    -moz-border-image: url(http://www.w3.org/TR/css3-background/border.png) 27 27 27 27; -webkit-border-image: url(http://www.w3.org/TR/css3-background/border.png) 27 27 27 27;
    border-image: url(http://www.w3.org/TR/css3-background/border.png) 27 27 27 27;
}

For more detail, John Resig has published an excellent writeup on the Mozilla implementation.

App

As noted above there is a bit of tweaking involved in getting these settings right. To ease some of this pain I’ve created the border-image-generator project, which allows for WYSIWYG editing of these properties. Rather than manually adjusting each parameter, border-image-generator allows the various parameters involved to be changed visually with instant preview of what these changes will look like in the current browser.

Seen in action demonstrating Resig’s examples here and here.

Features

• WYSIWYG editing of border-image properties
• Cross-browser border-image CSS generation
• URL-based State (History + Preview in multiple browsers)

It can be accessed through any of the following URLs:

• border-image
• github/kpdecker/border-image-generator

Any issues or suggestions for improvements can be sent to myself or logged in the github issue tracker.

Warning

As a preliminary warning this is currently a vendor experimental feature but it is currently set to be included in the CSS3 specification. There are some significant differences between the vendor implementations and the W3C candidate, so some caution should be used. Border-image-generator attempts to handle these cases as defined by the spec, but many things could change between the current implementations and the release of CSS3 implementations in the wild.

Related Links:

• MDC -moz-border-image Property
• ADC -webkit-border-image Documentation
• W3C Standard Documentation
• John Resig’s article
• Suburban Glory’s article

Making the jump to mobile development from desktop and server development can lead to quite a few gotchas due to the resource constraints inherent to mobile environments. This became very clear to me today while debugging an intermittent failure in the Facebook application’s news and notifications scenes.

Like every other debugging session for intermittent issues there were quite a few choice words used in the process and many dead ends, but eventually it became apparent that some vital Mojo.Service.Request service requests were not calling any of their notification callbacks. Expecting the onComplete callback to occur at the very least, I was very perplexed until I spoke with some of my esteemed colleagues at Palm and they pointed me to the garbage collector as the possible culprit for this situation.

The code in question was instantiating Request objects but not maintaining references to these objects. This is fine up until the point that the garbage collector runs and the request object as well as all callbacks are collected. At this point these requests could no longer notify the application of their completion, blocking further processing of the queues associated with these requests.

After storing the instantiated Request objects until completion all of the calls that were previously disappearing into the ether began to return as expected.

The moral of the story is that you need to be very careful about what references are maintained when working with garbage-collected languages in memory-constrained environments. If you want something to stay around, like callback methods, you need to be certain that it is referenced somewhere. To ease this task for Mojo.Service.Request calls (controller.serviceRequest calls are safe as the controller maintains a reference to the request object or cancels the request prior to popping the scene), we implemented the following wrapper:

var ServiceRequestWrapper = Class.create({
    initialize: function() {
        this.requestId = 0;
        this.requests = {};
    },

    request: function(url, optionsIn, resubscribe) {
        Mojo.Log.info("Service request wrapper url: '%s' method: '%s' CALLED", url, optionsIn.method);
        var options = Object.clone(optionsIn),
            requestId = this.requestId++;
        options.onComplete = this.completeHandler.bind(this, url, optionsIn, requestId);

        this.requests[requestId] = new Mojo.Service.Request(url, options, resubscribe);
        return this.requests[requestId];
    },

    completeHandler: function(url, optionsIn, requestId, response) {
        Mojo.Log.info("Service request wrapper url: '%s' method: '%s' requestId: %d COMPLETE", url, optionsIn.method, requestId);
        delete this.requests[requestId];

        optionsIn.onComplete && optionsIn.onComplete(response);
    }
});

By instantiating this on a location that will not be collected during the application’s lifetime and using the request method rather than direct Mojo.Service.Request calls for all requests that the result is necessary you can avoid this problematic scenario as well as save the choice words for a later time :)

After more than a year of development I am absolutely ecstatic to announce the 1.0 release of Firediff. There were quite a few hiccups due to personal commitments in this development cycle, but I feel like this release is quite solid and brings quite a few must have features.

As noted in the previous alpha and beta announcements, this release adds many key features to the 0.2.1 release:

• Revert Changes
• Save Snapshot
• Save Diff
• Document Formatters
• Search
• Activation Data Handling Improvements
• Style attribute change handling

At this point I have achieved the majority of my initial goals for Firediff and feel as though it fits most of the realistic needs that I originally envisioned when I set out on this project. From this point onward the community is even more vital in defining the future direction of Firediff as I am looking for additional features that can be implemented.

The following features and fixes are currently under consideration for future releases but we are looking for more to implement.

• Filtering of the changes view
• Stack trace
• Free Edit Diffing
• Entire tree diffs on insertion or removal
• Improved handling of inline stylesheets
• Iframe Support
• Parity changes with Firebug enhancements

Any input from the community in terms of feature request or code contributions that will help improve the quality of the project. If you have a cool feature that you would like to see implemented in Firediff, please feel free to file bugs or enhancement requests with the fbug project or contact me directly.

Version 1.0 is available on here and has been seeded to AMO (Under review as of this writing).

The first feature complete beta for Firediff 1.0 has just landed here. This release allows for customization of the format saved by the save snapshot and diff features. Also included are some minor bug fixes and official support for Firefox 3.6 and Firebug 1.5.

This release has also been registered on Babelzilla (along with Firefocus) and any translators are welcome to provide their input.

Bugs may be filed with the fbug issue tracker.

As part of my day job I recently needed to debug focus handling within a AJAXy web app and found that logging and visualizing of this was quite difficult. To assist with this task I spent some of my personal time developing Firefocus, a Firebug extension for tracking keyboard focus at the HTML node level within Firefox.

Firefocus provides the ability to log all focus and blur events to the console as well displaying the element which currently has focus on the HTML panel, particularly helpful for tracking down the nuisance element that managed to inject themselves in the tab order but are not displaying the focus status properly.

This extension supports Firebug 1.4 and higher and is available here.

Firediff recently hit a major milestone, with the implementation of major portions of the save snapshot and save diff features. These as well as the revert and search features are available in the most recent alpha.

As a somewhat preemptive warning, the save diff feature is not likely to generate a line for line match that can be applied directly to the source files. This is due a number of reasons, including performance optimizations in Firefox that cull information that is not vital to the final rendering of the page and the large number of coding styles that exist in the wild.

We are currently investigating the options that we have to improve this, although the current iteration should be treated as a  a serialized version of the page state that the designer or developer can use to manually update the source files, rather than something that can be automatically applied to the source using patch or another method.

Feel free to comment on this post or email me at kpdecker AT gmail.com with any input on these features or any of the other Firediff features.

Due an a conflict between one of the libraries used by Firediff and just about everything else, I have pushed the Firediff release schedule forward some and rolled a 0.2.1 release.

This release includes fixes for the extension conflict, a new text diffing algorithm that will hopefully give better results as well as provide the basis of the unified diff feature that is planned for 0.1, and a few minor bug fixes to the Snapshot UI.

Thank you to all of those who notified me of this conflict.