Разработка приложений для iPhone с применением Ruby on Rails и Eclipse: Часть 2. Отображение контента на клиентском устройстве iPhone

Применение iUI и структуры списков iPhone

Устройства iPhone и iPod touch сделали Mobile Safari самым популярным мобильным браузером в США. Хотя Mobile Safari отлично подходит для работы с нормальными Web-страницами, многие Web-разработчики создали специальные версии приложений для iPhone. Во второй части серии статей "Разработка приложений для iPhone с применением Ruby on Rails и Eclipse" мы научимся использовать в качестве метода навигации детализируемые списки.

Ноэль Раппин, вице-президент по Rails-разработкам, Pathfinder Development

Ноэль Раппин (Noel Rappin) является вице-президентом по Rails-разработкам компании Pathfinder Development (http://www.pathf.com) и имеет десятилетний опыт в области разработки Web-приложений. Он получил докторскую степень в Технологическом институте штата Джорджия, где учился преподаванию концепции объектно-ориентированного проектирования. Автор книги «Professional Ruby on Rails» и соавтор книг «wxPython in Action» и «Jython Essentials». Подробнее см. на страницах http://www.pathf.com/blogs и http://10printhello.blogspot.com.



27.05.2009

В первой части этой серии статей мы начали процесс доработки уже существующего Web-приложения Ruby on Rails с целью обслуживания пользователей iPhone. В центре внимания настоящей статьи — необходимая поддержка со стороны сервера для передачи пользователю iPhone разнообразного контента, а также для предоставления ему возможности отказаться от этого специального формата и видеть полноразмерный сайт. Во второй и третьей частях акцент делается на передаче реального контента пользователю и адаптации этого контента к ожиданиям пользователя iPhone или iPod. Вторая часть посвящена практическому использованию в качестве метода навигации многоуровневых списков, а третья сосредоточена на формах, группировании и других более сложных темах.

В рамках этой статьи для управления контентом iPhone мы используем каскадные таблицы стилей (Cascading Style Sheets — CSS) и библиотеку JavaScript с именем iUI. Библиотека iUI содержит классы CSS, соответствующие принципам, заложенным Apple в интерфейс пользователя для iPhone, а также сценарии JavaScript для управления элементами, имитирующими интерфейс стандартных приложений для ОС iPhone. Однако использовать iUI в своих собственных приложениях не всегда удобно, поэтому я расскажу также о некоторых важных видах CSS и JavaScript, необходимых для управления этими стандартными элементами. В соответствии с традицией Rails я привожу код HTML для преобразования стандартных структур iUI в методы хелперов Ruby. Эти методы собраны в модуль Rails, который можно загрузить и добавить в любое Rails-приложение.

Мы продолжим использовать пример сайта Soups OnLine из первой части. Этот пример взят из моей книги Professional Ruby On Rails и представляет собой сайт, посвященный рецептам приготовления супов. В большинстве случаев рецепты с данного сайта не имеют никакого отношения к настоящей статье. Шаги, используемые для создания интерфейса iPhone, не связаны со спецификой примера Soups OnLine. Единственная важная деталь заключается в том, что это приложение, как оно существует в своей до-iPhone форме, содержит контроллер RecipesController, который управляет рецептами посредством своего метода index. В первой части мы добавили BrowsersController для управления переходом к версии сайта для Mobile Safari и обратно.

Чтобы воспользоваться примерами из этой статьи, вам понадобится редактор Ruby или интегрированная среда разработки (IDE), такая как Eclipse. Полезно также иметь имитатор браузера для макетирования дисплея iPhone. Это может быть модуль Aptana iPhone для Eclipse, iPhoney для Мас или имитатор из официального комплекта разработчика ПО (SDK) для iPhone. В первой части этой серии статей рассказывалось об установке, применении и достоинствах/недостатках каждого имитатора. В примерах к этой статье применяется комплект инструментов iUI и модуль rails_iui.

iPhone и взаимодействие с пользователем

При первом взгляде на iPhone не знакомый с ним наблюдатель почти сразу же замечает, что он несколько отличается от традиционного настольного браузера. Например, даже ноутбук нормального размера трудно уместить в нагрудном кармане. Эти отличия оказывают существенное влияние на то, как нужно структурировать свое Web-приложение для оптимального взаимодействия с пользователем iPhone. Вот наиболее важные из этих отличий:

  • Экран iPhone (320x480 пикселей) значительно меньше даже самого мелкого экрана, на который бывают рассчитаны настольные Web-приложения. К тому же экран iPhone существенно отличается от типичного монитора настольного ПК или ноутбука по отношению сторон.
  • Плотность пикселей iPhone значительно выше, чем у настольного монитора, что позволяет легче читать мелкий текст и приводит к некоторому изменению относительного размера изображений.
  • Пользователи могут поворачивать область изображения Mobile Safari на 90 градусов, менять размер и, что еще важнее, соотношение сторон экрана.
  • Интерфейс на основе сенсорного экрана Mobile Safari менее точен, чем интерфейс с указателем мыши, поэтому такие цели, как кнопки и ссылки, должны быть крупнее и отстоять дальше друг от друга, чем это необходимо в настольном приложении.
  • iPhone часто используется в медленной сети. Однако пользователи неизменно ожидают почти мгновенной реакции на свои действия.

Результатом всех этих различий является то, что особенности Web-разработки для iPhone не сводятся к определению, сколько информации можно уместить на экране. Даже если вам удастся втиснуть в экран iPhone все свои навигационные панели, логотипы, рекламные вставки и контент, пользователь либо будет раздражен замедлением работы сети, либо ему придется «затачивать» кончики пальцев. Поэтому целью Web-разработки для iPhone является создание четкого, простого UI, позволяющего мобильному пользователю получать доступ ко всем наиболее важным функциям. По всей вероятности, для доступа к некоторым частям вашего Web-приложения от мобильного пользователя потребуется больше шагов, но ядро этого приложения должно находиться на переднем плане и в центре.

В качестве примеров можно привести специальные версии для iPhone двух популярных Web-сайтов: Amazon и Digg. iPhone Digg использует для имитации формы и содержания сайта вариант среды iUI, которая обсуждается в этой статье, а Amazon — более специализированное представление, которое тоже очень хорошо работает в браузере Mobile Safari. На рисунке 1 приведена иллюстрация Mobile Digg. (Amazon.com по какой-то причине не отображается на имитаторе как следует.)

Рисунок 1. Digg для iPhone
Digg для iPhone

И Digg, и Amazon ограничили функциональность для мобильных пользователей самой необходимой: Digg — списком главных заметок, а Amazon — поиском. Это позволило уместить сайт на экран iPhone и предоставить мобильным пользователям немедленный доступ к его важнейшим функциям. В остальной части статьи я покажу, как уместить свой Web-сайт на экране iPhone.


Добавление iUI к приложению Rails

Существуют два основных способа наделить Web-приложение формой и содержанием для iPhone:

  • поместить на сайт свои собственные CSS и JavaScript, основанные на эталонном коде Apple или на других удачных Web-сайтах;
  • воспользоваться готовым инструментарием.

Лучший из существующих наборов инструментов — это iUI. Его преимущество заключается в том, что изображения кнопок, шрифты и эффекты JavaScript уже готовы, что позволяет сосредоточиться на содержании сайта. Недостатком служат некоторые конкретные идеи о том, как должен быть организован ваш сайт:

  • предполагается, что в определенных местах будут применяться идентификаторы Document Object Model (DOM);
  • по умолчанию взаимодействие с сервером осуществляется через Asynchronous JavaScript + XML (Ajax).

Мне кажется, что iUI лучше всего подходит для сайтов, которые легко организовать в виде списков. Надо сказать, что в рекомендациях в отношении пользовательского интерфейса iPhone Apple называет формат списка «особенно эффективным способом» организации контента iPhone, так что если это возможно, нужно рассмотреть именно списочную организацию.

iUI содержит единственный каталог с файлом JavaScript, файлом CSS и набором примеров. Так как у Rails есть специальные каталоги, в которые он обращается за файлами этих типов, дистрибутив iUI нужно интегрировать с приложением Rails:

  • файл JavaScript iui.js переместить в каталог public/javascripts приложения Rails;
  • файл CSS, iui.css переместить в каталог public/stylesheets;
  • файлы изображений(.png и .gif) переместить в каталог public/images.

Поскольку все эти перемещения запутывают относительные URL в файле CSS, все ссылки вида url(button.png) нужно изменить на url(/images/button.png). В этом случае файл CSS будет правильно помещать изображения в дистрибутив Rails.

Если кажется, что проделать все это вручную слишком трудно, можно использовать модуль rails_iui, содержащий набор задач Rake, которые загружают и устанавливают iUI, включая замену адресов URL в файле CSS. Для этого применяется команда rake iui:install. iUI содержит также компактные версии файлов CSS и JavaScript с удаленными лишними пробелами для ускоренной загрузки. Имена этих файлов: iuix.js и iuix.css. Автоматизированная задача Rake позволяет использовать компактные версии файлов.

Когда iUI установлен в проект, нужно добавить файлы JavaScript и CSS в макет. Файл макета iPhone (в данном примере это app/views/layouts/recipes.iphone.erb) должен содержать в заголовке следующие две строки:

    <%= stylesheet_link_tag 'iui' %>
    <%= javascript_include_tag 'iui' %>

При использовании модуля rails_iui это можно выразить просто как <%= include_iui_files %>.

Теперь можно приступать к созданию контента для iPhone.


Создание макета для iPhone

В оригинальной версии Soups OnLine навигация осуществлялась посредством боковой панели, а основное содержание сайта располагалось в центре. На главной странице приложения почти все те же средства навигации представлены в форме списка, и каждый выбор позволяет пользователю переходить на следующий уровень. Например, выбрав Recipes (рецепты), он переходит к другому списку, в котором содержатся недавно добавленные рецепты, с возможностью просмотра большего числа позиций. Выбор каждой из этих позиций открывает страницу с соответствующим рецептом.

Я намерен обсудить здесь этот код на трех уровнях:

  • хелпер Rails, определяемый модулем rails_iui;
  • классы стилей, определяемые модулем iUI, которые используются в генерируемом им коде HTML;
  • некоторые детали, связанные с самими CSS, в применении к проектам без использования iUI.

По умолчанию iUI подменяет реакцию на обычное нажатие на ссылке. Вместо того чтобы перерисовывать всю страницу, iUI выполняет вызов Ajax и перерисовывает только видимую область страницы. Это позволяет iUI наделять каждую ссылку эффектом sideswipe, подобным эффекту, возникающему при просмотре списка артистов или альбомов в приложении iPod для iPhone. Это можно изменить двумя способами, заменив атрибут target в теге anchor. Если целевой ссылкой является _self, используется нормальное поведение гиперссылки, когда обновляется вся страница целиком. Для ссылки типа _replace тег anchor заменяется результатом запроса к серверу.

С точки зрения Rails структура iUI означает, что основной макет обрабатывается лишь однажды. Все последующие обращения — это вызовы Ajax. Даже обычные обращения link_to должны рассматриваться как вызовы Ajax и возвращаться со значением :layout => false. Это означает также, что для простых операций Ajax вам не нужно использовать link_to_remote в своем Web-приложении для iPhone.

Итак, исходная страница пользователя этого приложения служит только для навигации. Это означает, что нужно задать маршрут по умолчанию к приложению, которое не создает собственный текст, а лишь отображает макет с основными элементами навигации. При отсутствии какого-нибудь очевидного места для размещения этого маршрута введите его в BrowsersController, созданный в первой статье, добавив в файл config/routes.rb следующую строку: map.root :controller => "browsers".

Действие этого контроллера происходит в каталоге app/controllers/browsers_controller, и работает он довольно прямолинейно (листинг 1).

Листинг 1. Действие контроллера выбора маршрута к макету по умолчанию
    layout "recipes"
    def index
      respond_to do |format|
        format.html {redirect_to recipes_url}
        format.iphone {render :text => "", :layout => true}
      end
    end

В случае iPhone он обрабатывает только макет без текста. Запросы на HTML он переадресует на страницу индекса RecipesController, которая служит главной страницей представления окна приложения.

Обработка для iPhone происходит в обработчике (renderer), который теперь вызывает пару функций хелпера, определенных модулем rails_iui, для создания страницы в соответствии с ожиданиями iUI, как показано в листинге 2. (Хелперы rails_iui автоматически доступны для всех представлений, если модуль rails_iui находится в каталоге vendor/plugin/rails_iui приложения Rails.)

Листинг 2. Тело макета основного экрана навигации для iPhone
    <body>
      <%= iui_toolbar "Soups OnLine", new_search_url %>
      <%= iui_list iphone_menu.items,
          :top => content_tag(:h1, "Soups OnLine", :class => "header"),
          :bottom => link_to ("Switch To Desktop View",
              {:controller => "browsers", :action => :desktop},
              :class => "mobile_link") %>
    </body>

Результирующий экран выглядит, как на рисунке 2.

Рисунок 2. Основной экран навигации на сайте Soups OnLine для iPhone
Основной экран навигации на сайте Soups OnLine для iPhone

Здесь используются две функции хелпера. Первая, iui_toolbar, создает серо-голубую инструментальную панель в верхней части экрана многих приложений для iPhone. Хелпер Rails выглядит как в листинге 3.

Листинг 3. Хелпер Rails для инструментальной панели iUI
    def button_link_to(name, options, html_options = nil)
      html_options[:class] = "button"
      link_to(name, options, html_options)
    end
    
    def iui_toolbar(initial_caption, search_url = nil)
      back_button = button_link_to("", "#", :id => "backButton")
      header = content_tag(:h1, initial_caption, :id => "header_text")
      search_link = if search_url 
                    then button_link_to("Search", search_url, :id => "searchButton")
                    else ""
                    end 
      content = [back_button, header, search_link].join("\n")
      content_tag(:div, content, :class => "toolbar")
    end

Этот код создает HTML, показанный в листинге 4.

Листинг 4. Код HTML инструментальной панели iUI
    <div class="toolbar">
      <a href="#" class="button" id="backButton"></a>
      <h1 dddd="header_text">Soups OnLine</h1>
      <a href="http://localhost:3000/search/new" class="button" 
          id="searchButton">Search
      </a>
    </div>

iUI определяет несколько элементов HTML. Класс toolbar определяет цвет, размеры и расположение верхней инструментальной панели. Кроме того, для отображения белого текста внутри инструментальной панели служит специальный тег h1. DOM ID backButton зарезервирован iUI и создается сценарием JavaScript iUI после нажатия на ссылку. DOM ID header_text используется следующим хелпером rails_iui. В листинге 5 приводятся некоторые подходящие CSS из iUI.

Листинг 5. CSS заголовка iUI
     body > .toolbar {
         box-sizing: border-box;
         -moz-box-sizing: border-box;
         -webkit-box-sizing: border-box;
         border-bottom: 1px solid #2d3642;
         border-top: 1px solid #6d84a2;
         padding: 10px;
         height: 45px;
         background: url(/images/toolbar.png) #6d84a2 repeat-x;
     }

     .toolbar > h1 {
         position: absolute;
         overflow: hidden;
         left: 50%;
         margin: 1px 0 0 -75px;
         height: 45px;
         font-size: 20px;
         width: 150px;
         font-weight: bold;
         text-shadow: rgba(0, 0, 0, 0.4) 0px -1px 0;
         text-align: center;
         text-overflow: ellipsis;
         white-space: nowrap;
         color: #FFFFFF;
     }

Второй хелпер rails_iui, показанный в листинге 6, генерирует актуальный список из списка позиций меню. Способ создания самих объектов позиций меню в данном контексте не имеет значения. (Детали описаны в книге Professional Ruby on Rails— см. Resources). В настоящей статье, для упрощения изложения, позиция меню представляет собой объект, содержащий надпись и атрибут URL, указывающий, куда нужно перейти при выборе данной позиции меню.

Листинг 6. Хелпер списка rails-iui
    def list_element(item)
      onclick_one = "$('header_text').innerHTML='#{item.caption}'; "
      onclick_two = "$('backButton').addEventListener('click', 
          function() {$('header_text').innerHTML='Soups OnLine'; }, false);"
      link = link_to(item.caption, item.option_hash, 
          :onclick => "#{onclick_one} " + " #{onclick_two}")
      content_tag(:li, link)
    end

    def append_options(list_content, options = {})
      list_content = options[:top] + list_content if options[:top]
      list_content += options[:bottom] if options[:bottom]
      list_content
    end

    def iui_list(items, options = {})
      list_content = items.map {|i| list_element(i)}.join("\n")
      list_content = append_options(list_content, options)
      content_tag(:ul, list_content, :selected => "true")
    end

