• a mobile phone running Opera Mobile 9.7 or higher
• a desktop computer running Opera Desktop 9.5 or higher
• WiFi must be enabled on the mobile phone
• the IP of the desktop computer must be reachable from the mobile phone

If you can meet the requisites mentioned above, you are ready to go. On your desktop computer, launch Opera and select “Tools > Advanced > Opera Dragonfly”. This will Show the Dragonfly UI at the bottom of the Opera window. Klick on “Settings” to open up Dragonfly’s settings dialog. Scroll down until you see an entry called “Remote debugging”. Enable the setting by ticking the box and set the port number you want to use.

Note: the menu entries and the locations of the UI elements might be different on your system. The UI and the menu navigation is slightly different across versions and platforms.

Keep Opera running, it is now waiting for connection from remote debuggers on the port you specified.

Next, launch Opera Mobile on your phone and enter “opera:debug” in the URL box. Enter the IP address of your desktop computer and the port you configured Opera desktop to wait for connections on, and click “connect”.

If all went well, you should see a message below the connect button in Opera Mobile saying that it is connected to the IP and port you set.

In order to actually remotely debug a page, you have to open a new tab in Opera Mobile and direct the browser to the page. Then, in Dragonfly on the desktop, you have to click on the dragonfly logo to select the tab to debug.

Again, if all went well so far you should be able to use the full potential of Opera Dragonfly for debugging mobile HTML pages and WebApps on a real device, from your desktop computer.

Of curse, this works with Opera only, so stay tuned for further posts in which I will talk about other platforms and the options available there.

In order to quickly start testing, I looked for a way to compile and execute QT apps with OpenVG support on the desktop. (desktop means my Ubuntu 10.10 running in a parallels VM). After some time googling around I concluded that I needed to install ShivaVG first, then build QT with OpenVG support.

ShivaVG is an open source OpenVG implementation built on top of OpenGL. Installing it was as easy the usual configure/make/make install. After that it was the time to build and install QT with OpenVG support. Calling up configure did automatically find ShivaVG and recognized it as the OpenVG implementation. Unfortunately, during the actual build process, compilation stopped with different compiler and linker errors.

After some search, I could boil down the source of the errors I got to two things: missing variables for ShivaVG include directories and missing patch in QT regarding VGFont usage. Let’s see what these mean.

The first problem was that qmake was not finding the ShivaVG include and lib directories. In order to inform qmake about these settings, you need to find the right configuration file and manually add a couple of variables to it. QT stores platform specific configuration files in the mkspecs directory. I was building for an x86 linux system with a 64bit processor (remember, Ubuntu 10.10 running on virtual machine on Macbook Pro), so my configuration file is called mkspecs/linux-g++-64/qmake.conf. I added the following variables to that file before the load(qt_config) directive:

This solved the first bunch of compilation issues. However, I was still receiving strange error messages about VGFont not being found by the compiler. After another google session I learned that ShivaVG does not support VGFont. Fortunately, after yet another, much lengthier searching episode I found this patch on gitorious. What it does is to comment out the VGFont stuff from some files in the QT distribution. To my surprise, I was able to finish building QT from source with OpenVG support using ShivaVG after applying this patch.

What I experienced when actually running some QT examples and also my own demos with ShivaVG will be the subject of a future post. I’ll keep you posted

rettungsdienst.de is a leading german portal for emergency personnel. The App displays full articles from the portals news feed, also storing the articles on the device for offline reading.

Visit the iTunes AppStore page for rettungsdienst.de to purchase your copy.

Google V8 debugger protocol

V8 is Google’s open source JavaScript engine. It has support for debugging the JavaScript code running in it. From the V8 wiki:

There are two API’s for this a function based API using JavaScript objects and a message based API using a JSON based protocol. The function based API can be used by an in-process debugger agent, whereas the message based API can be used out of process as well.

Check Google V8 debugger protocol for more details.

Google Chrome Developer Tools Protocol

The main motivation behind this extended protocol was to be able to use TCP/IP sockets as a remote debugging transport. From my perspective this is where things start to get interesting. From the ChromeDevToolsProtocol wiki:

The existing V8 Debugger Protocol is not sufficient to provide Google Chrome, Chromium, or any other browser that supports the protocol, with the capability of remote debugging via TCP/IP sockets. The V8 Debugger protocol covers only JavaScript debugging operations, and only within a single V8 virtual machine (VM). In reality, there can be one or more separate V8 VMs inside a Google Chrome instance, residing in different renderer processes. Also, retrieving URLs loaded in the browser tabs, inspecting or modifying the DOM tree are not covered by JavaScript operations.

