Develop iphone apps with Ruby on Rails and Eclipse, part 3rd

Develop an advanced view of the iphone

Building views and forms

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 3rd of the "using Ruby on Rails and Eclipse to develop IPhone apps" series, which describes how to perform actions when users browse to the end of the list structure and the application actually needs to display something.

The first two parts of this series describe two important aspects of constructing a Ruby on Rails application that can serve special content for users of the Mobile Safari browser in the IPhone and ipod touch. Part 1th discusses how to set up the server to detect and provide alternative content for Mobile Safari. The mechanism chosen (not the only implementation method) involves creating pseudo MIME types, matching user agent strings and using Rails's respond_to mechanism.

The 2nd part explores the actual content that might be created for the IPhone or ipod touch. Use the IUI library as a mechanism to ensure that WEB applications follow Apple's interface appearance guidelines. The resulting application is much like a native iPhone application. This article describes how to create a downward-expanding list structure, similar to the IPhone's native mail application. Apple recommends the use of this structure because it is easy to navigate and is small in size, and can be downloaded quickly even with slower Edge network connections.

This last article in this series describes how to perform an action when a user browses to the end of the list structure and the application actually needs to display something. IUI provides some useful functionality for content and form layouts. This article also describes some features that provide special improvements to your application, such as capturing the rotation of a user's phone and adding icons that appear on the IPhone's home screen.

To run the sample, you need some tools. Of course, you need Ruby and Rails. The editor used in conjunction with Rails or the integrated development environment (IDE) is very helpful, such as Eclipse with Aptana Studio. The IPhone view screen simulator is also helpful (part 1th discusses the benefits of some options). The example used in this article is Soups OnLine, which was originally created in my Professional Ruby on Rails book for the recipe trading site. However, the specifics of the site are not important for this article. The IUI Toolkit provides a sense of the iPhone with cascading style sheets (cascading style sheets,css) and JavaScript. Created the RAILS_IUI plug-in to encapsulate the IUI functionality into rails usage for Rails assistants and other best practices.

Working with a panel to work with lists

After writing the 2nd part, I've created a browsing structure that can present a list of browsing options to IPhone users or Ipod-touch users. Some options point to a list of other recipes that are alphabetical or have recently been accessed by the organization. Clicking a menu in these listings will probably lead the user to the page that introduces the recipe.

When designing the various elements of the iphone display page, you must keep in mind the details of the iphone screen. The window settings I selected for this application will set the width of the page to the width of the device's current orientation. Since I wanted this Web application to look like a native IPhone application, I also disabled the user's ability to zoom in further. Therefore, it is important to make sure that my design is not more than 320 pixels in the vertical direction (I will briefly introduce the directed change). If you can ensure that the page does not exceed the pixel-320x480 screen, it is ideal. However, if the user has to scroll the page in one direction, that's fine.

Other aspects of the IPhone interface will mix the effects of small screen sizes. The IPhone's pixels are more dense than normal desktop screens, meaning the fonts and images displayed on the actual phone are smaller than the analog screen. You may have to enlarge the font size to see it clearly. Also, users tapping the screen with their fingers will not be as accurate as a mouse click. Apple recommends that you click on a square of at least 44 pixels for optimal availability.