Parse’s going down…

I was a bit shocked reading the following article.

Just choose to use Parse. Built an extension on it. Blogged about it. Loved it with all it’s problems.

It will be shut down not tomorrow of course but January of 2017 will be here soon. 😦

That’s how life works. Heads up! I will choose an other solution and of course will blog about migration from Parse and about the new solution I will use. 🙂

Browse Wisely – The Extension

bw (1)

Through the previous posts I wrote about my experiences developing an extension. Browse Wisely is the extension I wrote about.

Browse Wisely is published now!

You just need to visit the Chrome Web Store, download it and you can get the experience of smart browsing.

chromestore

Browse Wisely have the purpose to help controlling your browsing habits. You can set rules not to spend too much time on selected pages.

Set block rule with a time frame and the extension will not let you visit the selected site. It will automatically redirect you to a random Wikipedia site. You can read the article and learn new things.

Set a warning rule with defining the site you want to monitor and the time (in minutes) to warn you after. If you spent the given time on the page you will be warned. You can navigate to TED videos. Sneeze the warning for 5 minutes. Restart the timer or dismiss the whole warning panel.

 

It could be a pleasure to see you between my users!

If you try it feel free to write me a comment or send me an email. I’m happy for all the feedback. If you find a bug or have thoughts about features I could build in write to me.

 

Links to know more about the extension

To try it out

visit the store and download Browse Wisely.

To know more about the extension

visit the marketing site of Browse Wisely.

To follow the development phases read the posts

about the extensions in theory and in practice,

about React tricks with TypeScript,

about the React development,

and about the Parse and login flows.

It will be open-source soon. The skeleton of it already available.

Parse + Login with Facebook

If you create an application you probably will need to handle users somehow. If your application is front-end heavy and didn’t require big, complex database or complex server side login, you don’t want to spend too much time developing it. That was my situation with my extension as well. I wanted only store some user data and the user’s rules. Rules to control their browsing habits. So I searched for an easy to use, fast to setup and a cheap solution. That’s when Parse come into picture.

Parse

Parse is a platform. A cloud-based platform that provides a complete backend solution for your application. Parse’s goal is to totally eliminate the need for writing server code or maintaining servers.

The Parse team is using striped 1000 Provisioned IOPS volumes for MongoDB clusters running on Amazon Elastic Compute Cloud (Amazon EC2) instances. What is very impressive to hear. You can read more about it.

But let’s see what it offers to you, to the developer:

Easy to use. It is just some click to create your first application. Creating some tables is easy as well.

TIPP : Adding data and creating some extra relations between tables are more than the Launchpad is capable for. You need to use your code to do that. Sometimes it is not just the easiest way you can find it is recommended by the developers of Parse as well.

Really well documented. The basics are all in the documentation. They have FAQ section with really good answers.

TIPP : Only thing what I couldn’t get from them is a really useful documentation about authentication with Facebook if it isn’t the basic way and third party authentications. But more about it later in the second part of this blog post.

Easy to observe. You can monitor all of your data on the Launchpad. It is easy to check, update and delete the existing data.

TIPP : If you open your app on the Launchpad, choose the Data section and see nothing don’t panic. It shows you always the Analytics tab first. Change to Core and you will get your data you wanted to see.

Easy to use in code. It provides a lot of SDKs and a REST API as well to handle data from any platform.

More. It can do so much more than I used it for. It can send push notifications, show you analytics about everything and more.

Handle growth. If your app grows bigger and require more logic on back-end you have the first option to write some cloud code. There are hooks to handle the incoming and outgoing data.

After getting bigger than this you have one more step not to leave Parse just extend it. The Parse Hooks API that makes it possible to use your own Node.js server in conjunction with Parse.

But if nothing is enough you can easily export your data into JSON. Build your own server side and fill your data into your database with parsing data from the JSON files. Each table with the containing data will be one file.

And not to mention it is free. Free for commercial use until your app will be so big that it isn’t a problem paying for the services.75689840-7165-4c58-a2af-eb8a06a27c20

It is in hands of Facebook. It can build trust and give some kind of guarantee if such a big company is behind it. Like in case of React. It is used and tested in such a big user visited site like Facebook. It is part of the Facebook Open Source Program.