Каждая позиция меню получает свой собственный элемент li в списке HTML. Он содержит ссылку на нужный URL, плюс некоторый сценарий JavaScript для управления надписью на инструментальной панели. Сценарий JavaScript делает две вещи. Во-первых, он меняет текст инструментальной панели в соответствии с новой ссылкой. (Так как новая ссылка – это просто вызов Ajax для редактирования тела страницы, ею можно управлять только со стороны клиента.) Во-вторых, он изменяет кнопку Back, так что эта кнопка вновь изменяет заголовок инструментальной панели на Soups OnLine. Это не полное решение проблемы синхронизации заголовка в процессе углубления в список, но как я уже писал, ни iUI, ни модуль rails_iui не поддерживают эту функцию.

Все позиции списка собираются в список HTML UL посредством пары специальных атрибутов selected=true. iUI использует их для определения того, какой список помещать в тело представления iPhone. Если на странице присутствует тег HTML, в котором selected имеет значение true, всему телу представления назначается CSS при помощи декларации CSS display: block. В сочетании с тегом определения размера тела это, по существу, отдает выбранной позиции весь экран. Это может оказаться полезным. В одном из примеров iUI на одной странице размещено несколько списков, соответствующих разному уровню углубления. Сначала отображается только один, указанный в качестве выбранного, а другие доступны через anchor и наименования-ссылки внутри одной страницы.

