{"id":3995,"date":"2010-04-13T11:47:27","date_gmt":"2010-04-13T18:47:27","guid":{"rendered":"http:\/\/3.260"},"modified":"2012-04-12T19:36:52","modified_gmt":"2012-04-12T19:36:52","slug":"develop-with-jetpack-sdk-0-2","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/labs\/2010\/04\/develop-with-jetpack-sdk-0-2\/","title":{"rendered":"Beginning development with Jetpack SDK 0.2"},"content":{"rendered":"

This article is a translation of a recent article in Japanese<\/a> by fellow Jetpack Ambassador Gomita<\/a>. \u2014 mitcho<\/a>
\n<\/em><\/p>\n

Mozilla Labs recently released version 0.2<\/a> of the Jetpack SDK, which fixes some issues of the 0.1 release such as a glitch regarding development with Windows. SDK 0.2 doesn’t include the planned APIs for rapid development of new browser functionality, but you can still play with SDK 0.2 to get a flavor for development with the Jetpack SDK.<\/p>\n

In this article we begin by setting up an SDK 0.2 development environment and explain the steps required to develop a simple, practical add-on using SDK 0.2. The instructions here are for Windows, but the basic steps are the same in every platform.<\/p>\n

Installing Python<\/h3>\n

The first step to using the Jetpack SDK is to install Python. How to install Python depends on your OS, but in Windows you can choose the “Python 2.6.5 Windows installer” from the Python<\/a> site and follow the installation wizard. Here, I’ll use C:Python26 as the installation path.<\/p>\n

After the install, you can activate the “python” command in your command line by adding “C:Python26” to the Windows “Path” preference. (If there is already another value, delimit with a semicolon: “;”.) Run the command “cmd” from the Start menu to start the command prompt and run “python -V” to confirm the Python version, “Python 2.6.2”:<\/p>\n

C:>python -V\r\nPython 2.6.2\r\n<\/pre>\n
Note, the Jetpack SDK Docs<\/a> state that Python 2.5+ is required, but there seem to be some incompatibilities with Python 3.0.1 at this time. In addition, in my experience the SDK worked fine without the “Python for Windows extensions.”<\/p>\n
Setting up the Jetpack SDK<\/h3>\n
Next, we set up the Jetpack SDK. Download the Jetpack SDK 0.2 package from the Jetpack site<\/a>, unzip it, and place it somewhere convenient. Here, I used “C:jetpack-sdk-0.2”.<\/p>\n
To use the Jetpack SDK, it must be “activated.” From the command prompt, go to the Jetpack SDK folder and run “binactivate”:<\/p>\n
C:jetpack-sdk-0.2>binactivate\r\nWelcome to the Jetpack SDK. Run 'cfx docs' for assistance.\r\n(C:jetpack-sdk-0.2) C:jetpack-sdk-0.2>\r\n<\/pre>\n
Next, run “cfx docs” to open the SDK documentation in the browser. The SDK documentation starts a local server on port 8888.<\/p>\n
(C:jetpack-sdk-0.2) C:jetpack-sdk-0.2>cfx docs\r\nOne moment.\r\nOpening web browser to http:\/\/127.0.0.1:8888.\r\n<\/pre>\n
The package directory structure<\/h3>\n
Addons built with the Jetpack SDK are called “packages.” Let’s try building a simple “hello world”-style package, but first let’s see what the final directory structure of this package will look like:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
directory\/file<\/span><\/th>\nNote<\/span><\/th>\n<\/tr>\n
\"\u30d5\u30a9\u30eb\u30c0\"jetpack-sdk-0.2<\/td>\nthe Jetpack SDK folder<\/td>\n<\/tr>\n
\"\u30d5\u30a9\u30eb\u30c0\"packages<\/td>\nthe main packages folder<\/td>\n<\/tr>\n
\"\u30d5\u30a9\u30eb\u30c0\"hello-world<\/td>\npackage root<\/td>\n<\/tr>\n
\"\u30d5\u30a1\u30a4\u30eb\"package.json<\/td>\npackage manifest file<\/td>\n<\/tr>\n
\"\u30d5\u30a1\u30a4\u30eb\"README.md<\/td>\npackage documentation<\/td>\n<\/tr>\n
\"\u30d5\u30a9\u30eb\u30c0\"lib<\/td>\nthe package code directory<\/td>\n<\/tr>\n
\"\u30d5\u30a1\u30a4\u30eb\"main.js<\/td>\nmain program code<\/td>\n<\/tr>\n
\"\u30d5\u30a1\u30a4\u30eb\"simple-dialog.js<\/td>\na custom code library<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The package’s root directory is placed in the “packages” directory in the Jetpack SDK folder, and includes the “package.json” manifest file and the “README.md” documentation file. The “lib” folder includes the package’s main program code and any custom libraries used by our addon.<\/p>\n
Creating the package<\/h3>\n
We begin by creating the “hello-world” directory in C:jetpack-sdk-0.2packages . Next the manifest file “package.json” is created. The manifest file includes metadata about our package in JSON format. If you’ve ever created a XUL-style addon before, you can think of this as similar to the “install.rdf” file. Here, I used the following as the manifest:<\/p>\n
{\r\n    \"id\": \"helloworld@xuldev.org\",\r\n    \"version\": \"0.1\",\r\n    \"description\": \"This is my first package.\",\r\n    \"author\": \"Gomita <gomita@xuldev.org>\"\r\n}\r\n<\/pre>\n
The “id” property is used as a unique ID for all addons including Jetpack packages and is often formatted as an email address. This corresponds to XUL-based addons’ <em:id> tag.<\/p>\n
Next, reload the SDK documentation in the browser and confirm that “hello-world” shows up under “Package Reference.”<\/p>\n
Writing the main code<\/h3>\n
The next step is to add some working code to the hello-world package. Create a “lib” folder under the package root and create a “main.js” under “lib” with the following code:<\/p>\n
exports.main = function(options, callbacks) {\r\n    console.log(\"Hello, World!\");\r\n};\r\n<\/pre>\n
The main program code is always loaded as a module called “main”. This “main” property is made accessible from outside code using the CommonJS<\/a>-style code “exports.main = …”. “console.log” is a global function made available by Jetpack and the SDK prints the string to the command prompt.<\/p>\n
It’s worth noting that, in the current Jetpack SDK, calling “console.log(\"\u3053\u3093\u306b\u3061\u306f\");<\/code>” doesn’t yield the expected Japanese output. In the future such output will be handled through the planned localization API<\/a>.<\/p>\n
Testing our package<\/h3>\n
With some simple code in our “main” function, it’s time to try this code out. To test this code, we run “cfx run -a firefox” in the command prompt. By running “cfx run” with the “-a firefox” option, we load our package into a brand new Firefox profile and launch Firefox.<\/p>\n
(C:jetpack-sdk-0.2) C:jetpack-sdk-0.2>cd packageshello-world\r\n\r\n(C:jetpack-sdk-0.2) C:jetpack-sdk-0.2packageshello-world>cfx run -a firefox\r\ninfo: Hello, World!\r\nOK\r\nTotal time: 1.531000 seconds\r\nProgram terminated unsuccessfully.\r\n<\/pre>\n
After Firefox loads, confirm that the command prompt reads “info: Hello, World!” When you quit Firefox, the testing will end.<\/p>\n
Using a standard library<\/h3>\n
Now we’ll edit our code to invoke the timer library which is one of the Jetpack SDK’s standard libraries. The timer library is a module which abstracts various timer-related functionality, similar to the DOM’s window.setTimeout, window.clearTimeout. Details on this library are available in the SDK documentation<\/a>. Moreover, although not in the documentation, timer.setInterval and timer.clearInterval also work in this version.<\/p>\n
To use this library in our main program code, we first must invoke this library with the CommonJS require function. We modify the main.js file as follows:<\/p>\n
var timer = require(\"timer\");\r\nexports.main = function(options, callbacks) {\r\n    timer.setInterval(function() {\r\n        console.log(new Date().toLocaleTimeString());\r\n    }, 1000);\r\n};\r\n<\/pre>\n
After this change, run “cfx run -a firefox” in the command prompt to test it. Check to make sure that the current time is being printed to the command prompt once a second:<\/p>\n
(C:jetpack-sdk-0.2) C:jetpack-sdk-0.2packageshello-world>cfx run -a firefox\r\ninfo: 10:37:21\r\ninfo: 10:37:22\r\ninfo: 10:37:23\r\ninfo: 10:37:24\r\ninfo: 10:37:25\r\n<\/pre>\n
Creating a custom library<\/h3>\n
Next we’ll create a custom library to add some functionality not currently included in the Jetpack standard library. Implementing advanced functionality in add-ons, like filesystem access, involves using XPCOM<\/a> components. Jetpack encourages seprarating the use of XPCOM components into separate modules which are then used by the main program code. The Jetpack SDK doesn’t currently disallow direct XPCOM access within Jetpack add-on code, but such a restriction is forthcoming. Modularizing XPCOM code into separate libraries now allow you to easily migrate to equivalent standard libraries in the future.<\/p>\n
Let’s create a simple-dialog library to display a modal dialog much like window.alert does. The Jetpack code’s runtime environment doesn’t include access to the regular window or document objects, so just calling window.alert doesn’t work. To create an alert from this context, we use the nsIPromptService<\/a> XPCOM component. In our package’s lib folder, create a “simple-dialog.js” file. Just like our main program code, we implement this library as a CommonJS module using “exports.methodname<\/em> = function(…){…}”.<\/p>\n
The simple-dialog library will have these two methods:<\/p>\n\n\n\n\n\n
Method<\/span><\/th>\nNote<\/span><\/th>\n<\/tr>\n
alert(text<\/em>)<\/code><\/td>\nDisplays an alert dialog with the string in text<\/em> and an OK button. Equivalent to the DOM’s window.alert.<\/td>\n<\/tr>\n
confirmYesNo(text<\/em>)<\/code><\/td>\nDisplays a confirmation dialog with the string in text<\/em> and Yes and No buttons. The method returns true if the user presses “yes” and false if “no.”<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Here is the code for simple-dialog.js:<\/p>\n
var promptSvc = Cc[\"@mozilla.org\/embedcomp\/prompt-service;1\"].\r\n                getService(Ci.nsIPromptService);\r\n\r\nexports.alert = function(text) {\r\n    promptSvc.alert(null, \"[Jetpack]\", text);\r\n};\r\n\r\nexports.confirmYesNo = function(text) {\r\n    var pos = promptSvc.confirmEx(\r\n        null, \"[Jetpack]\", text, promptSvc.STD_YES_NO_BUTTONS,\r\n        null, null, null, null, {}\r\n    );\r\n    return pos == 0;\r\n};\r\n<\/pre>\n
Lines 1-2 are for calling nsIPromptService. Note that Cc, Ci are aliases for Components.classes and Components.interfaces, respectively, and are made available by Jetpack as global variables. Lines 4-6 implement the alert method for showing alert dialogs using nsIPromptService’s alert method. Lines 8-14 implement simple-dialog’s confirmYesNo method using nsIPromptService’s confirmEx method to display the dialog with yes and no buttons. nsIPromptservice’s confirmEx method returns 0 if the user presses “yes” and 1 if “no”, so we modify this value and return it.<\/p>\n
Using our custom library<\/h3>\n
Let’s call this new custom library from our main program code and verify that it works. Here’s our updated main.js file:<\/p>\n
var simpleDialog = require(\"simple-dialog\");\r\n\r\nexports.main = function(options, callbacks) {\r\n    var adult = simpleDialog.confirmYesNo(\"Are you over 18 years old?\");\r\n    if (adult) {\r\n        simpleDialog.alert(\"Welcome!\");\r\n    }\r\n    else {\r\n        simpleDialog.alert(\"Good bye!\");\r\n    }\r\n};\r\n<\/pre>\n
Run “cfx run -a firefox” and confirm that a confirmation dialog, as seen below, is displayed. Pressing “yes” and “no” should give you the appropriate alert dialogs as well.<\/p>\n
\"\"<\/p>\n
\"\"<\/h3>\n
\"\"<\/a><\/h3>\n
Implementing a network status observer<\/h3>\n
Now let’s use this hello-world package as a foundation for a more practical add-on. Using the observer-service<\/a> module included with the Jetpack SDK, we can monitor Firefox’s online\/offline network status changes.<\/p>\n
Firefox internally broadcasts various application events to observers via the nsIObserverService<\/a> XPCOM component. When Firefox goes offline, a “network:offline-status-changed” notification is broadcast. To subscribe this notification and act on it, we use the observer-service library’s add method. add’s first argument is the name of the notification we want to subscribe to and the second argument is a callback function. The callback function is given two arguments, of which the second is a string equal to either “online” or “offline.” In our add-on, we’ll check this value and display an appropriate alert using simple-dialog.<\/p>\n
var simpleDialog = require(\"simple-dialog\");\r\nvar observer = require(\"observer-service\");\r\n\r\nexports.main = function(options, callbacks) {\r\n    observer.add(\"network:offline-status-changed\", function(sbj, data) {\r\n        if (data == \"online\") {\r\n            simpleDialog.alert(\"Firefox is now online.\");\r\n        }\r\n        else if (data == \"offline\") {\r\n            simpleDialog.alert(\"Firefox is now offline.\");\r\n        }\r\n    });\r\n};\r\n<\/pre>\n
Launch Firefox by running “cfx run -a firefox” and then choose “File” > “Work Offline” and you should get a notification:<\/p>\n
\"\"<\/a><\/p>\n
Adding documentation<\/h3>\n
If you add documentation to a package, you can view it by clicking that package in the SDK Documentation. To add documentation, create a “README.md” file in the package root directory. “README.md” is written in Markdown format which looks like this:<\/p>\n
This is my *first* package.\r\n\r\n* foo\r\n* bar\r\n* baz\r\n<\/pre>\n
Now if you load the SDK documentation using “cfx docs” and click on the “hello-world” link, you’ll see this documentation together with the package metadata.<\/p>\n
Exporting an install package<\/h3>\n
Jetpack add-ons which are created in this way can then be exported into Firefox-standard XPI files. To export an XPI, go to the package’s root directory in the command prompt and run “cfx xpi”.<\/p>\n
(C:jetpack-sdk-0.2) C:jetpack-sdk-0.2packageshello-world>cfx xpi\r\nExporting extension to hello-world.xpi.\r\n<\/pre>\n
This creates an XPI file called hello-world.xpi . Opening this file in any Firefox profile will let you install it using the regular add-on install mechanism.<\/p>\n","protected":false},"excerpt":{"rendered":"
This article is a translation of a recent article in Japanese by fellow Jetpack Ambassador Gomita. \u2014 mitcho Mozilla Labs recently released version 0.2 of the Jetpack SDK, which fixes some issues of the 0.1 release such as a glitch … Continue reading<\/a><\/p>\n","protected":false},"author":456,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[588],"tags":[22915,19630,19655,4127],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/labs\/wp-json\/wp\/v2\/posts\/3995"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/labs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/labs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/labs\/wp-json\/wp\/v2\/users\/456"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/labs\/wp-json\/wp\/v2\/comments?post=3995"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/labs\/wp-json\/wp\/v2\/posts\/3995\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/labs\/wp-json\/wp\/v2\/media?parent=3995"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/labs\/wp-json\/wp\/v2\/categories?post=3995"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/labs\/wp-json\/wp\/v2\/tags?post=3995"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}