TIPP : Parse’s Javascrip SDK is open-source. Checking the code could help so much if you can’t find or understand something.

Developing with Parse

Parse gives you a really cool REST API to handle data in the universal mode. But if you want to have something platform specific you have options too. It provides a  lot of SDKs. It has Android, iOS, PHP, .NET an so much more. Of course it provides a JavaScript SDK as well. But working with Parse in TypeScript isn’t a problem neither because it has typings available too. You can use a direct link or install it with TSD.

Not to mention if you develop a React application using Parse you get an extra customized SDK to React.

It supports everything we need to start developing our extension.

It is one line only to initialize:

Parse.initialize("$PARSE_APPLICATION_ID", "$PARSE_JAVASCRIPT_KEY");

Building blocks of it are the Objects.

Parse.Object contains key-value pairs of JSON-compatible data. This data is schemaless, which means that you don’t need to specify ahead of time what keys exist on each Parse.Object.

parse-blog-1

You can use your Objects through Querys.

parse-blog-2

ruleParseObjects is the container list of all the original Parse.Objects.

Objects have the save and destroy methods on itself. So if you cast your data to something else like me you need to handle the linking between the new objects and the Parse objects. I created an IRule object from the Obejcts given by Parse, passing only the data for my React components. So I saved in my parseService class the original Obejcts as well. Linked them with the object ids to the IRule objects.

parse-blog-3

TIPP : It is important to be careful with naming convention because Parse can’t handle it. It will create new columns in your data table if you misspell something.

parse-blog-4

It is so easy to use. The goals of this post was only to show you how easy to use Parse for simple problems. After knowing the basics of Parse let’s see the bigger problem that I used it for Parse as the solution. It was the login. It has three parts to get things work. Setting up Facebook, setting up Parse and hacking the crazy things of an extension.

Login with Facebook

Using Facebook logic didn’t come so obvious for me. If you are someone like me you neither like to give access to your profile for unknown applications. But I thought about it and something I more dislike is to register myself again for something new. Problems with giving a unique nickname or finding out a new password – sometimes with too strong requirements – and of course remembering all of that is more frustrating for me. So I decided to save this procedure for my users. Made their life with that easier I think. It is just few click to register and to login. Think about it. It requires only your email – for custom registrations it is also required – your name and sometimes some public data. Only public. Data, what is already available for everyone on the internet. Actually it isn’t so strange to do that from this perspective.

It could be of course not just the Facebook to login. It could be Google+, Twitter or whatever third-party login as well. But Parse gives you the Facebook login out of the box. I decided to lunch my application with it and after some user feedbacks or after a hundred of users I will work on adding other login providers to my app. Doing so isn’t so obvious with Parse.

But let’s see how I built Facebook login into my extension in. It wasn’t as easy as I first thought.

Creating a Facebook app is easy. It is really well documented. (As I mentioned it previously by React and Parse too – Facebook does this documentations thing good, makes developer’s life easier)

Register your Facebook app.

After having the Facebook account registered as a developer the next step is to register the url of your website for getting things done. The url of your extension is chrome-extension://iccdneeippnmcmbaekeoonkckkjhojfi/UI/Popups/index.html. It runs in the local environment of users installed your extension. It isn’t the url you could use. So you can’t register your extension as a web app / website.

Here comes the trick. You need to host a site with the scripts of the Facebook init and login. After that you need to add this site to your extension as a content of an iframe. You didn’t need to create a whole login site and change your extension’s login site to it. I created only a button for this purpose. An iframe with a size of a button and the site hosted somewhere only containing a button.

OK, I can login with Facebook now but how does the extension know about it? – could be a right question. Here comes the messaging system of the extensions into the picture. But let’s see the Parse part of the login first.

Parse part

Parse gives you Facebook login out of the box. After checking the tutorial on the Parse site you could reach an incorrect conclusion as I did. I thought first that I need to use the two together as it is in the examples.

parse-blog-5parse-blog-6

 

