Category Archives: Javascript

Flicker-Free IFRAME refresh

One of our projects consists of single parent page and “widgets” that display secondary (classic ASPX webform) pages. A recent feature request was to auto-refresh widget information at given intervals. On the surface it was pretty straghtforward:

<iframe id="xIfrWidget0"></iframe>
var ifr = document.getElementById('xIfrWidget');

setInterval(function () {
   ifr.src = 'widget.aspx';
}, 2000)

The problem with this approach – there’s an ugly flicker of white between page refresh and the goal was to keep displaying current IFRAME content up until refreshed content is ready. Yes, there’re various AJAX-ified methods (including ASP.NET UpdatePanel) – but they add unnecessary overhead and may cause other issues.

The solution was suggested by this Stack Overflow post. The idea is to have secondary, hidden IFRAME into which perform actual load. Once load complete – switch IFRAMES – currently visible with old content becomes hidden, and hidden one with new content becomes visible. It goes something like this: Continue reading →

Unblock my heart, i mean, iPhone for Pebble geocoding

Cobblestyle I’ve recently updated code for Cobblestyle Pebble Watchface to take advantage of very cool geocoding service called Nominatim by Open Street Maps.

Nominatim is used in two places: Direct lookup is used in watchface’s config page to lookup coordinates of a place by its name for custom location setting; reverse lookup is used to lookup location name by its coordinates to display name on actual watchface.

It was working fine – on Pebble watches connected to Android phones. It was failing miserably on iOS, so iPhone Pebble users were getting neither location nor weather updates. And it was pretty puzzling for a while until I obtained logs from running watchface thanks to invaluable help from Robin.

Turned out iPhone Pebble app was plain simple blocked by Nominatim service, every attempt to retrieve location resulted in message being sent back “You have violated acceptable policy”. Which was kinda surprising since I just started using the service. When I contacted Nominatim support, they told me that apparently some Pebble app running from iPhone abused the service pretty badly, running hundreds of requests per second. And since the only way they can detect requesting app is by it’s User Agent string – all apps spotting iPhone Pebble UA were blocked.

Support suggested to set UA string specific to the app so it could be easily identifiable. Standard approach to set headers on xmlHttpRequest object is .setRequestHeader(..). Unfortunately by many browsers and clients it is considered unsafe to spoof UA via request headers. Fortunately iOS allows that, so all I have to do is catch and ignore errors in other clients. Basically this line of code solved the issue: 

try {
    xhr.setRequestHeader("User-Agent", "Cobblestyle Pebble Watchface");
} 
catch(e){}

Thanks to this as of version 2.19 Cobblestyle watchface correctly displays weather and location information. Yay.

Fire on High or Framebuffer in Rocky.js

First things first. DISCLAMER: Everything described here is a hack upon a crude hack and most likely, barring a divine intervention, won’t work in final product. And I apologize in advance to Pebble dev team if my attempts at “hacking” seem silly. Now to business. Pebble SDK offers very cool framebuffer API that allows developers to address display memory of the watch directly. This makes possible creation of many cool special effects (matter of fact EffectLayer library uses framebuffer extensively).
Rocky.js is JavaScript incarnation of Pebble SDK and it made me wonder whether it offers framebuffer access. Turned out it is hidden, but it’s there. At least at the latest commit at the time of this article it is. If you take a look at source file html-bindings.js you will see that binding function looks something like this:

Rocky.bindCanvas = function(canvas, options) {
  
  //...
   
  var framebufferPixels = new Uint8Array(module.HEAPU8.buffer,
                                         framebufferPixelPTR,
                                         canvasW * canvasH);

  //...

  var binding = {
  
  //...

  }

  //...

  return binding;
};

Continue reading →

Persistent configs in Rocky.js watchfaces

Rocky.JS is the first step in Pebble journey to run JavaScript directly on the watches (unlike Pebble.JS which runs on your phone). Previously I described how to convert a simple watchface from C to Rocky.js. But that was a static watchface with unchangeable settings.

Here I will show how to create a configurable watchface in Rocky.js similarly how classic SDK faces can be configured. You will be able to reuse your existing config page – and if it was set to work with Pebble emulator as well as real watch – you will reuse it without any changes at all.

First let’s review how classic Pebble SDK calls config page. In PKJS (JavaScript) portion of Pebble code usually there’s a piece like this:

Pebble.addEventListener("showConfiguration",
  function(e) {
    Pebble.openURL("http://my.cool.server/pebble/my_cool_config.html");
  }
);

If user requests config of face/app – this event fires and opens page with configurable options from specified URL. After user modifies settings usually “Save” button is clicked on that page and code similar to this executes:

$('#xbtnSave').click(function () {
   var location = (decodeURIComponent(getURLVariable('return_to')) || 
                   "pebblejs://close#") + 
                   encodeURIComponent(JSON.stringify(settings));
   document.location = location;
})

Here, first we determine which location to redirect config page to. If parameter "return_to” is passed in query string (here custom function getURLVariable() is used to extract individual parameters – look it up), so if this parameter is passed – it means config page is called form the emulator and we use it for redirection. Otherwise we use standard "pebblejs://close#" URL to save settings into real watch. We also take settings object which has our collective options combined, convert it to string and add to the URL as a parameter. Page then is redirected to resulting URL and Pebble emulator or real watch takes care of processing parameters.

So, how can we (re)use it in a Rocky.js watchface? Continue reading →

