Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Web Development

Developing for Mobile Internet Devices: Part 2

Paul Ferrill has been writing in the computer trade press for more than 20 years. Paul holds both BSEE and MSEE degrees and has written software for more computer platforms and architectures than he can remember.

In Part 1 of this series, I showed you what it takes to build applications for the Mobile Internet Device (MID) platform. I covered the basic issues of setting up a development workstation, choosing a programming language, and making good choices in terms of external libraries. I also discussed issues like device emulation, the importance of working through a prototype "hello world" application, and common problems to avoid. [Editor's Note: For information on Moblin, see Dr. Dobb's MoblinZone.]

This installment gets down to the business at hand and walks through the process of designing and coding a working application. I chose a Twitter application that will report the user's current location as a way to exercise as many of the MID features as possible. Although it's a simple application in terms of what it does, it has many of the parts you'd need to build any general-purpose user application.

Design Choices

Many of the functional parts of this application are foundational to everyday applications, requiring features such as user authentication, configuration storage and retrieval, network communications, and user interaction. It's important to modularize the design as much as possible to both break the overall project down into manageable pieces and to make it easier to reuse the code.

The application checks each time it runs to see whether any user credential information has been entered. If not, it presents a typical user name/password login dialog box and stores the information in an encrypted local configuration file. A preferences dialog box makes it possible to change the user name and password after initial setup along with other program options.

For the initial release of this program, I assume that there is an active network connection. This is a bit of a stretch for the Compal JAX10 MID I tested on: It did not have an active 3G radio, so there was no "always-on" Internet connection. I was able to simulate having a consistent connection by using Wi-Fi, instead. Later versions might check for connectivity and, if currently disconnected, queue up the message to send the next time a connection to the Internet is available.

Another design consideration for the mobile form factor is deciding what happens when a button is pressed. With this particular application, there is a consequence for choosing single-key action; every time the user presses one of the action buttons, a message is sent to Twitter. If you assume the user won't inadvertently press a button or do something like put the device in a back pocket with the application running, it shouldn't be a problem. Alternatives might include adding a confirmation dialog box to each action ("Really send message?"), adding a button or a timer to lock the screen, or exiting the program by default after the message is sent.

Building a UI for the Small Screen

One of nice things about Python is the abundance of libraries to do just about anything you need to do. The Compal MID used for this project has a number of useful libraries installed as a part of the base operating system, and I chose to take advantage of them. The GTK+ user interface (UI) library contains a wealth of resources for building everything from a simple dialog box to a complex data-entry form. PyGTK is a wrapper around the GTK+ library and provides access to virtually every routine through standard Python objects.

Building a login dialog using PyGTK consists of creating a simple window with individual text boxes for username and password. You can find a good example and explanation of these techniques on the PyGTK tutorial page. In the following code snippet the pass_input.set_visibility(False) line causes the password to be blanked by a dot symbol:


def login(self):
        dialog = gtk.Dialog('Login', 
                            flags=gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT,
                            buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_REJECT,
                                     gtk.STOCK_OK, gtk.RESPONSE_ACCEPT))
        userbox = gtk.HBox(False)
        user_label = gtk.Label('Username:')
        user_input = gtk.Entry()
        passbox = gtk.HBox(False)
        pass_label = gtk.Label('Password:')

        pass_input = gtk.Entry()

Another chore for the small screen is creating a finger-friendly interface. For this application, that means buttons appropriately sized and spaced so that an adult's finger can easily press the button of choice. It is possible to code the button sizes specifically for the Compal screen size and resolution, but a more general approach would be to use the available system information to calculate the appropriate dimensions.

A second option with GTK+ is to create a table that fills the screen with a matrix of buttons that essentially takes up all the screen real estate. Although doing so might not be as visually appealing, it does accomplish the task of building a finger-friendly interface in which you can easily "click" the right button. It also provides a few more options for adding descriptive text to the button for the Twitter application. In Python, the matrix would look something like this:


def create_table(self):
        self.table = gtk.Table(3,4,True) # Create a 3 row by 4 column table
        button1 = gtk.Button("Button 1") # Create a button named button1
        self.table.attach(button1,0,1,0,1) # put button 1 in location 0,1
        button2 = gtk.Button("Button 2")
        button3 = gtk.Button("Button 3")
        button12 = gtk.Button("Button 12")

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.