After I logged in the user that way I checked what happened. I had the logged-in user on my site, not in the extension. I thought I can post the required credentials to the extension. I checked what are stored into local storage after the login process because I saw that the Parse.User.current() method operates with the data in the storage. So I passed the local storage data to the extension saved into the local storage of the extension. After reloading the extension it could link the session on Parse side with the local storage data in the extension. Sounds terrible I know and it worked only deterministic way. Sometimes not. I needed to find something better. A real solution.

This was the first time when the documentation of Parse couldn’t help at all. So I searched for similar problems and I could find something. There is an option to give credentials for the FacebookUtils.login method of Parse. It means you can handle the two login separated. Login your user first with Facebook and after that logging your user with the Facebook’s credentials into Parse.

parse-blog-7

This was the original code of Facebook to handle login and get some user data. This site and this code will be embedded into an iframe – into an iframe of the extension. So the easiest way to send message to the extension’s background page is getting the top window and sending the message from it. The receiver code which will use Parse’s login with passing the credentials is on the following picture.

parse-blog-8

So this is the way the user can log in with using only one button. With the button loaded into an iframe hosted on a separated site which handles in the background everything else. Logs the user with Facebook in, send the login data to the extension and login user from the extension into Parse leading to the authorized user using your extension. That’s the way you can succeed all the login from the extension. It was not so easy to find out but it’s simple and clean as the result.

Summary of Extension tricks

1, Extension itself doesn’t enough if you want Facebook or Google+ login. Both – and almost all other – requires an address of your site. So you need to have a somewhere hosted site. After having the Facebook website configuration you can’t trick with calling it from your extension. It only works with the origin site built into the extension with an iframe.

2, Login with two separated steps. Login with Facebook on the hosted site and send credentials to the extension through the messaging system of the browser. After that login with this credentials to Parse. That’s how you get an authenticated user in your extension on an easy and fast way.

React with TypeScript

Introduction

 

If you red my previous posts you probably know that I currently develop an extension in TypeScript.

For implementing the UI part of the extension I chose React. React because it is super hyped nowadays, I was interested and always good to learn something new.

About React itself and about the development details developing with React it will be an other post as it is planed. But I thought this part of my journey with React deserves a separated post.

Let’s see how I get together React and TypeScript for my extension.

 

Start getting TypeScript together with React

 

The release of TypeScript 1.6 includes support for React components.

That means you don’t need to use any module dependency handler, like Browserify to handle React modules.

It’s really nice. Let’s try it out!

You install typescript with npm:

npm install –g typescript

You check the version you have installed:

npm view typescript version

It is the newest. 1.6. Cool!

Try to use the tsc compiler with ––jsx or with ––project (including jsx handling as well).

 

The first problem

 

Do you have Visual Studio installed to work sometimes with that too?

Yes? – That’s the problem!

I work on Windows with WebStorm 11 but for other projects I have Visual Studio 2015 installed as well.

Visual Studio makes its compiler for windows as default. Command line will try to use it first.

 

Solutions

 

Check your Visual Studio folder:

C:\Program Files (x86)\Microsoft SDKs\TypeScript

Does it contains any TypeScript versions under 1.6?  Yes?

  • Solution 1

Upgrade the Visual Studio’s TypeScript from here.

  • Solution 2

Just delete the older TypeScript versions.

  • Solution 3

Set an explicit system variable pointing to the npm installed version of TypeScript compiler.

 

 

Getting TypeScript together with React

 

After letting this problem behind you can try out the TypeScript compiler.

Install React and ReactDOM with npm.

npm install –save react react-dom

Install typescript definitions for them with tsd.

tsd install — save react react-dom

If you are using modules you should use react.d.ts, react-dom.d.ts and any of the react-addon-*.d.ts definition files.

Use them in modules you need:

import React = __React;

import ReactDOM = __React.__DOM;

If you are using the global React variable, you should use react-global.d.ts.

You need to download the react-global.d.ts file from the DT site and copy it under the typings/react folder.

Include React and ReactDOM in index.html. (From CDN or from your sources.)

https://fb.me/react-0.14.3.js
https://fb.me/react-dom-0.14.3.js

 

Create your UI

 

Write your demo button .tsx file:

react from extension

If you didn’t handle page load in your code and include your scripts into the head, you probably will face the following error in your inspector console.

