Develop iphone apps with Ruby on Rails and Eclipse, part 2nd

Show iphone content to client

Using the IUI and IPhone list structure

The IPhone and ipod touch make mobile Safari a popular American mobile browser. Although it is more than enough to present a regular web page with Mobile Safari, many web developers have created an application version for the IPhone. This article is part 2nd of the "Use Ruby on Rails and Eclipse development IPhone Apps" series, which describes the common use of the Drill-down list as a navigation method.

Part 1th of this series employs an existing Ruby on Rails Web application, which is then enhanced for use by IPhone users. Part 1th focuses on the necessary client support, which allows different content to be sent to IPhone users and allows the subject to select specific content and then display the site in full screen. Sections 2nd and 3rd focus on what is actually being sent to the user and how to make the content meet the expectations of the IPhone or ipod touch user. The 2nd section concentrates on the common uses of the Drill-down list as a navigation method, and part 3rd focuses on forms, groupings, and other more advanced features.

In this article, you will use cascading style sheets (CSS) and JavaScript library IUI to handle iPhone content. The IUI library has a matching CSS class with Apple's iphone HMI Guide (human-interface guidelines), as well as handling the side sliding (sideswipe) effects that mimic the original iphone OS application interface Javascri Pt. However, we usually do not want to use IUI in the application, so I will discuss some practical CSS and JavaScript that deal with these common elements. Consistent with good Rails practices, I constructed HTML for the common IUI pattern of the Ruby helper method. These methods are bound to a rails plug-in and can be downloaded and added to any rails application.

You will continue to build based on the soups OnLine example used in part 1th. Soups OnLine is my book, an example of Professional Ruby on Rails, and a site that lists "recipes for soups." In most cases, the specifics of this site have little to do with this article. The steps needed to integrate the IPhone interface are not related to the specifics of the soups OnLine example. The most important detail is that the application (as it retains its early form of the IPhone) contains a controller recipescontroller, which handles the recipe list through the index method. In part 1th, Browserscontroller was added to manage the various selections in the Mobile Safari version of the site.

To use these examples in this article, you need a Ruby editor or IDE, such as Eclipse. A browser simulator that mimics the IPhone's display can provide a lot of help. The following simulators are available: the Aptana iphone plugin for Eclipse, the Mac Iphoney, and the official iphone Software Development Kit (SDK) simulator. The 1th part of this series discusses the installation, usage, and pros and cons of each simulator. The examples in this article use the IUI Toolbox and the RAILS_IUI plug-in.

IPhone and user Experience

The first time you touch the iPhone, the average person immediately notices that it's not quite the same as a traditional desktop browser. For example, it is very difficult to put an ordinary laptop in your pocket. These differences profoundly affect how the WEB application should be built on the Iphone, giving the user the best experience. The most important differences include:

The IPhone has a much smaller screen size (320x480) than the smallest target application for desktop WEB applications. The aspect ratio of the iPhone screen is also very different from the typical desktop or laptop monitor.

The IPhone has a much higher pixel density than a desktop monitor, making it easier to read small text or change the relative size of the image.

Users can rotate the Mobile Safari view at 90°, change the size of the image, and, more importantly, change the aspect ratio of the screen.

Mobile Safari's touch screen interface is not as accurate as the mouse interface, which means its buttons, links, and so on should be larger than desktop applications.

The Internet environment used by the iPhone is usually slow. But users eagerly expect the web to respond to their requests instantly.