Однако так как выбранный список занимает все окно, заголовок с логотипом Soups OnLine и сноска со ссылкой Switch to Desktop View должны помещаться внутри тега UL. Хелпер обеспечивает возможности для включения вверху и внизу списка произвольного кода HTML — мы уже видели это во фрагменте тела макета (см. листинг 2) как :top и :bottom. Результирующий HTML выглядит как в листинге 7. Я включил в меню весь листинг первого элемента, но опустил повторение листингов других элементов.

Листинг 7. Код HTML списка iUI
    <ul selected="true">
      <h1 class="header">Soups OnLine</h1>
      <li>
        <a href="/recipes" 
          onclick="$('header_text').innerHTML='Most Recent Recipes';   
                $('backButton').addEventListener('click', 
                function() {$('header_text').innerHTML='Soups OnLine'; }, false);">
                Most Recent Recipes</a>
      </li>
      
      ### ДРУГИЕ ПОЗИЦИИ СПИСКА ОПУЩЕНЫ
      
      <a href="/browsers/desktop" 
          class="mobile_link">Switch To Desktop View</a></ul>

Выбор позиции Most Recent Recipes (свежие рецепты) приводит к смене боковиков и экрану, показанному на рисунке 3, где заголовок и кнопка Back заменены сценарием JavaScript iUI.