Uncaught Error: Invariant Violation: _registerComponent(…): Target container is not a DOM element.

A quick fix could be if you write your script tags at the bottom of the body tag. Handling all of this is better from code I think. I wrote it down just because if you see this error this is the fastest way to move on.

react from extension

Including scripts at this point of your site isn’t from the devil. With React you have the option to do that and you can read a lot of good thoughts about the benefits of including scripts this way.

Having to code is one thing you. You need to create a deploy-able package from your source.

 

Compile for publish

 

You can do it from command line manually with tsc. You only need a good configuration json.

tsc –project tsconfig.json

Or you can choose an automated way, using Gulp. Gulp could be good for handling other automatized tasks as well. In this post we will check only the typescript compiler task of it.

You need to require the TypeScript compiler:

var ts = require(‘gulp-typescript’);

And use the “createProject” method of it. It will create a configured project according to the settings in your json file.

The project’s src is defined in the files section of the json config file (if not all files will be included).

react from extension

Let’s see the magical tsconfig.json file that we could use for the command line compiler and for the gulp task as well.

react from extension

For all setting options detailed, visit the following sites.

Schema description. Just the facts.

Github wiki with more explanations.

If you don’t have a lot of options and you don’t want to outsource it to a json file, you can configure the ts compile in the gulp file as well.

react from extension

 

Run it and it will work fine!

Extensions – Practice

In the previous post you could read about the main parts of an extension. Short and just the definitions. Let’s see them in practice.

TypeScript

I used TypeScript for the development. We decided to choose this instead of the plain JavaScript because a lot of developer worked on the original project. There were a plenty of misspelling errors – figured out only in run-time and we had problems to keep everything in hand. We needed regulations a more structured and controlled environment for developing in JavaScript. That’s why we choose TypeScript to work with. I only get used to developing with it that’s why this project is in TypeScript as well.