Check Google Chrome Dev Tools Protocol for more details.

But Google is not the only party seriously involved in mobile on-device debugging. Let’s see what others are doing:

Opera Scope Transfer Protocol

The fine folks at Opera have been supporting this for quite some time. All that is required is a copy of Opera Desktop 9.5 or higher (which includes the Dragonfly developer tools per default) and a device running Opera Mobile 9.7 or higher. Check Remote debugging with Opera Dragonfly for further details.

Opera’s protocol used for debugging is called Scope Transfer Protocol (STP/0) and is also open source. STP/1 is in the works and will be available soon.

Android Debug Bridge (ADB)

If you are into Android development (with Java) you probably know that adb is your friend. For the rest of you, adb is a command line tool that comes with the Android SDK and has a lot of nice functions to offer. A good overview is presented here: Android Debug Bridge.

Adb has an option to redirect the device’s debug log to the console. This log output contains the output of console.log(). So with just a bit of regex magic you can have your console.log() output on your local console.

iPhone Console Redirection

I am aware of two options for the iPhone. One is to use Joe Hewitt’s Firebug for iPhone, which contains a small web server that acts as a bridge between mobile Safari and Firebug. The other one is the Bugaboo App. This App basically displays a WebView and also has a built-in web server that you can access with your desktop browser to send JavaScript statements to it.

Summary and Outlook

All this looks very promising. But does this mean you can launch your favorite IDE, connect your device, hit “Debug” and you can start browsing the DOM, setting breakpoints and stepping through the code? The answer is: maybe. It depends on the device and the browser in question. Some browsers allow a full desktop-like debugging experience, others are limited to console redirection and yet others have to stick to the good old alert() debugger for the time being.

In follow-up articles I will get into details of how to accomplish several “levels” of remote on-device debugging on mobiles.

Web Application vs Web Page

What is the difference between a web application and a web page? The boundaries between web apps and web pages are sometimes blurry, however I believe it is safe to use the following definition:

A web application focuses on functionality, whereas the web page focuses on content presentation.

From a development perspective these are fundamentally different approaches. A [mobile] web page focuses on content presentation. Normally, the logic of the web site it is part of is implemented on the server. The web page contains JavaScript, but it is used mostly for UI effects, input validation and asynchronous data loading. Tasks are mostly form based and often split across several pages.

A [mobile] web app follows a different approach, it is designed to provide a certain functionality. It uses JavaScript to implement the main applications logic on the client side, uses a different set of UI elements, and does client/server communication only to send/retrieve raw data. The more a web app is tailored to handle one specific task optimally the better.

JavaScript Is Not Easy

As mentioned above, the use of JavaScript in traditional web pages is often reduced to small code snippets that handle input validation, dynamically manipulate the DOM in order to create nicer UI effects, or doing AJAX calls to load asynchronous data. Most of these tasks can be made even easier to the web page developer with the use of a JavaScript framework like Dojo or jQuery.

All this has led to the assumption that JavaScript is easy. After all, you can do cool stuff with just a couple of lines of code. While this might be true for web page development, it certainly is not for web app development. In order to understand why not, I will analyze a couple of concepts that are deemed to be important and state-of-the art in professional software development.

1. Object Orientation. It is a widely accepted fact that object orientation helps reusing code, applying patterns and generally making software development faster. Also, less code has to be written in comparison to non-OO languages, so it also increases productivity while it helps improving quality. JavaScript supports class-free, prototypal object orientation. This kind of OO is quite different from traditional OO like the one found in Java and C++. Traditional web developers will have a steep learning curve when learning OO from scratch. Existing developers used to traditional OO will have to learn how prototypal OO works. Getting into the details of prototypal object orientation is far beyond this article. I suggest following the link above for an introduction to the subject at wikipedia.
2. JavaScript is loosely typed. This means that you don’t have to specify the data type you are working with. The JavaScript interpreter (i.e. the browser) automatically converts between data types during the script’s execution as it sees fit. For developers used to Java/C++ this is quite a paradigm shift. For web developers, this feature will seem to reduce complexity in the beginning. However, lose typing is error-prone and forces you to learn the conversion rules by heart.
3. Special features. JavaScript has a couple of special features that might seem cumbersome to both traditional OO developers and web developers. With scoping and closures being two prominent examples. I will not get into the details of these two, instead, please check the following links to get a clearer picture:
   What You Need To Know About JavaScript Scope
   JavaScript Closures