Рисунок 3. Углубление на один уровень
Углубление на один уровень

Чтобы создать этот экран, метод index контроллера рецептов должен поместить format.iphone {render :layout => false} в свой блок respond_to, как показано в листинге 8.

Листинг 8. Действие индекса рецептов
    def index
      @recipes = Recipe.find_for_index(params[:type])
      respond_to do |format|
        format.html # index.html.erb
        format.xml  { render :xml => @recipes }
        format.iphone {render :layout => false}
      end
    end

Обработанный файл app/views/recipes/index.iphone.erb использует тот же хелпер rails_iui. Это предполагает, что объект Recipe может надлежащим образом реагировать на методы caption и option_hash, вызванные хелпером: <%= iui_list @recipes %>.


Использование замены для удлинения списка

Выше я упоминал, что задание цели _replace в теге anchor iUI приводит к автоматической замене первоначального текста. Это помогает заставить последний элемент списка отображать что-нибудь вроде «Следующие 25 строк» и размещать новые позиции в том же списке, что и первые, облегчая пользователю прокрутку вниз по всему списку.

Чтобы функция замены работала с использованием уже созданных хелперов, внесите в метод iui_list два дополнения. Хелперу списка нужна возможность добавлять в список новые позиции. Предположим, что сейчас нужно удлинить список на одну позицию. Затем, в ответ на выбор этой позиции, нужно возвращать список позиций с тегом li, но без ограничивающего тега ul, который уже присутствует на модифицируемой странице.