Developing this way requires only a few extra thing to do.

  • You need to use typings (type definitions for JavaScript). The definition files of regular JavaScript libraries. But you don’t need to panic, because it is collector portal and you can find here a lot of typings for different libraries. – really a lot, I found typing for so small libraries I couldn’t believe it first. (:
  • You need to compile typescript files. But doing this is supported by gulp. You can easily add automation to do it with a single gulp library, called gulp-typescript.

Structure

Here is the structure for my source.

path

Well separated parts: Background, Content, UI, Manifest like the architectural parts of an extension + Common and Assets. Files in this structure will be explained in the following sections.

Other infrastructural elements of my solution.

path2

  • Gulpfile for automation
  • package.json for libraries installed with npm
  • tsd.json for type defintions installed with tsd
  • gitignore for github
  • and dist for gulp-generated, package-ready files.

Messaging

We have these parts: Background page, extension’s UI and content script.
What we have in common, they all communicate with each other.
Messaging connects all of them.

So for a good extension skeleton we need a good messaging system.

In my solution I built a base class for all my components that contains the mechanism of messaging. My implementation based on broadcasting.

From content scripts we send a message which one all the background scripts based on my baseClass will get but only the subscribed ones will handle it. One event could be important for more parts of the background components. Same from the extension’s UI.

Background scripts will broadcast their messages to the content scripts and UI scripts as well. UI scripts can’t communicate direct with the content scripts but through the background script they can. Sending the message from UI to the background script and forwarding from the background script to the content script that’s how it could work. 

Every base class have the same functionality.

msg1

In the constructor you pass the event handler of your actual component for the browsers event handler. Browser part will be explained in the next section – these are the common, browser independent parts.

You have this base class with two arrays for all your component’s classes. Listeners and pending responses. Storing them and checking them at every action will provide that you didn’t lost any message or reply in the extension’s messaging traffic.

As an example. I created the test file. It defines its event subscriptions in the constructor. Other classes extending the base class will have own arrays for all of that. Every component will know for which events they interested or for which ones not.

msg2

The actual ‘on’ subscribing method adds only this subscription to the array. Going through the array and checking which events to handle will happen if the browsers listener will get a message.

msg3

Sending a message will be the preparation of a well defined event package and the triggering of the event. Triggering is different in the different browsers that’s why it is only a method here, a method of the browser.

Browser & Component differences of messaging

As I mentioned all the base classes are only duplicates. In the code yes, but in every component we will use a different browser implementations. So we will have browser file for Background scripts, Content Scripts and UI scripts as well. First I will show you these differences. So the different browser implementations of the different components. After that I will show the actual browser differences, that are because of the two different browser, Chrome and Firefox.

Isn’t clear yet? – No problem. I will show everything in practice. I hope it will make things clear.

Background script:browser1

chrome.runtime.onMessage.addListener is the method of the chrome API to handle event subscriptions. If we get a message we will iterate through all of our subscribed class’s callback – remember base class passed in its constructor to the browser implementation – and call them with the actual event data.

Filling this array, the eventListeners array happens through the eventReceived method.

browser2

Sending a message from background scripts has two steps. Sending the actual message to the scripts in the UI and sending them to the content scripts. Both have different ways.

browser3

UI can communicate directly through the run-time with the background script so we can use it to deliver messages from one to other. But as I mentioned it in my previous post, Content scripts are not part of the extensions technically. They will get the messages through the actual page, into they are actually injected. We can get all the pages opened in the browser in our background script with the chrome.tabs.query and we can send the message to all of them. Only the page containing our injected logic with the event handlers will do something with the message the others will ignore it.

Content script & UI scripts (Popup):

Background need to use other method to send message to Content Scripts and UI scripts but they can get messages through the run-time and can use it to sending the messages as well in the same way.

cs1

cs2

The type in the sendMessage is for the browser. Extension communication go through  the type, message. In the payload we can define our type as well. Identifying our messages with our types/names.

UI scripts implementation is for popup types, not for panel types. It is differentiated in chrome. More about it you can find in my skeleton implementation.

 

Messaging in Firefox looks different. In background scripts you have to create a panel as the main component of your extension. It has a port, we can use for sending and getting messages.

In content scripts and UI scripts we have a ‘self‘ or ‘addon‘ object with the port or we can use the window object for sending and listening events. More about it you can find in my skeleton implementation.

Other browser differences

We need to hide more differences not just messaging. So little things like timeouts are different in the browser.

In Chrome:

br2

In Chrome background scripts you can use a fully featured window object, but in Firefox you don’t have the timeout functions on that. You have a timers SDK to use for that.

In Firefox:

br3

In Chrome you can use the chrome.* objects and methods.

In Firefox you need to use the underlying module handler – the built in CommonJs for getting the SDK’s libraries.

br1

More feature that needs different implementations according to the actual browser will come. In the skeleton I needed only these ones. I think in later posts there will be more about this differences. Don’t miss them.

Extension bootstrapping

Bootstrapping the extensions are very different in the two browsers.

Chrome uses the manifest.json for all the things.

manifest

It will bind the Ctrl + B key-combo to start our UI. The UI will be the default_popup’s html. We define the background scripts and the content scripts as well. Chrome will know what to do with them.

Firefox have a few details in the package.json file.

manifest3

It defines only the path of the background script and Firefox will use the background script and the browser’s SDK to create the parts of the extension.

manifest2

You define here the panel and it properties. The icon (= button) in the browser’s toolbar. It handles the show and hide of the extension’s UI. Injecting the content scripts happens also here with the pageMod SDK library.

In case of content scripts the * defines that we want our script injected into every opened tab, we define the path of the script and we want to load and run the script on document ready event.

In Chrome (previous picture) matches: <all_urls> is the same with the * in Firefox. Js defines the path. Run_at is the same as contentScriptWhen. In Chrome we have an extra option to include our script not just into the page but into all of the iframes the page contains. Firefox uses other option to do that.

aaaaa

All the sources mentioned in this article you can find in my repository in github. You can check it: https://github.com/FerencKun/extensionbase

If we are ready with the development we need a good automatized infrastructure to build the files and prepare them for packaging and publishing.

Automations with gulp

Developing an extension for both browsers. Chrome and Firefox. Without gulp could be very hard. Gulp task can help us make the right package for both browser with a little configuration and with parameterized tasks. Here I don’t have space to define what gulp is. Please let me speak about it so as if you would know the basics of this technology and if you didn’t, here are some good links to learn more about gulp.

One big difference is that in Chrome we can add more background scripts but in Firefox we can only define one file. So we need to concat all the background scripts into one.

gulp

Using TypeScript makes our work easier, but for packaging we need of course the compiled JavaScript. Gulp helps.

gulp1

We can add our different browser files with the gulp task in our copy task but we need different path settings in html files. (If we don’t want to rename our destination files.) There is an option to do it with gulp as well.

We can define string patterns (with custom prefixes) to replace with value in that place too. In html I will define //@@browserFilePath and gulp will replace it with chrome.js or with firefox.js according to the parameter.

Now we have the already ready files to package them for the browsers. About packaging and and publishing I will write about later. I hope this much content will be enough for this post. But more info in this theme will be coming soon.

To be continued…

Extensions – Theory

Update: I started to write one post about extension basics but it grown too big. So I decided to write two about it. One about the theory and one about the practice. So this one will be more readable. I promise the other one will contain codes and minimal of talk. You can easily skip this one if you are familiar with extension basics and you are interested only in checking my solutions for developing one.

extensions.PNG

Extensions. Extensions everywhere. This was my previous half year about as I mentioned it in the previous post. It was a good intro to this series I think, so I don’t want to start it with telling stories. Let’s jump into the world of browser extensions.

This post will be about the extension basics, where everything begins:

  • What is an extension exactly?
  • Which browsers are we talking about?
    • Chrome and Firefox
    • IE and Safari
  • What are the extension’s cross browser and reusable parts and what are not?
  • How to start developing extensions for multiple platforms?

What is an extension exactly?

“Extensions extend the functionality of the browser and the websites being viewed in it.” – this is the official definition of them.

Extension has little or no UI components. It isn’t their purpose to show a lot of information through visual elements. Their true power is getting and manipulating the tabs and their contents. That is what makes them sexy.

I think you already have some extensions installed. Maybe you didn’t know about them. Let’s check them in your browser.

In Chrome:

In Firefox:

Ok, you checked them. Maybe not so interesting ones (if you didn’t already use extensions). Check this examples:

One really good example is the extension of Evernote. It really uses the actual page’s DOM and makes cool things with it.

Another good one is Meldium. It uses more components of the API. Navigation, new tab opening, text injection and so on.

Now you know what an extension looks like and saw what they can do with your browser. And that was only the tip of the iceberg. But I hope you already started to feel that you need to create one. It is so much potential in one thing like that. Now what? Let’s google it. Let’s start searching for some development help.

Chrome Web app vs. Chrome Extension vs. Firefox Add-on vs. Firefox Extension

These could be the words you will probably find in this context. Which one? What I will create through this articles is something that is called in Chrome as an extension and in Firefox as an add-on. Your eyes work just fine. Chrome extensions are not equal to a Firefox extensions. Chrome extensions are the same as add-ons in Firefox. Firefox extensions are a smaller subset of add-ons with different functionalities. Nice isn’t it?

– If you develop for Firefox as well and search for something on the internet ALWAYS check that it is for extensions or for add-ons generally. Especially on the developer site of Mozilla. The two can use very different SDK-s in different contexts and you can just watch why it isn’t working. –

More about extension vs. app, add-on vs. extension:

Chrome app vs. extension

Firefox add-on vs. extension

I will develop simultaneously a Chrome and a Firefox extension. – I will write ‘extension’, but you know the term differences between the two browsers already.

IE and Safari have different concepts, installation process and have very different APIs to work with. So I skipped working on this platforms. Usage of this browsers is so dawn low.

Now we know what we want to develop. Let’s see what the bricks we can build with are.

Architecture of Extensions

What parts have an extension?

  • Manifest
  • Background page
  • Content script
  • UI pages (Panels and popups)

These are the terms in both cases, Chrome and Firefox. But of course it isn’t so simple. The meanings and implementation details of them are different in the two. This section will be about the definitions with some examples. We will see what are the similarities and differences between the two browsers handling the following components.

Manifest

First of all we need a manifest file. It will be the entry points of the extension creation.

In case of Firefox it is only a sort description file. General info such as name, author… From development site the permissions and the main part could be interesting but the Background script will make the big thing, what is done in the manifest in the case of Chrome.
We have permission almost everything by default. Private-browsing, cross-domain-content and multiprocess options are the editable through this file. The “main” property defines our background script.

Manifest file of a Chrome extension contains a lot more info about the extension itself. It defines beside the general things the content scripts to inject into pages (what and how to do), same with the background scripts. It defines the starting page, the icon and browser action to show/hide our extensions UI (popup). Permissions here are very different.
We have access to nothing by default and we need to list every item that we would like to use.  “tabs”, “cookies”, “storage”, “activeTab”, “webRequest”, “webRequestBlocking”, “clipboardWrite” and so on.

Background page

The name of this part could be a bit tricky because background page especially didn’t need to have actual view – html part. It is the place for the logic behind the extension. It could be only JavaScript file(s) – so it is in my case as well. It has the access to the extension SDK and here can we do most of the work we want to do in the extension. It connects all the other parts of the extension as well.

Background pages have two kinds. One for long running task. We can use persistent background pages. I will use only them. But there is another type you can use so called event pages. Event pages are loaded only when they are needed. With them you can freeing memory and other resources. You will see in a later post why I need the persistent ones. But to change from one type to the other is only one property change in the extension’s manifest file. (https://developer.chrome.com/extensions/event_pages)

arch-1

In the background you can write a reusable code as your business logic for both browser. Differences will come if you want to use the browser itself. There is a different API for the getting the chrome features as getting the Firefox’s one, of course. From setting a timer – setTimeout – to the sending a message to an opened tab in the browser. Background scripts in Chrome own a full featured window object. You can call the window.setTimeout easily. But in Firefox you have a window object with a reduced feature set. For setting a timeout you need to include the SDK’s timer lib. require(“sdk/timers”);

In Chrome you have the chrome object. Chrome.* functionalities are available for you by default. In Firefox you need to use require – Firefox have a built in commonjs infra to handle modules – to get the different SDK parts. More in the implementation details part.

After developing a while and if you start to check your extension in the browser you can check your extensions background page. It will help to debug your extension.

Where can you find your extensions background page?

In Chrome

base-chrome

IN Firefox

base-firefox

UI pages

These are ordinary HTML pages, styled with CSS and powered with some JavaScript. Most of the time these are options pages, which let users customize how the extension works.

We can see UI pages of the extension as small web pages and we could show some staff for the user but they are better used for interacting with the background part.

UI pages have 2 different kinds. One is the so called Popup. This is what the user get if he/she clicks on the icon of our extension in the toolbar and we show the user our standalone mini site.

arch-2

The other kind of UI windows are the Panels. They will be part of the actual page of our browser. Standalone window elements, over-layers on the actual page. In Chrome the content of the panel will be part of the actual page, it will be loaded into an iframe. In Firefox they are standalone dialogs. Not parts of the actual page’s DOM.

Actually in Firefox panels and popups are the same, just otherwise positioned. Popups under the extension icon in the toolbar. Panels to whatever part of the actual page.

In Chrome, Panels and Popups have different behavior in background. Such as sending a message looks different from the two different kind of UI elements. In Firefox these are the same with the same behavior. Firefox uses officially only the term of Panel.

UI pages can be inspected in Chrome. As usual just click on the opened window of the extension UI and you get the Inspect Element function. In Firefox I couldn’t find the possibility to check it.

Content scripts

Content scripts are JavaScript codes that we can inject into the web pages, the user visits. This codes share the window object with the actual page, can read and change the DOM.

arch-cs

Content scripts are parts of the loaded page, not the part of the extension. But it have the ability to communicate with our background page through messages – it is a two way communication of course. They are our spies behind the enemy lines.

In Chrome you can see and also debug your content script.

chromeContent

In Firefox I couldn’t find this option, even with Firebug.

Documentations with more info

You can use for the first hand info the developer sites of Firefox and Chrome as well. Both are well documented. You can find a lot of examples and good descriptions about anything. Firefox documentation was a little confusing for me. Chrome’s was much better. But during the development I think you will find yourself reading both of the developer sites.

 

So these were the main parts of our extension. Short and just the definitions. Next post in this topic will be about my implementation details.

Check it too.