4. Browser differences. If you have been doing web development for a while you will know what this is about. Each browser implements JavaScript with slight differences. These differences can make life very hard to JavaScript developers. Sometimes there is no way around some of these problems other than providing separate program flows for different browsers. Please visit quirksmode.org for details of browser differences.

As I hope to have proven in the points above, JavaScript is not an easy language for neither web nor native app developers. Both groups will have a steep learning curve to take before being able to develop real-world applications in JavaScript, making use of it’s features.

The UI Problem

One last thing I’d like to point out is the UI problem. Let’s get back to our definition of a web app and a web page. Web pages are designed for presentation. Web apps are designed for functionality. If you think about a web page and it’s elements, you will most probably think about concepts like navigation, links, tables and forms. If you do the same with an app, you will probably come up with buttons, panels, textfields, toolbars and menus. Can you see the difference? A UI concept for information presentation is quite different than the concept for task-oriented functionality.

Traditional developers are less affected by this problem, as the platform they develop for most probably already offers a consistent UI framework. (SWING for Java, WPF for C#, Cocoa for objective-C, to name a few). The same applies for web developers. HTML defines a set of elements that web pages can render. A lot of libraries exist for the server part of a web page to handle these elements.

There is no standard web app UI framework that works like a native, object oriented UI framework as of today. However, there are very promising projects that a web app developer can use today, two of which I’d like to point out:

qooxdoo

Sencha Touch

While qooxdoo is rather targeted at desktop web app development, Sencha Touch was made specifically for mobile devices. Both are good choices for web app development. However, they impose another hurdle in the already steep learning curve for potential web app developers. A certain familiarity with JavaScript is also required for both frameworks in order to understand the concepts and make the best possible use of them.

Conclusion

As I have shown above, web app development cannot be taken lightly. It is not safe to assume that existing web development know-how can be leveraged in a short time. Web app development has its own profile, which both web developers and native app developers do not entirely fulfill. There is a steep learning curve associated with becoming a web app developer, regardless of the developers background. However, I believe it is worth the effort. Web app development is certainly to become a key skill, especially with the adoption of HTML5 and CSS3 in more and more desktop and mobile browsers. With rich and native-like JavaScript frameworks like Sencha Touch and qooxdoo, web app development has already done a huge step in the right direction. I’m looking forward to seeing a lot of great web apps come up in the near future.

Visit the iTunes AppStore page for feuerwehrmagazin.de to purchase your copy.

The server part is slightly less complex than the iPhone part. Let’s get started. The code below shows how to take a string and encrypt it using the Mcrypt PHP package. Of course, you should use a more random kind of key as the one used here:

    $str = 'I am an encrypted piece of data';
    $secret_key   = "a16byteslongkey!";
    $iv = "0000000000000000";

    $str = mcrypt_encrypt( MCRYPT_RIJNDAEL_128,
                         $secret_key,
                         $str,
                         MCRYPT_MODE_ECB,
                         $iv);

It is important to note that I am using ECB mode in this example. If you are into security and encryption, you will know that ECB is less secure than CBC or PCBC. The reason for choosing ECB is that it does not have padding issues, so it is easier to understand and follow the code. The use of ECB is not recommended for real-world applications!

That being said, let’s get on with our example.

The iPhone Client

Setup

First of all, you will need to add Security.framework to your project. Go to Frameworks -> Add -> Existing Frameworks and select Security.framework from the list.
Next, you will need a copy of SecKeyWrapper.h and SecKeyWrapper.m. You can get those files from Apple sample code, for example here. Note that it is not absolutely required to use SecKeyWrapper. However it makes things easier by letting you focus on the task at hand instead of diving into the depths of iPhone’s security methods.
Add the SecKeyWrapper files to your project. If you added the framework correctly it should compile without warnings.

The Code

    // assume the encrypted data is in responseData, which is a NSMutableData*
    char * key = "a16byteslongkey!";
    NSData * symmetricKey = [NSData dataWithBytes:key length:16];

    CCOptions pad = kCCOptionECBMode;

    NSData *d = [[SecKeyWrapper sharedWrapper] doCipher:responseData
											   key:symmetricKey
											   context:kCCDecrypt
											   padding:&pad];
    [responseData autorelease];

    // if the data was a string, you can get the decrypted string like this
    responseString =[[NSString alloc] initWithData:d
                                          encoding:NSASCIIStringEncoding];

Final Thoughts and Considerations

Simulator Issues

Encryption does not work on the iPhone simulator. Actually, the framework is just not available for the simulator. So currently the only way of testing encryption stuff is to debug on device using USB.

AppStore Submission

When submitting an App to the iTunes Store you will be asked whether your application makes use of encryption or not. Using encryption might lengthen the review process, as you will have to declare that you are using encryption. Chances are you will have to create and upload a CCATS form and wait for Apple to review it before your app will go up for sale. Fortunately, I submitted an App that uses AES encryption and did not have to fill in any form, but then again, I am located in Germany.

Anyway, I recommend reading up on CCATS in the iTunes Connect Developer Guide.

A Word on Security

I am not a security expert. The code shown here is for educational purposes only. In a real-world implementation, you might want to use a longer key (256bit) and a better block cipher mode than ECB. Also, the approach presented here is a symmetrical one, which means both client and server need to know the key used to encrypt the data beforehand. This is by definition less secure than an asymmetric method. Asymmetric encryption is out of the scope of this article though.

Last but not least, security is always relative. AES encryption is heavy on the CPU load on both client and server. The right security approach is always dependent on what you want to encrypt, how big the data to be encrypted is and how important the data is, i.e. how many resources you can afford to use for securing it.

Download the SDK and extract the ZIP file where it best suits you. You should be presented with the following directory structure:

We are looking for what’s in the “Header” and “Source” directories. Go ahead and drag those two directories to your XCode project. Once that is done you will need to add some libraries and frameworks for the code to compile.

CFNetwork.framework

This step should be nothing new to you, just right-klick on the Frameworks group in your XCode project, and select Add >> Existing Frameworks. From the list, choose CFNetwork.framework.

xmllib

Now comes the tricky part. The SmartFox SDK relies heavily on XML and therefore on xmllib. Libs can be added to a project using the same step as above, but choosing a .dylib file from the list instead. The problem is this won’t work for SmartFox on all configurations. What you need to do is find the location of the right version of xmllib on your Mac and manually add it to the project’s build settings.

If you have been developing iPhone Apps for more than a month or two, chances are you have more than one iPhone SDK on your Mac. Assuming you have several 3.x versions, we will use 3.0 as the baseline for this article.

Let’s add the xmllib library to your project. In XCode’s main menu, go to “Project” >> “Edit Project Settings”. In the page that pops up, locate the “Other Linker Flags” entry. Add these two flags: “-ObjC” and “-lxml2“.

Next, locate the entry called “Header Search Paths“, and add the following path to it:

/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/include/libxml2/

The last step is to add the actual framework path so that XCode can actually find the library. Locate the entry called “Framework Search Paths” and add “/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/include”

Make sure youre base SDK is iPhone 3.0 aswell so that it is all compatible and nice.

Close the project settings pane and rebuild your project. It should compile without complaining.

In this article, I will describe how to build an AJAX form submission that is triggered on the iPhone’s mobile Safari browser whenever the keyboard is dismissed. I applied the technique described here in the Knausermeister App. If you are interested in the Knausermeister App, please read this article.

The iPhone keyboard in web-apps

One of the mandatory requirements for the Knausermeister app was simplicity of use. This means that the click distance from entering a product name to seeing a list of results had to be as small as possible. Let’s have a look at the default keyboard of iPhone’s Safari Mobile:
As you can see, the keyboard has both a “Done” and a “Go” button. The difference between these buttons is that the “Done” button just dismisses the keyboard dialog, whereas the “Go” button simulates pressing Enter on the current input element.

Now, the Knausermeister app consists of just one HTML page. The idea was to enter the search term into an input field and then load the results asynchronously via AJAX. No need for a second page to be the target of the form’s submit action. All this should happen as soon as the keyboard is dismissed, regardless whether the “Done” or the “Go” button is pressed.

The first part of the above requirements, starting the search when the keyboard is dismissed using the “Done” button, is easy: assuming a search() method that carries out the AJAX based search, all there is to do is to add an onBlur() method to the input element and call the search() function from it.

The second requirement though, although a no-brainer at first, turned out to be quite tricky. As stated above, one main goal of the app was to reduce the click distance between entering a product name and receiving results. The customer is supposed to enter something into the input element, then press the “Done” or “Go” button, and receive results after the keyboard has automatically dismissed itself. In other words, there is no room for a dedicated submit button.

Let’s see how this could look like in it’s simplest form:

<input maxlength="100" type="text" />

Tapping on this input element displays the keyboard shown in the screenshot on the left. Note that there is no “Go” button, just a “return” one. The reason for this is that we do not have a form element around the input element. So let’s add a form around the input element, as shown in the code snippet below:

<form>
  <input type="text" maxlength="100" value="" />
</form>

If we now reload our test page and tap into the input field again, we will see that now the “Go” button appears, as we expected. However, pressing it reloads the page. This is highly undesirable, since the whole application consists of just one page that uses AJAX to retrieve search results. For this reason, reloading the page needs to be suppressed. Remember, this is a web app and there is no web server serving the page. So the natural action here would be to add a javascript function to be called when the form’s action is carried out:

<form action="javascript:alert('search')">
  <input type="text" maxlength="100" value="" />
</form>

<form action="javascript:alert('search')">
  <input type="text" maxlength="100" value="" />
  <input type="submit" />
</form>

If you try this out you will see that it works like a charm when you tap on the submit button. The javascript is called and the keyboard is dismissed. However, tapping on the “Go” button still does not make the keyboard go away. The (cumbersome) reasoning behind this is that submitting a form should reload the page or load a completely new page. The problem is that this does not work with AJAX based applications where the form submission “just” triggers a javascript function that loads it’s data asynchronously. So why does the keyboard disappear when using a submit button and does stay on the screen when just pressing the “Go” button with a javascript target? The answer is not at all. When another element in the document gains the focus, the keyboard disappears, as the browser registers a change in focus. However, this only works for focusable elements like buttons or anchors. Non-focusable elements like paragraphs or spans do not work, as they don’t trigger a change in the focus.

The solution

So we’ve seen that we need to force a focus change after the customer has pressed the “Go” button and submit the form at the same time. Here is the solution I came up with:

First, I added an anchor with no content inside the form. This anchor will just be used to force a focus change. Leaving the contents of the anchor empty prevents the user from accidentally tapping on it. Next, I added an onKeyPress handler to the text input element that programmatically submits the form and sets the focus to the anchor. The onKeyPress only reacts to pressing the enter and return keys, which is what happens when the “Go” button is pressed.

Here is the code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <head>
  <meta name="viewport" content="width=320; user-scalable=no" />
  <meta http-equiv="Content-type" content="text/html; charset=utf-8">
  <title>Safari Mobile input test page</title>
  <script>
  function handleKeyPress(e)
  {
    var key;
    if(window.event)
      key = window.event.keyCode;
    else
      key = e.which;

    if(key == 13 || key == 10)
    {
      document.forms[0].submit()
      document.getElementById('testLink').focus();
      return false;
    }
    else
      return true;
  }
  </script>
</head>
<body>
  <form action="javascript:alert('search')">
      <input type="text"
         onKeyPress="return handleKeyPress(event)"
          maxlength="100"
                   value="" />
      <a href="#" id="testLink"></a>
    </form>
  </body>
</html>

Knausermeister provided me with an easy to use interface for querying products. The return is an XML file containing all the fields you would expect (product name, price, shipping fee, shop url, etc.)

Why phonegap?

Phonegap is an open source development tool for building mobile apps with web technologies (HTML, CSS and JavaScript). Basically it provides a native application for each platform it supports (currently iPhone, Android and BlackBerry). This native app instantiates an embedded web browser component. Your web technology app is then executed inside this embedded web browser component. The advantages of such a solution are:

However, it also has a couple of drawbacks:

• Debugging is tricky. How do you debug JavaScript code running inside an embedded web browser control in a native application on the iPhone/Android? The answer is not at all. At the time of writing this article the best way to debug phonegap apps is to use the debugger built into the latest versions of desktop safari/webkit. However, as anyone involved in mobile web development should know, webkit does not equal webkit. The mobile version of the iPhone browser behaves differently than it’s desktop counterpart. For simple applications like Knausermeister, this was not a problem though.
• Building the final native app is still done in the respective development environment. This means, if you developed a phonegap app and want to deploy it to iPhone devices, you need to use XCode. If you then want to deploy the same app to the Android Marketplace, you need to use eclipse with the Android toolchain.
• There is no phonegap UI API. If you don’t want your app to look and behave like a web page, you will have to use a third party UI library.

Why not a “normal” web app?

Conclusion

This article demonstrated how leveraging web technologies can help reducing development efforts significantly. The Knausermeister app was developed in one person/day, and the most effort went into finding the solution to the AJAX form submission/keyboard problem. Porting the app to Android and submitting to both the AppStore and the Android Market took about half a day. The iPhone version of the app was accepted by Apple 24 hours after submission.