This milstone adds quite a few nice features like bézier curves for Canvas, background-position and -repeat for CSS theming, and (especially) improved multi-tab browsing: It is now possible to host multiple UI-Sessions within the same HTTP-Session, meaning that there are no more tricks required to use multiple tabs with RAP applications in the same browser. Lets look at an example how multiple browser tabs can be used within a RAP application by integrating it with the markup and BrowserNavigation features.

Assuming our application lets the user select a person from a database to edit, the typical setup would be a TableViewer that opens a Dialog on a DefaultSelection event. We want to give the user the additional option to open this dialog in a new browser tab. This tab may run the same EntryPoint, or in this case one designed for this specific purpose only.

We create a TableViewer with markup support:

viewer = new TableViewer( parent );
viewer.getTable().setData( RWT.MARKUP_ENABLED, Boolean.TRUE );

Then we insert a link in the last cell of each row, whereby “edit” is the name of another EntryPoint:

viewer.setLabelProvider( new CellLabelProvider() {
  @Override
  public void update( ViewerCell cell ) {
    Person person = ( Person )cell.getElement();
    switch( cell.getColumnIndex() ) {
      case COLUMN_FIRST_NAME:
        cell.setText( person.name );
      break;
      case COLUMN_PLACE_OF_BIRTH:
        cell.setText( person.nation );
      break;
      case COLUMN_LINKS:
        String url = "edit#person/" + persons.indexOf( person );
        cell.setText(  
          "<a href=\"" 
          + url 
          + "\" target=\"_blank\">edit</a>" 
        );
      break;
    }
  }
} );

In the other EntryPoint, we add deep-link support like this:

BrowserNavigation bn 
  = RWT.getClient().getService( BrowserNavigation.class );
bn.addBrowserNavigationListener( new BrowserNavigationListener() {
  @Override
  public void navigated( BrowserNavigationEvent event ) {
    String state = event.getState();
    if( state.startsWith( "person/" ) ) {
      int index = Integer.parseInt( state.substring( 7 ) );
      editPerson( persons.get( index ) );
    }
  }
} );

Done. You could also use the URLLauncher service to open the tab without using a “real” link.

The Vision

My idea was to create a highly modular and especially flexible client that supports only a minimal subset of RAP features, but can very easily be extended and customized. RAP 2.0 introduced a simple JavaScript API for creating custom widgets. This client would go one step further and also allow you to change the presentation of existing widgets to your liking (also using JavaScript). For that you don’t have to implement a new Java API, the client-server communication is already in place, as is the internal logic of the widget (like selection management). Also, the widget will still be single-sourcing capable. Any RAP widgets or features that you might miss in the client you should easily be able to implement yourself after reading the documentation. It would basically be a D.I.Y. RAP Client construction kit, and not a replacement for the full-blown existing WebClient.

Another noticeable feature of this client would also be its ability to adapt to (and take advantage of) different environments. This would also mean that it breaks with RAPs paradigm of looking and working identically on all supported browsers. If you want to take advantage of exciting HTML5/CSS3 features you can but it won’t work/look like the same older browser. You could also create a very different presentation if you are on a touchscreen device, or if you want to optimize for performance on older hardware. You could even create a presentation built entirely on SVG, or for other environments than a browser, as long as they run JavaScript.

By the way, most custom widgets and ClientScripting components written for the default WebClient should also still work with this client.

So I went ahead and built a proof-of-concept/experimental version of this web client for RAP. It currently supports 5 widgets and is appropriately titled “RAP Lite”. The code can be viewed here. You can also download it and run the demo but remember that this is strictly a research project and only barely functional.

What can it currently do?

First of all, here are two screenshots of the Demo application included:

The screenshot on the left is the default WebClient, while the one on the right is RAP Lite. The first 5 buttons all only change the Label at the top.
So far it looks and works mainly in the same way, except that RAP Lite starts up faster.

“Visit the other side” brings a List widget to the front using a nice CSS3 animation in the latest FireFox and Chrome browsers:

Clicking on “Scroll” will animate the scroll position of the List to a random value. In a modern browser the scrollbar is a subwidget (iScroll) that looks the same on any OS. Let’s compare that with IE8:

In IE (on the right), the List now uses the traditional OS-native scrollbar without animation because the iScroll widget is not supported in IE. Also, the gradients are gone because RAP Lite will not go to the same lengths as the default client to render them. Lets modify the demo to tell the client to use another presentation for buttons:

Now RAP Lite uses the native HTML form elements for push buttons, which aren’t as flexible, but look somewhat better than flat rectangles.

Finally, lets have a look at a cool feature that I didn’t mention before at all: The ability to run RAP Lite inside of a traditional, static HTML website:

This is not RAP running in an iframe. Instead, there is a simple script within that static HTML site that assigns the RAP application a div to run in. However, that’s not all. Let’s assume you want to embedd RAP in your website, with some static content between the RAP components. You can do that too. The button at the bottom of the demo opens another Shell which now looks like this:

Notice that the text flows around the new Shell, and even adapts when it changes it size.

How does it work?

RAP Lite can be separated into three layers (+libaries):

The first layer provides the core infrastructure for communicating with a RAP server. The code is taken directly from the existing WebClient and could be used to build any kind of JavaScript-based RAP client on top. (This is not quite the case yet, but almost).

The second layer provides the widget data models and internal logic, and connects the models with the first layer. It does not, however, include any HTML/CSS rendering or DOM event handling. As such it should, like the first layer, be able to run in any JavaScript environment, even non-browser.

