Disclaimer: The views expressed in this post are my own and do not reflect any opinions of my employer. The app was written using publicly available resources as an Independent developer.
A few posts ago, I had written about the TrialTool app for Windows 8. TrialTool is a web based application that illustrates the capabilities of various Javascript APIs. It is like an API playground that lets you view, modify and run examples and this version of TrialTool specifically illustrates the various Windows 8 APIs.
1. Background
The app was developed on Windows 8 Developer Preview with Visual Studio 11 Express. The entire application was written using HTML5, CSS and Javascripht. The tool does not exhaustively cover all APIs yet, but the APIs used are a good representative of the programming model in Windows 8.
2. Development Environment
My primary IDE is Eclipse or Cloud9 and this was actually the first time I have used Visual Studio exclusively for an end to end project.
The application starts from choosing a pre-defined project type or a simple blank JS template in Visual Studio. The templates do a good job of creating the skeleton and filling in the boiler plate code. As with any skeletons, it may be hard to navigate the multiple files created as a part of the template for a newbie. Once you know your way around the files and the parts to edit, the templates are good. Unfortunately, looks like Visual Studio is the only option for now as I was not able to find any command line utilities that I could use with Eclipse or Notepad++ to build, package or deploy the project.
3. Writing Code
Starting with a blank project is similar to writing a web page from scratch. Using a template however starts us off with the Metro Style UI. TrialTool used the grid layout template that starts with an "index" page that displays a list of items. Each item can be clicked to take us to a "details" page.
The Javascript files created by the template recommend using strict mode.
3.1 Single Page application
The app created is inherently an equivalent of one-page website. Navigation from the "index" page to a "details" page results in the details being loaded as a DOM fragment. Loading and unloading events give us control over the content to be displayed on each action. The WinJS module defines events that let us access the activate or DOM fragment load events for navigation in addition to events for layout changes (portrait to landscape mode for tablets, re-size, etc. )
I noticed that the by default, files of type HTML, CSS and JS had a directory each. I would prefer to group files by modules instead of file type; file types are distinguished by their extension anyway.
3.2 CSS Grids
The use of ms-grid to define the metro UI is great. Grid layout for CSS are still in work in progress. Tiles are an prime to the Metro UI and the implementation of ms-grid makes building tiles in Metro UI is a lot easier.
Vendor prefix would be removed in the final version I guess.
3.3 Data Binding
The Templates also have support for data binding. With the data-win-* attributes in a the HTML tags, render views can be defined. These render views can define specific controls (like ListView) and options for these controls. JSON data can be loaded via AJAX and use these "itemRenderers".
The concepts here are very similar to frameworks like Backbone. However, some features like automatically changing the view when data changes, etc needs to explicitly coded unlike backbone. A way to point a itemRenderer to a URL would be even better.
Another feature that I would like to have is the ability to declare formats in the item renderers. Currently, the data from the model can be converted, but that seems to be manual. A data-win-option on individual elements to specify the format would be good.
3.4 Promises
All asynchronous operations (like AJAX, File reading, etc) seem to return promises. This is definitely better for an interactive event driven application. The "async" keywork in C#
is the equivalent.
The documentation for the promised could have been better. Looks like the documentation is written for C# and force fitted to Javascript. For example, in an operation like FilePicker, the return value is a promise. However, to see the actual arguments passed to the promise.then() method, you have to navigate to the "GetResults" method.
4. Windows 8 APIs
The main reason I would write a Windows 8 app (apart from store distribution) would be to use the Windows 8 APIs; otherwise, the app may as well be a web site viewed in the Metro IE.
Working with native Windows 8 APIs in Javascript is no different manipulating DOM using native DOM methods. Popping up a Windows 8 Toast is no different from invoking the native window.alert. Working with native File APIs, or cryptography is also very easy and straight forward.
The documentation on the Windows Runtime APIs is exhaustive but I would would have been more comfortable if they were grouped better and the first list the over high level categories (like Storage) and then you could drill down to understand a specific API (Bulk Access or File properties). This would help since a lot of APIs have common concepts before we look at specific APIs. This was probably why I wrote TrialTool in the first place.
The other issue I found was an example of APIs that require features not present in the Javascript language. For example, reading the contents of a file returns an InputStream that does not seem to show any Javascript API. It is not very clear that DataReader can in fact be used to read the data.
I wish that the APIs converge to become similar to the HTML5 File/Blob APIs.
5. Debugging
Debugging with Visual Studio is so good that you would not really miss Firebug or Web Developer toolbar. From basic features like support for logging to break points or inspecting the HTML source, the debugger is very powerful. I would recommend a dual monitor setup for for a better experience.
One feature that I found missing was a way to profile (like Speed Tracer) the Javascript app for performance issues. Adding to the wishlist would be a way to remotely debug an application (like Opera dragonfly but that is a feature I would like in IE too). Remote debugging may prove useful specially in case of tablets.
The usual annoyance of printing [object] with console.log still exists. It would be even better if we are able to integrate console.log with Windows application or system logs during a production deployment.
6. Packaging and Deployment
Though Visual Studio has a Store menu, looks like the Store is currently not available. The only option available today would be to create a local app. Packaging the app creates an appx file, a bat file and certificate file. Executing the bat file with Admin privileges install the application.
7. Conclusion
For the Web Developers, the option of using HTML/CSS/JS for writing native windows 8 applications is definitely compelling. Existing web development knowledge can be put to use here, but to leverage the full power of the operating system, it is best to familiarize with the APIs that Windows8 provides.
Overall, a great approach in bringing web development to native applications - hope writing Android or iOS apps were this simple for a Web Developer.
Writing Browser Extensions - Comparing Firefox, Chrome and Opera
MediaPlus is a browser extension that gives users more control over media elements like video, images, games, flash, etc by allowing them to move, resize, download, magnify and perform other actions on them.
Writing an extension for browsers is very similar to writing web pages that work across browsers - similar concepts but interesting quirks along the way; hence this post.
1. Background
MediaPlus started as a browser bookmarklet that injected some javascript into the current web page. This javascript was responsible for identifying various media elements like flash, images, etc and mark them as actionable. When the user needs to interact with a specific media content, they move the mouse over the media content and a panel with various actions shows up. This is the core functionality of MediaPlus.
In addition to the above functionality, MediaPlus also needs to provide interaction points to start, suspend or stop the plugin. All these actions are folded into the bookmarklet button on the browser.
As an browser extension for Firefox, Opera and Chrome, MediaPlus provides these extension points. This post deals with the similarities and differences in the extension system of the three browsers.
The comparison boxes below are color coded to indicate the parts I felt was best/easiest against worst/hardest.
For Firefox, the jetpack way of writing extensions was used. A browser extension for Safari is under development and I am still learning to write extensions for Internet Explorer; these would be possibly covered in future posts.
2. Parts of an extension - Concepts
The basic concepts of building an extension as very similar.
Note that all the three browsers support userscripts, thanks to their architecture.
2.1 Manifest File
All extensions start with a manifest file. This is the file that defines the basic behavior of the extension.
They are called package.json, config.xml and manifest.json in Firefox, Opera and Chrome respectively that define the name, version, description, author, icons, permissions and other meta-data about the extension. Though they are similar, Opera interestingly chooses XML over JSON.
2.2 Additions to Browser Interface
The manifest file also defines the different controls that the extension will add to to the Browser UI. This include things like Context Menu Items, Toolbar buttons and other panels.
2.3 Content Scripts
The core of MediaPlus rests in the script that is injected into the page. This is called a content script or injected script.
In all three browsers, content scripts do not share the run time with the page for security reasons. Extensions usually can do more (like access local file system, cross domain ajax etc) than a script inside a webpage and hence the security boundary.
2.4 Background Processes and Message Passing
A background page is a singleton javascript loaded once in the browser that is responsible for background operations and other house keeping activities. All the three browsers have this concept with different ways to pass messages between content scripts, browser interaction parts and the background script.
3. Coding
Any standard HTML and Javascript editor can be used for creating these extensions.
The issue with Firefox may be attributed to the fact that Jetpack extensions are actually compiled to the XPI that Firefox understands.
4. Debugging
Once the extension is written, the ability to trace through the code and see log messages helps a log in Debugging.
5. Publishing
Once the extension is ready, it needs to be published to a place where users can discover and download the extension. All the three browser have a store like interface where users can discover and download the extensions. In case of all three stores, screenshots, icons and videos have to be provided in specific dimensions as required by the stores.
Auto-updating the extension when a new version is available is also great in all three browsers. All the three also provide support for hosting the extensions at places other their store with support for auto-update URLs.
5. Analytics
Post publication, a mechanism is needed to monitor the traffic and downloads to the extension.
6. Conclusion
To conclude, all the three browsers strive to provide and most powerful yet simple platforms for developing extensions. Though there are not standards (like for web pages), each browser tries their best to infer from existing ways of doing things.
Note that this article derive from my experiences of building MediaPlus and I may not have touched upon all aspects of extension writing.
You can download MediaPlus for your browsers from the following links.
Writing an extension for browsers is very similar to writing web pages that work across browsers - similar concepts but interesting quirks along the way; hence this post.
1. Background
MediaPlus started as a browser bookmarklet that injected some javascript into the current web page. This javascript was responsible for identifying various media elements like flash, images, etc and mark them as actionable. When the user needs to interact with a specific media content, they move the mouse over the media content and a panel with various actions shows up. This is the core functionality of MediaPlus.
In addition to the above functionality, MediaPlus also needs to provide interaction points to start, suspend or stop the plugin. All these actions are folded into the bookmarklet button on the browser.
As an browser extension for Firefox, Opera and Chrome, MediaPlus provides these extension points. This post deals with the similarities and differences in the extension system of the three browsers.
The comparison boxes below are color coded to indicate the parts I felt was best/easiest against worst/hardest.
For Firefox, the jetpack way of writing extensions was used. A browser extension for Safari is under development and I am still learning to write extensions for Internet Explorer; these would be possibly covered in future posts.
2. Parts of an extension - Concepts
The basic concepts of building an extension as very similar.
| Chrome looks to be inspired by Greasemonkey way of building things - just making the thing better. | Opera is heavily influenced by W3C Widgets | Firefox Heavily borrows from commonjs, specifically the modules part. |
2.1 Manifest File
All extensions start with a manifest file. This is the file that defines the basic behavior of the extension.
They are called package.json, config.xml and manifest.json in Firefox, Opera and Chrome respectively that define the name, version, description, author, icons, permissions and other meta-data about the extension. Though they are similar, Opera interestingly chooses XML over JSON.
2.2 Additions to Browser Interface
The manifest file also defines the different controls that the extension will add to to the Browser UI. This include things like Context Menu Items, Toolbar buttons and other panels.
| For chrome, these are usually included statically in the manifest. Interface elements include context menus, URL bar plugins, menu items, etc. | Opera seems to be better as they provide flexibility of adding browser interface elements during run-time. The interface is defined in index.html along with its actions for clicking the button, etc. | Firefox is also similar to Opera where the browser interaction elements are specified in the main module. This allows more actions to be specified by the extension based on the page. |
2.3 Content Scripts
The core of MediaPlus rests in the script that is injected into the page. This is called a content script or injected script.
| Chrome is the simplest as Javascript and CSS can be inserted at any point using an API call. | Opera does not have a direct way to inject script and hence, AJAX requests are made to the extension to read the script content and then inject it dynamically as HTML content.Opera includes all scripts in the includes folder as a part of the page. This however means that injecting scripts dynamically become hard. | Firefox provides page-mod that includes scripts. Injecting scripts into specific tabs with similar URLs using a page-mod is hard that forced MediaPlus to use the same mechanism employed in Opera where scripts were read and written with HTML tags. |
In all three browsers, content scripts do not share the run time with the page for security reasons. Extensions usually can do more (like access local file system, cross domain ajax etc) than a script inside a webpage and hence the security boundary.
2.4 Background Processes and Message Passing
A background page is a singleton javascript loaded once in the browser that is responsible for background operations and other house keeping activities. All the three browsers have this concept with different ways to pass messages between content scripts, browser interaction parts and the background script.
| Chrome again provides the simplest model of message passing using simple APIs. Messages can be relayed between content scripts, background process and browser UI (panels, popups, etc.). Messages are handled using simple message listeners. There are also concepts of long and short lived connections. | Opera strictly follows the W3C message passing mechanism with Channels. Though complex, this is more powerful, providing events "onconnect", to actually start listening to a specific channel. | Firefox seemed to be the most powerful with message passing had both channels and events. The best past of Firefox was the ability to add an event listener ("onMyMsg") to specific messages and just act on it, thus avoiding switch case. |
3. Coding
Any standard HTML and Javascript editor can be used for creating these extensions.
| Chrome has a dedicated developer dashboard that can be used to point to the extension directory. Making changes to code requires hitting a reload button on the "Manage Extensions" to ensure that the latest code is running. | In case of Opera, the config.xml can simply be dropped onto the Opera Window (in developer mode) and the entire directory structure is picked up. Hitting the reload button is require here too. | Setting up the development environment for Firefox is the hardest given that Jetpack extensions are actually compiled to XPI. This also means that any change would mean compiling and reloading the extension - something not native to web developers. |
The issue with Firefox may be attributed to the fact that Jetpack extensions are actually compiled to the XPI that Firefox understands.
4. Debugging
Once the extension is written, the ability to trace through the code and see log messages helps a log in Debugging.
| Chrome here steals the show with its web developer toolbar. With a single interface, all parts of the extension including the background process, content script and browser UI can be debugged. The simple console.log prints all messages in the console. | Injected Scripts in Opera can be debugged with breakpoints using Dragonfly. However, I have noticed that tracing through background index.html or browser UIs seems hard. The opera.postError is required to post messages to the Opera Error console - and it does not live well with JSON. | Possibly a result of its development experience, debugging in Firefox can be hard. However, I ensured that I always pointed to a profile directory that had Venkman and Firebug. This way, I could actually debug all parts of the extension. |
5. Publishing
Once the extension is ready, it needs to be published to a place where users can discover and download the extension. All the three browser have a store like interface where users can discover and download the extensions. In case of all three stores, screenshots, icons and videos have to be provided in specific dimensions as required by the stores.
| The extension simply needs to be zipped and uploaded to the store. The Chrome store seems to be the most mature of them. There is also support for a payment system. You extension needs to get approved before it is actually visible on the store. The store is also one single place for apps, themes, etc. | The OEX file (zip of extension files needs to be uploaded) The Opera Store has a great/quick approval process too. I have not seen the support for payments in the store. | The packaged XPI file is uploaded to the store. Given that Firefox had extensions even before some of the other browsers existed, it has a great eco-system of extensions. Though they are no "payments", donations are supported for developers. |
Auto-updating the extension when a new version is available is also great in all three browsers. All the three also provide support for hosting the extensions at places other their store with support for auto-update URLs.
5. Analytics
Post publication, a mechanism is needed to monitor the traffic and downloads to the extension.
| The store page for Chrome is can be integrated with Google Analytics, providing it with great analytics. Apart from traffic sources, downloads and weekly installs, with user comments are also available. | Analytics in Opera store is pretty basic. Ratings, download count and user comments are the only available features. Download per | Though firefox is not integrated with any powerful analytics, it does provide details like visits and downloads per time. It seems to be an in house version of an analytics system. |
6. Conclusion
To conclude, all the three browsers strive to provide and most powerful yet simple platforms for developing extensions. Though there are not standards (like for web pages), each browser tries their best to infer from existing ways of doing things.
Note that this article derive from my experiences of building MediaPlus and I may not have touched upon all aspects of extension writing.
You can download MediaPlus for your browsers from the following links.
http://nparashuram.com/projects/flashresizer.html
Edit: As people pointed out, the article deals only with building extensions for Firefox using Jetpack. You can build extensions without Jetpack, but that cannot be compared to what Opera and Chrome offer.
TrialTool for Windows 8
TrialTool is a web based application that illustrates the capabilities of various Javascript APIs. It is like an API playground that lets you view, modify and run examples and see the output right inside the browser.
A few days back, Microsoft released the Windows 8 Developer Preview that would give developers a peek into the next version of the operating system and to start developing applications.
HTML, CSS and Javascript was one of the ways to build Windows 8 native applications. The list of APIs in the reference was huge and I wanted a way to not just read but also play around with the APIs to understand and experience them. To this end, I ported the web version of TrialTool to illustrate the various Windows 8 APIs available.
The video below is a screencast of how TrialTool looks like, on Windows 8 Developer Preview.
As show in the video above, you can browse through various sets of examples. You can click on an individual example, view the corresponding code, modify it and run it inline.
TrialTool is also integrated with Windows Search. You can hit "Windows Key" + F to bring up the search panel, type in the name of the API to search and select TrialTool from the list of applications to directly navigate to the API you are interested in.
TrialTool is also a Windows 8 Share Target. While reading MSDN documentation or looking at code sent over email or IMs, you can select the code, bring up the Start menu (usually at bottom left) and click Share. You can select TrialTool from the list of listed applications. The selected code is shown in a "code cache". You can select and add more code to the code cache and see how the snippets work. With this capability, not only can you just read documentation, you can actually see how the API works.
The project and the source code are available on codeplex. If you have an installation of Windows 8, simply download the zip file and run the bat file with Administrator privileges.
As seen in the video above, not all APIs are shown yet; I am working to make more APIs available. I am also working on adding features like syntax coloring and a better search, etc for this version of TrialTool for Windows 8.
If you are interested in helping out, please contact me.
A few days back, Microsoft released the Windows 8 Developer Preview that would give developers a peek into the next version of the operating system and to start developing applications.
HTML, CSS and Javascript was one of the ways to build Windows 8 native applications. The list of APIs in the reference was huge and I wanted a way to not just read but also play around with the APIs to understand and experience them. To this end, I ported the web version of TrialTool to illustrate the various Windows 8 APIs available.
The video below is a screencast of how TrialTool looks like, on Windows 8 Developer Preview.
As show in the video above, you can browse through various sets of examples. You can click on an individual example, view the corresponding code, modify it and run it inline.
TrialTool is also integrated with Windows Search. You can hit "Windows Key" + F to bring up the search panel, type in the name of the API to search and select TrialTool from the list of applications to directly navigate to the API you are interested in.
TrialTool is also a Windows 8 Share Target. While reading MSDN documentation or looking at code sent over email or IMs, you can select the code, bring up the Start menu (usually at bottom left) and click Share. You can select TrialTool from the list of listed applications. The selected code is shown in a "code cache". You can select and add more code to the code cache and see how the snippets work. With this capability, not only can you just read documentation, you can actually see how the API works.
The project and the source code are available on codeplex. If you have an installation of Windows 8, simply download the zip file and run the bat file with Administrator privileges.
As seen in the video above, not all APIs are shown yet; I am working to make more APIs available. I am also working on adding features like syntax coloring and a better search, etc for this version of TrialTool for Windows 8.
If you are interested in helping out, please contact me.
jsFoo - Bangalore
I was at the jsFoo Conference, Bangalore yesterday.
I had two sessions, one on IndexedDB and the other on how Javascript Engines work. Here are the attached slides. The videos of the sessions will be made available shortly.
I had two sessions, one on IndexedDB and the other on how Javascript Engines work. Here are the attached slides. The videos of the sessions will be made available shortly.
Indexed DB
View more presentations from Parashuram Narasimhan
Understanding Javascript Engines
View more presentations from Parashuram Narasimhan
Subscribe to:
Posts (Atom)