Rocky.js – Pebble watch coding in JavaScript

Pebble never ceases to amaze. And every time you think – this is it, they reached the pinnacle of awesomeness – they surprise you again. This time they did pretty much the impossible – ported their C SDK to JavaScript, by creating Rocky.JS project. Ultimate goal is to run JS directly on the watch hardware – this will open way to huge number of new developers who hesitate to dive into depth of C. Meanwhile it provides ability to run Pebble code directly in a browser! It’s a lot of fun and as a bonus you can insert Pebble watchfaces directly into your website as evident by living watchface you see here.
Watchface you see running above is called Meyer Object it’s been available for Pebble watch for a while and I decided to port it to Rocky.JS Continue reading →

Fixing problem with Yahoo geolocation service

Recently two Pebble watchfaces I’ve developed based on Paul Joel designes: Clean&Smart and Cobblestyle began to experience weather update issues – as in “weather was not updated at all”. Looking into the issue I found a weird thing: If you set your location manually – weather worked. But automatic weather based on phone location did not.

The way automatic location works is pretty straighforward. First this function is called to determine location:

function getLocation() {
  navigator.geolocation.getCurrentPosition(
    locationSuccess,
    locationError,
    {timeout: 15000, maximumAge: 60000}
  );
}

It uses phone location services (GPS, if its available, otherwise network-based location). In case of success it calls locationSuccess function. And in my tests it always called it, so location was determined successfully. Continue reading →

Detect IFRAME click from parent page

If you need to detect a click on a Web Page, that’s trivial: just catch Document or Body onclick event and any element on the page you click will bubble the event to your handler.

But if one of those elements is an IFRAME – that won’t work. IFRAMEs contain other pages and their events a contained within their content and don’t bubble up. Luckily there’s a way. Take a look this snippet of jQuery code:

$('IFRAME').on('load', function () {
   $(this).contents().on('click', function () {
      alert('Click Detected!');
   })
})

It attaches handler to IFRAME’s content’s onclick event, but only after IFRAME has already been loaded. Place this code in parent page that contains IFRAMEs and it will work universally across all browsers to detect when IFRAME was clicked.

NOTE: As usual in these scenarios, this works only if parent page and children pages comply with Same Origin Policy.

Developing first Pebble.js app

    

Pebble Smartwatch has offered SDK to develop watchfaces and watchapps in C language for a while now. But most recently they tried something different: Pebble.JS a project that lets you code for Pebble in JavaScript. Unlike native app – JS code runs on your phone, so it’s not as fast, and Bluetooth communication required to display any data, but there’re numerous advantages as well.

To test it I decided to write a simple app that would use basic, but important features of Pebble.JS: displaying of information card (a la Pebble notifcation), using menu and executing an AJAX call to bring information from the Net.

Enter AutoInsult for Pebble – application that is based on autoinsult.com – it generates a random insult based on style you selected.
Continue reading →

Access jQueryUI dialog buttons after dialog was created

If you’re using jQuery UI Dialog, you know sometimes there’s a need to access dialog’s button objects after the dialog has already been created. This can be easily done via 

$(dialogElement).dialog("option").buttons

command. One possible scenario where this can be useful – is executing specific button click function when user clicks [X] in dialog title. Imagine that buttons are set via array and the last object in this array is always something like CANCEL or NO or DISREGARD – and you want to simulate click of that last button whenever user clicks [X]. Using above command it’s pretty straightforward:

$(oDivDialog).dialog({
   //... some dialog parameters
   buttons: arrayOfButtonObjects,
   //... some more parameters
   close: function () {
      var buttons = $(this).dialog("option").buttons;
      buttons[buttons.length - 1].click();
   }
})

Line 5 begins close event which is called on dialog closing.
Line 6 retrieves array of buttons for the dialog
Line 7 calls click() function of the last button in the array

Infragistics WebDataMenu: Manual postback from client-side Click event

There’s a a few possible scenarios when you need to manually to initiate server-side Click event of Infragistics WebDataMenu control. For example in client side click event you do some verification/user confirmation and upon positive confirmation (e.g. user clicks YES) – server-side Click event should kick in.

In a normal flow of event you can use set_cancel(bool) method to allow/disallow natural menu postback e.g.

function Menu_ItemClick(sender, eventArgs) {

   if (confirm('Are you sure?'))
       eventArgs.set_cancel(false)
   else
       eventArgs.set_cancel(true)

}

This works because this dialog stops code execution waiting for the user input. But what if you use something like jQueryUI dialog that relies on callback functions to get user feedback? In this case execution of the code continues immediately so you have to cancel postback right away and instead in the callback of the dialog initiate manual postback e.g

function Menu_ItemClick(sender, eventArgs) {

   $("#dialog").dialog({
      resizable: false,
      height:140,
      modal: true,
      buttons: {
        "Yes": function() {
          $(this).dialog("close");
          __doPostBack(sender.get_id(), 'ItemClick' + eventArgs._getPostArgs());
        },
        "No": function() {
          $(this).dialog("close");
        }
      }
   });  

   eventArgs.set_cancel(true)

}

The example above initiates modal confirmation jQuery UI dialog and immediately cancels menu postback (Line 18). Later if user clicks “Yes” button – dialog is closed and manual menu postback is initiated (Line 10) – it passes menu ID and correct postback argruments which result in server-side Click event of menu control. If user clicks “No” – dialog is closed and nothing else happens.