The third and final layer does the actual presentation. Each widget model is assigned one or more (alternative) views that can render their content. The views use HTML templates and/or subwidgets (standalone widgets not based on a model) to generate the widget representation. DOM Events are pre-processed by the view, then forwarded to the model. The theming is applied using central CSS rules generated at runtime, and every view can contribute it’s own rules. Most changes in the model are either reflected by adding/removing CSS classes, or by re-rendering all or most of the HTML. While more incremental changes may be more efficient in some cases, this approach keeps the code very simple and the number of DOM operations small.

What does it all mean?

There are currently no concrete plans for a more “official” version of this client. The fact that is’s based on underscore.js sadly means that it can not become part of the RAP project for legal reasons. However, if I’m ever involved in creating another web client for RAP, it will most likely look a lot like this experiment.

If you are writing unit tests for your Java code, then you should also write them for any other code you wrote for the same project. Otherwise these tests only give you a false sense of security. RAP 2.0 provides a new JavaScript API to extend the framework with custom components, as you can read here. Using third party JavaScript libaries (jQuery, D3, etc) or widgets/applications (like GMaps, CKEditor… ) makes the task manageable even if you are not an HTML/CSS/JavaScript expert. But what about tests?

As Java/RCP/RAP developer you may be used to JUnit, and perhaps Mockito (if not: read this). Now, Java/JavaScript differences aside, I like Jasmine even better. I used it to test my JavaScript code when porting the CKEditor add-on for RAP (demo, download) to RAP 2.0. In this article I will use this project to demonstrate one way to use Jasmine with RAP.
You can look at the editors Java implementation here, and at the JavaScript code we want to test here.

Remote API Basics

To fully understand the examples i’ll show here, you should be familiar with the RAP Remote API, but you’ll get the gist of it either way. If you want, you can jump straight to the next chapter.

A brief introduction to Remote API is also given here. Basically, each side (client and server) have one “half” of the custom widget, and a representation of the other side’s “half” as an instance of RemoteObject:

Therefore RAP includes a RemoteObject implementation for Java and one for JavaScript. The main difference is that the server can create new remote objects…

Connection connection = RWT.getUISession().getConnection();
RemoteObject remoteObject 
  = connection.createRemoteObject( "MyWidget" );

… while the client can only get existing ones:

  var remoteObject = rap.getRemoteObject( widgetInstance );

In addition, the Server can also receive remote operations via the remote object, while the client object has to implement methods (especially setter) that can be directly called by the framework.

Typically, a simple custom widgets client-side life cycle looks like this:

• The client component has to register a TypeHandler (once). This is basically the glue between your custom widget and the framework. The type handler consist of a factory for the client object, and a list of properties, methods and events it supports.
• The server side creates an RemoteObject instance. With this, a “create” operation is send to the client and invokes the type handler’s factory.
• Using the id of a Composite (which the server typically provides in a “set” operation), the custom widget can obtain the client side instance and attach itself to it: rap.getObject( parentId ).append( htmlElement );
• All invocations of “set” or “call” on the server side RemoteObject will cause the matching methods of the client widget to be called. To send messags back, the client widget can itself obtain a RemoteObject to send operations to the server.
• When the server remote object is destroyed, so is the client object.

Jasmine at a glance

The Jasmine project site already gives a good tutorial, so I’ll try to keep this short. Jasmine allows for Behavior-Driven Development (BDD), which is similar to Test-Driven Development (TDD). It basically means that your tests will read like a “story” written in plain English. (Or any other language, if you’re crazy.)

For example, a traditional test in JUnit…

public class Math_Test extends TestCase
  public void test_RoundsUp2Point5() {
    assertEquals( 3, Math.round( 2.5 ) );
  }
};

… may look like this in Jasmine:

describe("Math", function() {
  it("should round 2.5 to 3", function() {
    expect( Math.round( 2.5 ).toBe( 3 );
  });
});

As you can see it’s not that different at first, except it’s easier to describe what exactly you are testing. The “describe” function seems similar to a test class (it is called a “Suite”), “it” to a test method (actually a “Spec”), and “expect” looks a bit like Mockitos “verify”. The “setUp” and “tearDown” methods in JUnit would be “beforeEach” and “afterEach” functions in Jasmine.

However, the advantage is that unlike JUnit tests, “describe” functions can be nested. And what I personally love about that, is that each can have it’s very own beforeEach/afterEach functions, and they are executed for all the “describe” functions the “it” is in. That made my tests a lot more readable. In JUnit I would often have a lot of similar setup code at the beginning for each test, and multiple asserts the end. Sure, there ways to reduce it, but I think it’s a pain. My Jasmine Specs on the other hand are usually around three lines only.

What to test?

There may be several parts to your JavaScript component. The RAP type handler has little to no logic of it’s own, and would require a “real” RAP client to be tested. Therefore we omit it, and only test the widget “class” itself.

If your custom widget is basically a wrapper for an existing JavaScript app (like CKEditor), then you might want to test only the wrapper. If so, you can also replace the app with your own mock, though you have to know the app’s API really well for that to work. In my case, I first did a untested prototype to figure out how to get the CKEditor to cooperate with RAP. Then I started again from scratch, writing tests first using a CKEditor mock I created myself.

If you are writing the entire widget yourself, you should of course test all of it, not just the part that connects to RAP.

Setting Up Jasmine with a RAP enviroment

Download the Jasmine Standalone Release and unzip it to a folder in your test project. You don’t need the included examples, so delete the src and specs folder. Open the SpecRunner.html in an editor. We are interested in the <script> tags only. Remove those that point to the deleted files. Then get the “rap-mock.js from our GitHub repository and include it with a new script tag. This is key, as the file contains a mock implementation of the RAP JavaScript API, so that your custom component can be tested outside an actual RAP application.

Below the rap-mock.js, add the JavaScript file(s) from your own RAP JavaScript component. If they are in another bundle, it may have to look like this:

<script 
  type="text/javascript" 
  src="../../com.eclipsesource.widgets.ckeditor/src/resources/handler.js">
</script>

Finally, create a new JavaScript file like “CKEditorSpec.js” and also include it in the HTML file. This is where we will put the tests.

The rap mock is initialized automatically by including the file itself, but to be sure that everything is reset with each test, your outmost “beforeEach” should look like this:

 beforeEach( function() {
  rap = new RapMock();
} );

In addition to the official API of the “rap” object, this one has two fields “fakeRemoteObject” and “fakeComposite”. Like “rap” itself, they are only empty implementations of the RemoteObject and Composite types, which are returned if rap.getRemoteObject() or rap.getObject() (respectively) are called. That makes it a lot easier to test interactions with these objects later on. (Note that it always returns the same instances, but since they dont have any state it shouldn’t matter.)

My First Spec

Since variables have function scope in JavaScript, and all Suites and Specs are functions, you can freely define variables within any suite and share them with the contained Specs. I would suggest to do so for your outmost Suite for the instance of your custom widget. For me, it looks like this:

describe( "eclipsesource.CKEditor", function() {
 
  var editor;
 
  var createEditor = function() {
    editor = new eclipsesource.CKEditor( { "parent" : "w2" } );
  };
 
  beforeEach( function() {
    rap = new RapMock();
    editor = null;
  } );
 
  afterEach( function() {
    editor = null;
  } );
 
  ...
 
} );

I’m not creating an instance in the outer Suite because we will sometimes need to do some setup before calling the constructor. This is where spies come into play. Remember, our rap mock (and in this case CKEditor mock) does absolutely nothing itself (except preventing crashes). To write meaningful tests, we need to spy on it.

Spies replace methods with stubs, which can later be checked for invocations Mockito-style. They can also return any value, capture arguments, or execute arbitrary code. Read more about them here. Spies are automatically removed after each it.

Now we dive right into it, and test that the widget adds itself (specifically it’s element) to the parent:

  describe( "The Constructor", function() {
 
    it( "should get a Composite with the parent id", function() {
      spyOn( rap, "getObject" ).andCallThrough();
      createEditor();
      expect( rap.getObject ).toHaveBeenCalledWith( "w2" );
    } );
 
    it( "should add an element to the composite", function() {
      spyOn( rap.fakeComposite, "append" );
      createEditor();
      expect( rap.fakeComposite.append )
       .toHaveBeenCalledWith( editor.element );
    } );
 
  } );

It is a common pattern to prefix “private” fields of JavaScript objects with a “_”. For the CKEditor wrapper I completely abstained from creating private fields and made everything “public”, including the HTML element. If I hadn’t, I would either have to access a private field, or examine the contents of the element that was given to the fake composite. Since i’m not interested in testing the CKEditor itself, I chose this simpler solution.

Most other aspects of the constructor and the editor/wrapper are tested in similar ways, as you can read in the full Spec file. However, there are a few more special cases I like to discuss in detail.

Testing events

The CKEditor wrapper registers events listener on the CKEditor itself and on the “rap” object, e.g. to check for changes before a request is send to the server. There are various ways to test them. The “cleanest” one would likely be to obtain the listener with a spy and execute it:

describe( "The send listener", function() {
 
  var onSendListener;
 
  beforeEach( function() {
    spyOn( rap, "on" ).andCallFake( function( event, listener ) {
      if( event === "send" ) {
        onSendListener = listener;
      }
    } );
    createEditor();
  } );
 
  describe( "of an editor that has not changed", function() {
 
    it( "sends nothing", function() {
      spyOn( rap.fakeRemoteObject, "set" );
      onSendListener();
      expect( rap.fakeRemoteObject.set ).not.toHaveBeenCalled();
    } );
 
  } );

With the “beforeEach” function this does not bloat your code all that much, but it’s still a couple of lines. So instead I simply made the listener “public” (like with the HTML element) and called it after checking it was registered. This is part of the “contructor” Suite show above:

it( "should add a send listener", function() {
  spyOn( rap, "on" );
  createEditor();
  expect( rap.on ).toHaveBeenCalledWith( "send", editor.onSend );
} );

Now I can simply invoke editor.onSend whenever I want, since I now it has been registered with the RAP client, which I trust to work correctly. But, there is one important bit: You should not simply write editor.onSend(), because this would mean that editor will be the context (this) of the invokation. This is not automatically given when working with JavaScript callbacks, and I know it is not the case with rap.on. (To see how I solved that issue for the CKEditor, look at the bindAll function in the source code.) Instead, you can write editor.onSend.call();, which executes it without context.

The Clock makes “tick”

A common issue with JavaScript testing are asynchronously executed function. This custom widget has one of those for setting the editors font, which happens with a small delay using the JavaScript setTimeout function. This means I can not simply call editor.setFont and check the results right away. Jasmine includes two different solutions for this issue. If you want or need your test to emulate the actual runtime scenario, you need to wrap the code of your Spec in runs and waitsFor functions.

Since I use only a mock CKEditor I had no such requirement, and used the alternative: Simply mocking the JavaScript timer.

describe( "The setFont function", function() {
 
   var body;
 
   beforeEach( function() {
    jasmine.Clock.useMock();
    createEditor();
    body = editor.editor.document.getBody();
    spyOn( body, "setStyle" );
    editor.setFont( "13px Arial" );
  } );
 
  it( "calls body.setStyle on a ready event", function() {
    editor.onReady.call();
    jasmine.Clock.tick( 0 );
    expect( body.setStyle ).toHaveBeenCalledWith( "font", "13px Arial" );
  } );
 
} );

Feedback…

…would be welcome, especially if you have trouble writing tests for RAP custom widgets. I did not touch on some topics like sending events to the server (which the CKEditor doesn’t do), or how to test DOM changes, but that would have completely burst the scope of this article. (I sometimes have issus keeping things short…) Also, on testing the server side: RAP includes a Fixture (not official API) which allows testing the Remote API, but we might change it soon, so I didn’t want to write about it now. If you are curious, look at CKEditor_Test.java.

Final Words

Jasmine is awesome. Go use it for something.

What are Mnemonics?

Should you not know, Mnemonics are the characters that get underlined in some widgets (especially the menu bar) if you hold down the ALT key. Mac users may scratch their heads right now, because those aren’t supported in OS X. Their exact behavior differs a bit between the other platforms, but as long as you hold ALT and press of the underlined character on your keyboard, the widget gets selected. What I like about that is that, unlike normal shortcuts, you do not need to remember Mnemonics, and they can change all the time depending on what’s on screen.

Mnemonics in RAP 2.1M1

As of M2 (or the current nightly build), RAP will support Mnemonics on Menus, Buttons, ToolItems, TabItems, Labels and Groups. (Also CTabItem and CLabel.) To enable them, you first need to set the modifier that makes the Mnemonics visible. While you could use ALT, it’s strongly discouraged, because that would activate the actual Mnemonics of your browser with unpredictable results. I recommend using CTRL+ALT, and reserve CTRL and CTRL+SHIFT for global shortcuts/Key Bindings. The combo can be set with just one line:

display.setData( RWT.MNEMONIC_ACTIVATOR, "CTRL+ALT" );

Now all you need to do is to put a “&” before a character in a widgets text, and you already have a working Mnemonic. Example:

tabItem.setText( "Tab Item &1" );

Since this is a relatively complex new feature, I would love for developers to grab RAP 2.1M1 when it’s available next week and try it in their application so that we can get some feedback.

Coming soon: Full Accelerator support.

When you look at our New and Noteworthy log for RAP 2.0 RC1, you’ll notice that we are going to live up our new name: The brand new RAP “Remote” API on Server and Client makes custom widget development much simpler than it ever was. This is also the first time we publish official JavaScript API, making JavaScript components much more future-poof.

This build also introduces simplified EntryPoints, which can safe you a nice bit of typing when starting new RWT applications or snippets:

public class HelloEntryPoint extends AbstractEntryPoint {
 
  @Override
  protected void createContents( Composite parent ) {
    Button button = new Button( parent, SWT.PUSH );
    button.setText( "Hello World!" );
  }
}

We encourage everyone to download and install RC1, and report any issues you may find to the RAP Newsgroup or Bugzilla. RAP 2.0 will be released on February 11.

The client service API accounts for that. In RAP 2.0, the client is represented by a class implementing the Client interface (WebClient by default). An instance of this class can be obtained from RWT.getClient(), which selects an implementation that matches the currently connected client. This implementation then provides the client services via the getService method. For example:

MyService service = RWT.getClient().getService( MyService.class );

If the client connected to the current session supports the service, an instance is returned, otherwise null. (Also, within one session it will always return the same instance for the same service.) If you can be certain that the service is supported by all clients you are targeting, you can use it immediately, otherwise you should check for null first.

Right now, all services that are part of RAP are supported by the WebClient at all times. Some of them provide features that already existed in RAP 1.x in some form, some of them are completely new. There will certainly be even more in the future, especially ones that are based on HTML5-only features. As such, their availability at runtime may depend on the currently connected browser.

For now there is:

• ClientInfo: Provides you with the clients timezone offset and locale setting.
• BrowserNavigation: Allows you to support the browser’s back/forward button and deep linking.
• ExitConfirmation: Lets you set a message that is displayed if the users tries to close the window or navigate to another website.
• UrlLauncher: Open any given URL without leaving the application or influencing the client. May be used to open other websites, view files, start mailing or calling a specific person. May also support opening save dialogs in the future.
• JavaScriptLoader: This new feature allows the server to add JavaScript to an already running client. The service also keeps track of which files have already been loaded. This makes it easy to develop custom widgets/components that are loaded as they are needed, keeping the initial loading time for the user as short as possible. (Fittingly, we also introduce a new custom component API in 2.0).
• JavaScriptExecuter: This service allows you access the client directly. If there is a simple, client-related task that RAP does not provide any Java API for (yet), this may be a way around that. Of course one should be very careful with this feature. Using it incorrectly may disrupt or even crash the entire client. Just make sure your script can not throw any exceptions and does not mess with any clients internals.

Update: You can try all services in the updated Controls Demo.

I did all my testing with the upcoming RAP 2.0M3 on a 64Bit Intel version of Windows 8. I currently have no WinRT tablet available for testing.

IE 10, Desktop mode

RAP basically runs like it would on IE9. That means that it takes advantage of modern features like HTML5, but not to the same degree as on Firefox and Chrome/Safari. One shortcoming of IE9 was its limited support of CSS3, which is why RAP used some SVG in the UI to compensate for that. Since IE10 is currently running as IE9, this is still the case.

After 5 minutes of hacking I got RAP to only use CSS3 in IE10. While it generally works, there seems to be an issue with gradients having an incorrect orientation. If it turns out to be an easy fix, we might be able to render the UI with CSS3 only in RAP 2.x/IE10.

IE 10, App mode

For IE to run in app mode, it has to be set as the default browser. It took me a while to figure that out. It’s like IE is offended that I dared to install another browser.

The UI seems to work like in desktop mode, but we are here to look at the controls. Using the mouse already causes some issue: Usually a right-click is used to bring up the URL-bar, which is hidden by default. However, that does not work while running a RAP application. It should not be hard to fix, assuming there is a way to detect IEs app-mode with JavaScript. Using fingers (swipe from bottom) or keyboard (CTRL+L) works fine though.

Running fullscreen, the RAP theming fits quite well with the metro design.

Using fingers to press buttons and menus, or select items also works flawlessly, as does editing text. Double-tapping zooms into the application, a feature which we usually suppress on iOS and Android to allow quick selections and double-clicks. Touch-scrolling does not work at all except on multi-line textfields. Dragging any other items (like scrollbar thumbs) is also not possible.

RAP already supports all of this on iOS and Android (within limitations), but that code was written specifically for webkit browser and does not seem to work on IE10. We will likely have to put some effort into getting IE10 to the same level. Amusingly, the IE10-gesture of swiping left/right to navigate back/forward works very well with the more advanced BrowserHistory feature of RAP, as can be tested with the Examples Demo.

Google Chrome 23

Even though RAP does not detect Chrome on Windows as a touch-enabled browser, touch-controls work pretty good. Even scrolling trees and tables works, which was a huge issue on Android and iOS. Double-tapping does not zoom, but correctly fires a double-click event.
Fixing the touch-detecting in RAP improves the touch-scrolling a bit, but changes nothing else.

Firefox 17 beta

Firefox is also not detected as a touch-device. Emulating simple clicks works fine, but that’s about it. Clicking in textfields does not bring up the keyboard. Touch-scrolling works, but is very much broken. However, since this version of Firefox is not yet a “real” Windows 8 app, let’s hope for an improved version soon.

Conclusion

Overall RAP is usable with touchscreens on Windows 8, though not quite yet at the same level as in iOS. However, support is noticeably better than it initially was with the first iOS/Android devices, so it should be not quite as hard for RAP to get there.

Here are some simple ways to automate how you deal with whitespaces in Eclipse.

First, if you don’t want to have trailing spaces in your java code (why would you), you can remove them automatically:

If you use JSDT, there also is an option available to turn this feature on for javascript.

Second, if you want to be sure not to miss any unwanted whitespaces, you can configure Eclipse to show them as characters. Since doing this for all whitespaces can make the code harder to read, you can choose to show only those you don’t want to have in your code:

This setting affects all text files, including java, javascript and HTML. Sadly, there is no option yet that shows only two or more enclosed spaces.

If you are a Javascript developer, this internationalization tool fixes all these problems.

Instead of writing…

function foo( arr ) {
  for( var i = 0; i < arr.length; i++ ) {
    if( arr[ i ] === undefined ) {
      arr[ i ] = null;
    }
  }
  return arr;
}

…you could write…

funktion foo( arr ) {
  für( var i = 0; i < arr.length; i++ ) {
    wenn( arr[ i ] === undefiniert ) {
      arr[ i ] = null;
    }
  }
  rücksprung arr;
}

… or …

функция foo( arr ) {
  для( пер i = 0; i < arr.length; i++ ) {
    если( arr[ i ] === неопредел ) {
      arr[ i ] = нуль;
    }
  }
  возврат arr;
}

… and the code will still work.

Seriously though, I’m not 100% sure if this is supposed to be a joke or not. I’ve seen developers naming variables in their code in their native language. I even did it myself – when I was 12.

I’m not sure if it’s because of a lack of language skills or some sense of linguistic purity/anglophobia, but it’s really cringe-worthy. Not only will almost no one outside your country be able to understand it, but the constant switching between English keywords and another language is just confusing and hard to read. (Though I guess this tool would solve that particular problem…)

In this article I will describe four basic approaches to debugging JavaScript on Android (stock browser and Google Chrome) and iOS (Safari), and consider the pros and cons respectively. While you can read about some of these tools here and there, I've got the impression that some authors only tried them shortly to see if it works at all. I really used most of these at some point to get actual work done.

I will occasionally use an example script that contains the following function:

function foo( myObject, myNumber ) {
  var bar = 10 / myNumber;
  var result = myObject.calcSomething( bar );
  document.getElementById( "result" ).innerHTML = "The result is " + result;
}

Contents:

1. Native Tools
2. JavaScript and Bookmarklets
3. HTTP Remote-Debugging
4. USB Remote-Debugging
5. Conclusion

1. Native Tools

This is what you can do with only your phone or tablet. (Without injecting additional JavaScript into your application.) It isn't much.

iOS

For iOS you can enable the debug console. Go to Settings -> Safari -> Advanced, set "Debug Console" to "on". This makes a bar appear at the top of the browser. Tapping that bar shows the console. Here all uncaught exceptions are logged, much like they would on MacOS/Windows Safari for example. The buttons at the bottom allow you to filter the messages, but you can not type anything, or interact in any other way.

This would not really explain why our script does not print anything.

You can also use console.log() in your script to print out messages:

Now we can tell that it's myObject that is null, but only since we already suspected it and put the log there.
It also does not tell us why. For that a stacktrace, or better yet, a step-by-step debugger would be helpful.

The functions debug(), info(), warn() and error() do the same, just with different icons. There are also a bunch of other functions on the console object, but they all don't seem to do anything. Even console.trace(), which can be really useful sometimes, doesn't work at all.

I also found an JS console app, but it's more suitable for experimenting with JavaScript, not for debugging.

Android

The Android Browser doesn't have a console, or any other tools working out of the box. However, I found some apps in Googles Play store that could help.

JS Log is basically a replacement for the js iOS console. It logs messages and uncaught exceptions in the Android notification area. Too bad that it worked very unreliably.  On my Android 3 tablet it sometimes didn't log even when explicitly calling console.log(). On my Android 4 phone it didn't work at all. (So no Google Chrome support either.) Not recommended.

The HTML DOM Viewer is a minimalstic browser (presumably using the default Android browser internally) that also features a console (for logging only), and allows you to inspect the current HTML/DOM state. Unlike JS Log it's pretty reliable, but it's not very convenient to use. I wasn't able to scroll or clear the console, which is already a deal-breaker. The HTML view has no syntax highlighting at all, and longer tags do not wrap, nor can you scroll horizontally. Oh, and it has ads:

Sadly, no real recommandation for this tool either.

2. JavaScript and Bookmarklets

Debug-tools can also be implemented with JavaScript itself, and they can be surprisingly powerful. Of coure, running in the same enviorement as the application that they are supposed to be debugging bears a slight risk of interference.

D.I.Y.-Console for Android

The minimal requirement for me is to have a (reliable) way to log errors and messages. So I wrote this little script for Android browsers:

if( ( /android/gi ).test( navigator.appVersion ) ) {
  console = {
    "_log" : [],
    "log" : function() {
      var arr = [];
      for ( var i = 0; i < arguments.length; i++ ) {
        arr.push( arguments[ i ] );
      }
      this._log.push( arr.join( ", ") );
    },
    "trace" : function() {
      var stack;
      try {
        throw new Error();
      } catch( ex ) {
        stack = ex.stack;
      }
      console.log( "console.trace()\n" + stack.split( "\n" ).slice( 2 ).join( "  \n" ) );
    },
    "dir" : function( obj ) {
      console.log( "Content of " + obj );
      for ( var key in obj ) {
        var value = typeof obj[ key ] === "function" ? "function" : obj[ key ];
        console.log( " -\"" + key + "\" -> \"" + value + "\"" );
      }
    },
    "show" : function() {
      alert( this._log.join( "\n" ) );
      this._log = [];
    }
  };
 
  window.onerror = function( msg, url, line ) {
    console.log("ERROR: \"" + msg + "\" at \"" + "\", line " + line);
  }
 
  window.addEventListener( "touchstart", function( e ) {
    if( e.touches.length === 3 ) {
      console.show();
    }
  } );
}

Copy this code into your application or put it in an external .js file and load it from your application. It replaces the dummy "console" object of the Android or Chrome browser with one that actually works. You can see the console either by calling console.show() form your code, or by touching the document with three fingers at once. (So be sure to remove the code before your application goes live.) It obviously won't work on devices that don't have multi-touch.

In contrast to the other console implementations up to this point it also supports "trace" and "dir" commands.

As you can see, it uses the alert function to display the log. This keeps the code small, robust and minimally invasive. It works well enough since Android's alert-window supports scrolling. However, if you wanted to, you could easily replace it with a <div> popup and pretty-print the output, or add other features like javascript execution. Personally, I like this lightweight, simplistic approach. I did not have any problems with it yet, except that the lines tend to wrap a lot due to the small size of the popup - especially on phones. It does not (and isn't supposed to) work on iOS.

Firebug Lite

Firebug was one of the first debugging add-ons for browsers, and it's name is almost synonymous for  such tools. Firebug Lite implements a subset of the Firebug features using JavaScript. For the most part it works well on iPad and Android tablets, though it's clearly not made for touchscreens. To use it with your application, add the following line in your header:

This is the so-called debug version, because for some reason the minified version didn't work for me anywhere but the iPad. Of course this only works if you have an internet connection. Otherwise you have to download Firebug Lite and host it yourself.

Firebug will appear automatically:

Firebug Lite on the iPad. Finally a stack-trace in Safari!

You can view scripts, but not set a breakpoint. However, it is possible to use the console to execute JavaScript commands:

 You should disable the keyboards auto-uppercase feature, it will save a lot of time while typing.

Viewing HTML is possible, but a bit fiddly because the UI is not designed for touchscreens. Hitting the "+" icon can be an ordeal.

This would explain why the text isn't visible...

The DOM tab doesn't work for some reason. One possible improvement with this approach is to attach a keyboard and/or mouse to your tablet.

If your Android device has an USB port you can also attach a normal mouse.

Of course you can also just pinch-zoom in (when your application allows it), but it's less convinient and may produce minor glitches. Apparently no one has tried to make a touchscreen-friendly version of firebug or something similar. (Well, excluding my selfmade console above.)  I'm sure there are other tools like this out there, but I didn't find any really worthwhile yet.

On iPhone it didn't work at all for some reason, but Firebug is pretty much impossible to operate on phones anyway, due to the small screen.

Bookmarklets

Adding JavaScript tools to your application by editing your HTML/JS files isn't very convenient, and you risk forgetting to remove them afterwards. An alternative to this are bookmarklets. These are bookmarks that contain JavaScript that is executed in the loaded website. They can be created from any javascript with tools like this one. On desktop browser they are  usually added using drag and drop, but that doesn't work on mobile devices. One method is to add them to your desktop browser and sync them to your phone/tablet. (I haven't tried that yet.) Alternatively, you have to do this:

First you need to somehow get the code (starting with "javascript:") into the iOS/Android clipboard. Bookmarklets on websites are usually given as a link, so that won't work. Copy the code on your PC/Mac and put it into a textfile, or email, or whatever you like, and get that to your device. For our examples you can just use the code below. Select (long-press) and copy it.

Firebug Lite (debug):
javascript:(function(F,i,r,e,b,u,g,L,I,T,E){if(F.getElementById(b))return;E=F[i+'NS']&&F.documentElement.namespaceURI;E=E?F[i+'NS'](E,'script'):F[i]('script');E[r]('id',b);E[r]('src',I+g+T);E[r](b,u);(F[e]('head')[0]||F[e]('body')[0]).appendChild(E);E=new%20Image;E[r]('src',I+L);})(document,'createElement','setAttribute','getElementsByTagName','FirebugLite','4','firebug-lite-debug.js','releases/lite/debug/skin/xp/sprite.png','https://getfirebug.com/','#startOpened');

Firebug Lite (minified):
javascript:(function(F,i,r,e,b,u,g,L,I,T,E){if(F.getElementById(b))return;E=F[i+'NS']&&F.documentElement.namespaceURI;E=E?F[i+'NS'](E,'script'):F[i]('script');E[r]('id',b);E[r]('src',I+g+T);E[r](b,u);(F[e]('head')[0]||F[e]('body')[0]).appendChild(E);E=new%20Image;E[r]('src',I+L);})(document,'createElement','setAttribute','getElementsByTagName','FirebugLite','4','firebug-lite.js','releases/lite/latest/skin/xp/sprite.png','https://getfirebug.com/','#startOpened');

Android Console:
javascript:(function(){if((/android/gi).test(navigator.appVersion)){console={"_log":[],"log":function(){var%20arr=[];for(var%20i=0;i<arguments.length;i++){arr.push(arguments[i]);}this._log.push(arr.join(",%20"));},"trace":function(){var%20stack;try{throw%20new%20Error();}catch(ex){stack=ex.stack;}console.log("console.trace()\n"+stack.split("\n").slice(2).join("%20%20\n"));},"dir":function(obj){console.log("Content%20of%20"+obj);for(var%20key%20in%20obj){var%20value=typeof%20obj[key]==="function"?"function":obj[key];console.log("%20-\""+key+"\"%20->%20\""+value+"\"");}},"show":function(){alert(this._log.join("\n"));this._log=[];}};window.onerror=function(msg,url,line){console.log("ERROR:%20\""+msg+"\"%20at%20\""+"\",%20line%20"+line);}window.addEventListener("touchstart",function(e){if(e.touches.length===3){console.show();}});}})();

On the iPad, you first  have to create a bookmark in the share menu, then edit it using the "Edit" button in the bookmarks menu. Paste the code where the URL would be. For the Android browser it's a bit simpler, since you can edit the URL while creating a new bookmark. Depending on the Android version/browser, bookmarks are added by pressing some star or "+" icon, or by selecting "Save to bookmarks" from a menu.

iOS on the left, Android on the right. Obviously.

Now you just have to open the bookmark while your application is running. This works very well to open Firebug Lite on the iPad, or the DIY console on Android 3. Sadly, that's it. I had no success with Android 2 and 4 at all, and Android 3 wouldn't load Firebug half of the time, or only very slowly. Another problem is that if you need the tool while the document is loading (e.g. for logging), this solution won't work.

3. HTTP Remote-Debugging

To get around the limitations of a touchscreen-only device, remote debugging is (besides an emulator) the only way to go. In this chapter we look at tools that achieve this by injecting JavaScript into your application (debug target) that communicates with an HTTP-server (debug server), and can then be controlled by another browser (on your desktop, debug client). I will only explore the scenario of a one-to-one connection.

weinre

Probably the best known of such tools is weinre. Similar to Firebug Lite, it implements a subset of the features of the WebKit Developer Tools. It has now become part of the Apache Cordova project, but there are no official releases of that yet (August 2012).  However, you can get weinre "unofficially" here. I'm using "weinre-jar-1.6.1.zip" on a windows machine in my example.

Unzip the jar file, then type on your console (or create a script or shortcut):

It should print "weinre:HTTP server started at [...]". Then Add the following line to your HTML <head>, with [...] standing in for your IP:

You can also use a bookmarklet (you can get the code at "http://localhost:9090/"), but if you have a dynamic IP it's pretty pointless.

Then open Safari or Google Chrome on your desktop machine and go to "http://localhost:9090/client/#anonymous". There your mobile device should appear under "Targets" as soon as you load your application.

This is what it should look like. When you reload your target application,
multiple targets may be displayed temporarily.

Weinre has a similar functional range as Firebug Lite. It doesn't support as much console commands (no trace for example), but it features a network and a timeline tab. (The last one is very limited though, and doesn't seem to catch touch events.) No step-by-step debugging or profiling either, those would likely by impossible to implement in JavaScript.

The Network tab is useful if you work with XMLHttpRequests, like this Eclipse RAP application.

I had the occasional problem to get a working connection, and performance can be bad if your application is very complex. Also, hardcoding an IP address in your script is obviously not a good idea, especially if your IP may change often. Which is where we get to...

Adobe Shadow

While the name might make you think Adobe Shadow is completely different tool developed entirely by Adobe Systems, this is not the case. It has some nice little features of its own (like taking a screenshots of a website on multiple devices at once), but for our purposes it's just a convenient wrapper around weinre.

The difference is that you don't have to add any javascript to your application yourself. Instead, you download an app (here for iOS and here for Android), which will do that for you. You will also need the server component (no Linux version though) and a Google Chrome extension.

After you have all that, start the Adobe Shadow application and Google Chrome on your desktop, and the app on your device. Supposedly the app should find the server by itself, but I always had to enter the IP manually. Then you have to enter a short pin from your device on the Chrome extension, and you're connected. Your connected devices will all go to the same URL as your desktop Chrome browser, which is cool in theory, but can get really weired/annoying if you just change tabs to quickly look something up.

Now you just have to click the "<>" icon besides any of your listed devices, and a popup with weinre opens.

I have to say that Adobe Shadow isn't much of an improvement over weinre. In fact, with Shadow I had a lot more issues with not getting or even loosing a connection than with just weinre. Also, both Adobe Shadow apps (iOS+Android) have that feature where they reload the page without using cache (useful!) - triggered by a "pull-down" gesture. This can interfere with your application if you work with touch events or vertically scrolling elements. It really annoys me because it's so unnecessary. Dear Adobe, what's wrong with using a button? It's a tool, not a videogame!

I say go with weinre, unless your IP changs really often. And even then, consider that you still have to re-connect the devices (with a pin!) to your desktop machine every time. Also, Shadow does not work on linux.

Other

Socketbug and Firebug Crossfire and remote jsconsole take the same basic approach as weinre.  I didn't get around to try them, but they seem to offer  less functionality and no  significant improvement over weinre. Perhaps one of these tool will come out on top eventually, but for now I recommend weinre.

4. USB Remote-Debugging

This is very similar to HTTP Remote Debugging, but communicating with the browser application itself, not some JavaScript running inside.

Android

This is only possible with Google Chrome, not the default browser. (Chrome is available for Android 4+).

First it is required to enable USB debugging on the phone/tablet: Go to the device settings, select "Developer options" and enable "USB debugging". Then open Chrome (still on the mobile device), open the menu, go to Settings -> Developer tools -> "Enable USB Web debugging".

For the PC(/Mac) a bit of setup is requried. Download and install the Android SDK, specifically the "platform tools" and "Google USB Driver". It's available for Windows, Mac and Linux. Now connect your device to your PC via USB.  In the SDK-directory "platform-tools" you can find the executable "adb". To check that the device is properly connected, type "adb devices". It should appear in the printed list.

Now type "adb forward tcp:9222 localabstract:chrome_devtools_remote" and open "localhost:9222" on your PC's Google Chrome. You'll see a gallery representing the tabs opened on the mobile Google Chrome. Select one and you get the usual WebKit Developer Tools. Like with weinre you can use the console and DOM exploring, but now we can finally do step-by-step debugging:

No more trial and error logging, the debugger reveals everything.

Reloading the page on the device does not require a re-connect, and even breakpoints are sustained. There's no noticeable delay.

The Timeline tab works much better now, and there is even more stuff like Profiling.

Because I'm lazy I wrote a little script so I can always get the developer tools opened in a few seconds.

Windows batchfile:
@echo off adb devices adb forward tcp:9222 localabstract:chrome_devtools_remote %localappdata%\Google\Chrome\Application\chrome.exe "http://localhost:9222/" pause

If your device gets listed here, but the desktop Chrome shows something like "This webpage is not available", then USB Debugging is probably not enabled on the mobile Chrome.

iOS

For iOS there is a tool called iWebInspector, which seems to be very similar. However, it's only working with the iOS simulator, not with real devices. More importantly, it's only running properly on Mac OS 10.6 or 10.7, but no later. (Windows and Linux are out anyway.) As such, I couldn't test it and consider it useless by now.

However, it's very likely Apple does not want to stay behind Google for long, so an alternative is arriving soon. Time will tell if it's going to be a match for Google Chromes remote debugging. Support for Windows or Linux machines doesn't seem very likely though. Bad Apple!

5.Conclusion

The main issue here is that there is not one solution that fits for all cases and all browsers. The only option I can really recommend wholeheartedly is the remote USB debugging of Chrome, but that's no solution if you have a problem with another browser. If you require only logging you are probably going to be covered, but anything beyond that requires sub-optimal tools like weinre or Firebug Lite. Of those two I can't generally recommend one over the other. See which one best fits your needs.

You can also use a user agent switcher (like this one) to test your application in a normal browser. This works fine as long as you don't have a browser-specific problem, or need any devices-specific features for your testing (like touch events, rotation, etc.).

I can also generally recommend  to write unit tests and run them on your mobile devices. That already gives you a lot more security while writing more code. It  may be worth another blog post entirely.

If someone has anything to add, please let me know in the comments. I'm more than happy to update the article. I'll also try to keep it up to date regarding new releases like iOS 6 or Apache Cordova.