Первая часть реализации этой задачи — это несколько специфичные хелперы link_to для управления специальными режимами iUI _replace и _self. Затем я добавил еще один метод для управления переключением между различными типами ссылок в зависимости от аргумента target. То и другое показано в листинге 9.

Листинг 9. Хелперы ссылок iUI
    def link_to_replace(name, options, html_options = {})
      html_options[:target] = "_replace"
      link_to(name, options, html_options)
    end

    def link_to_external(name, options, html_options = {})
      html_options[:target] = "_self"
      link_to(name, options, html_options)
    end

    def link_to_target(target, name, options, html_options = {})
      if target == :replace 
        link_to_replace(name, options, html_options)
      elsif target == :self or target == :external
        link_to_external(name, options, html_options)
      else
        link_to(name, options, html_options)
      end
    end

При наличии этих хелперов ссылок для введения новой функциональности можно добавить хелпер iui_list и сопутствующий метод append_options (листинг 10).

Листинг 10. Хелперы ссылок iUI
    def append_options(list_content, options = {})
      list_content = options[:top] + list_content if options[:top]
      list_content += list_element(options[:more], :replace) if options[:more]
      list_content += options[:bottom] if options[:bottom]
      list_content
    end

    def iui_list(items, options = {})
      list_content = items.map {|i| list_element(i)}.join("\n")
      list_content = append_options(list_content, options)
      if options[:as_replace] 
        list_content
      else
        content_tag(:ul, list_content, :selected => "true")
      end
    end

