Crafting the SAPO Campus platform, a thousand pixels at a time.
Latest posts

High Performance Javascript - dealing with JSON

No Widget is an Island

Designing Email - Part II

Designing Email - Part I

The amazing "widget" object

The Facebook Witch Project

SAPO Campus keynote from OSL Unesco demonstration session

SAPO Campus session at the UNESCO OSL Seminar

SAPO Campus - Eden Seventh Open Classroom Conference

SAPO Campus leaflet for the UA freshmen


Janeiro 2011

Novembro 2010

Fevereiro 2010

Dezembro 2009

Novembro 2009

Outubro 2009

Setembro 2009

Julho 2009

Maio 2009

Abril 2009

Março 2009

Fevereiro 2009

Dezembro 2008

Novembro 2008

Outubro 2008

Setembro 2008

Terça-feira, 28 de Julho de 2009
Notification Server: Widget Support
After concluding yesterday's post about the Javascript-powered Notification Server, I realized it had a gaping hole the size of the Grand Canyon. The platform could send notifications, but what about support for widgets? It sure would be cool if widgets could join in on the fun.

After about half an hour, the Notification Server supported notifications coming from widgets. The way you send out a notification is a little different, but still easy nonetheless:
var notification = {};
notification.kind = "success";
notification.message = "A hearty hello from me, the widget! I'm at the beach you see :)";

Basically, you just need to create an empty object and populate it with the kind and message variables. You can omit variables, of course, causing their value to default to the Notification object prototype. You can probably notice I made no mention of callback: right now, defining a callback is not supported due to security reasons - a malicious widget could try to execute a platform function or even on another widget.

widget.sendNotification is actually a custom extension to the Netvibes UWA, and is meant to abstract the widget developer from the rather ugly Environment.sendRemote command, which sends a remote message to the widget platform.

Also, as of now, widget notifications are considered slightly less important than platform ones. The current implementation forces a skew parameter with a value of -1 on notifications coming from widgets, which decreases their overall priority by one point in the priority queue. This may be subject to change as development wears on.

Published by bruno-abrantes às 11:32

Segunda-feira, 27 de Julho de 2009
Development Peek: The Notification Server
For the past week or so, I've been directing part of my development efforts into building a Notification Server for the SAPO Campus PLE. The concept was inspired by the bottom bar prevalent in most Facebook pages:

The need for a notification system arose from a pretty obvious concern: sometimes the connection to the server would drop, and every action which needed to access the server (using AJAX) would silently fail. This means any work the user did since the server gave out was effectively lost, without any kind of feedback.

The design of an error reporting system quickly evolved into an abstract notification system, which could be used not only to provide error feedback but also general messages of interest to the user.

Thus, the basic design of such a system lies on two different components: a Server Manager and an Interface Manager.


The Server Manager

The Server Manager listens for notifications and pushes Notification Objects into a priority queue. Each Notification Object is, at heart, a jQuery Event object, and implements a series of custom properties (defined in the object prototype, and thus easily overridden):

Internally, the Notification Object is expanded to contain other properties (priority, timeToLive and wasBorn) which are used to control the object's place in the queue, and whether it is fresh enough to be shown when its time comes (This prevents the kind of scenario when a significant number of notifications are queued up, and the ones being shown to the user are no longer relevant).

A periodical function determines if there are unread notifications available and whether it's alright to show them (a delay is in place to allow the user to actually read the notification). If both conditions are true, the notification is pushed through to the Interface Manager and the Notification Object is removed from the Priority Queue.


The Interface Manager

The Interface Manager receives new notifications from the Server Manager and shows them in the interface. There aren't a lot of complex things going on in here, but here are the highlights anyway:

Note that the callback function actually lives in a closure, so any local variables you use while defining the callback function are kept just as they were when the function was passed on to the Notification Server. If you wish to evaluate variables as they are when the callback runs, you need to use public or privileged variables/functions.

Here's how the interface currently looks like (not designer approved yet, mind you!):


Ok, so how do I use the Notification Server?

If you're developing on top of the SAPO Campus PLE Platform and need to display awesome messages to your users, tapping into the power of the Notification Server is easy as can be:

var notification = new Notification();
notification.kind = 'error';
notification.message = 'Han shot first!'

What's going on here is pretty straightforward: you're creating a new Notification Object, and all you need to do is alter the properties specific to your situation. In this case, all we really need to change from the default values is the kind and message properties. After creating the object, shoot it into space using jQuery's trigger() method, passing the object as a parameter.

Notifications are automatically sent whenever an AJAX request is made, and also when the requests are either successful or error out.

Published by bruno-abrantes às 16:39

About us
Janeiro 2011








todas as tags

subscrever feeds