Дополнительный элемент list на самом деле добавлен вместе с двумя вариантами метода append_options. Предполагается, что этот элемент будет передаваться в опцию :more и, как и элементы списка items, состоит из надписи и URL. Последний оператор if в iui_list приводит к тому, что тег списка ul будет пропускаться, если передана опция :as_replace => true.

Вызов метода iui_list с добавленной последней ссылкой выглядит так (для помещения элемента в конец списка используется опция :more):

    <%= iui_list @recipes, 
        :more => ListModel.new(nil, "Next 25 items", more_recipes_url) %>

Ответное действие контроллера на more_recipes_url— что бы это ни было — должно вызывать iui_list со значением :as_replace => true.

iUI может проделывать со списками еще один трюк. При помощи класса CSS group создается заголовок внутри списка, подобно тому, как это делается в стандартном приложении iPod для проигрывания песен (рисунок 4).

Рисунок 4. Список с заголовками групп
Список с заголовками групп

Хелпер rails_iui для создания списка группы использует большую часть кода простого списка. Метод использует блок для динамического определения заголовков (листинг 11).

Листинг 11. Хелпер rails_iui для списка с группами
    def iui_grouped_list(items, options = {}, &group_by_block)
      groups = items.group_by(&group_by_block).sort
      group_elements = groups.map do |group, members|
        group = content_tag(:li, group, :class => "group")
        member_elements = [group] + members.map { |m| list_element(m) }
      end
      content_tag(:ul, group_elements.flatten.join("\n"), 
          :selected => "true")
    end

Метод iui_grouped_list использует метод Rails ActiveSupport group_by, который преобразует список в двухмерный список [group, [members]]. Сортировка гарантирует, что группы расположены в алфавитном порядке. (Перед использованием этого метода нужно упорядочить отдельные позиции).

Код представления для этого метода выглядит примерно так (блок возвращает первую букву названия рецепта):

    <%= iui_grouped_list(@recipes) {|r| r.title[0, 1]} %>

Где мы находимся и куда идем

До сих пор мы узнали, как обрабатывать специализированный контент для пользователей Mobile Safari. Мы научились также отображать элементы навигации по сайту с применением списков в соответствии с ожиданиями пользователей iPhone, и быстро загружать их даже через медленные сетевые соединения Edge.

Третья часть настоящей серии статей посвящена тому, что происходит, когда пользователь углубляется в список и действительно получает какой-то контент. Речь идет об отображении панелей и диалогов с использованием обычного стиля iPhone в виде прямоугольников со скругленными углами. Вы узнаете также, как реагировать на изменения, когда пользователь поворачивает свое устройство и включает/выключает обрамление (sideways) Mobile Safari.


Загрузка

ОписаниеИмяРазмер
Код примеровos-eclipse-iphoneruby2-v1c.zip116KB

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Мобильные приложения
ArticleID=391992
ArticleTitle=Разработка приложений для iPhone с применением Ruby on Rails и Eclipse: Часть 2. Отображение контента на клиентском устройстве iPhone
publish-date=05272009