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

Определение Mobile Safari в приложении Ruby on Rails

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

Ноэль Раппин, вице-президент по 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.



10.04.2009

За месяцы, прошедшие с момента выпуска Apple iPhone и iPod touch, Mobile Safari стал самым популярным мобильным Web-браузером в США, и его доля рынка продолжает расти. Ввиду особенностей форм-фактора и модели пользовательского интерфейса (UI) iPhone он значительно отличается от других мобильных браузеров, и многие разработчики решили оптимизировать свои Web-сайты с целью поддержки модели UI Mobile Safari.

Решение о создании специального контента для iPhone является компромиссным между двумя более радикальными вариантами выбора. С одной стороны, можно не делать ничего. Интерфейс «постучи — и увеличишь» Mobile Safari позволяет легко посещать Web-сайты, даже если они не предназначены специально для мобильных устройств. Apple выбрала этот путь, полагая, что пользователи iPhone должны иметь доступ к всемирной паутине во всей ее полноте. Другая крайность — можно воспользоваться выпущенным недавно комплектом разработчика ПО (SDK) для iPhone и сделать свое приложение стандартным iPhone-приложением. Это обеспечит безграничную гибкость пользовательского интерфейса и доступ к функциям iPhone — таким как датчик ускорений или видеокамера, — которые невозможно использовать в Web-приложении. Однако создать специальное приложение при помощи SDK труднее, чем Web-приложение, а если Web-приложение уже есть, то простейший способ предоставить пользователю привычный интерфейс iPhone — создать его специализированную версию для iPhone.

В этой статье показано, как построить приложение Ruby on Rails, которое динамически распознает браузеры для iPhone или iPod touch (в остальной части статьи я говорю об iPhone — помня, что все это применимо и к iPod touch), предоставляя пользователям Mobile Safari возможность при желании видеть весь Web-контент. В статье рассматриваются также структуры со стороны сервера, необходимые для поддержки отдельного контента для пользователей iPhone, и рассказывается о том, как приступить к обслуживанию контента iPhone. Во второй части серии «Разработка приложений для iPhone с применением Ruby on Rails и Eclipse» рассказывается о том, как придать этому контенту форму и содержание, характерные для iPhone.

Установка среды программирования

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

Возможны два варианта создания комбинации Eclipse/Aptana: ввести модули Aptana в существующую среду Eclipse или загрузить Aptana Studio, производную от Eclipse, и добавить модули в окне запуска Aptana. Если среда Eclipse уже установлена, выполните обычный поиск модулей Eclipse. Выберите Help > Software Updates > Find and Install и добавьте URL модулей, указанные в разделе Resources. Нам понадобятся два модуля Eclipse. Если вы применяете Eclipse для разработки Rails, модуль RadRails у вас, вероятно, уже есть. Понадобится также модуль разработки для iPhone, который создает макет экрана iPhone для предварительного просмотра результатов разработки в формате iPhone. Хотя этот модуль предназначен для просмотра статических страниц HTML, его можно приспособить и для приложения Rails. На рисунке 1 этот модуль показан в действии.

Рисунок 1. Модуль iPhone
Модуль iPhone

Первое, что бросается в глаза, — дисплей модуля больше, чем реальный iPhone. Это сделано для того, чтобы сохранить попиксельную совместимость — дисплей модуля имеет те же размеры в пикселях, что и дисплей iPhone, только у iPhone они расположены гораздо плотнее. При работе на Macintosh есть еще две возможности имитировать iPhone: iPhoney или официальный имитатор iPhone в составе SDK iPhone.

iPhoney — это специализированное приложение, которое подобно модулю Aptana создает макет дисплея iPhone. Разница в том, что показывает каждый из этих экранов, когда размеры сайта больше размеров iPhone. Модуль Aptana, как видно на рисунке, отображает контент в полную величину и предлагает линейки прокрутки. В iPhoney Web-страница сжимается до размера окна просмотра (как будто на странице размещен реальный дисплей iPhone). Ни одна из программ не поддерживает функции увеличения или уменьшения двойным постукиванием, так что это все же не полноценная замена тестированию на реальном устройстве.

Тот, кто подписался и загрузил SDK iPhone, может также использовать официальный имитатор iPhone, входящий в состав пакета. Он содержит корректный агент пользователя и имитирует все поведение Mobile Safari, включая увеличение двойным постукиванием. К мелким недостаткам можно отнести только то, что нужно работать под Mac OS X V10.5, и так как имитируется вся операционная система iPhone, при запуске системы нужно запускать и Mobile Safari. Еще нельзя получить листинг исходного кода HTML, как при работе с настольным браузером. Но это самый точный из всех существующих имитаторов Mobile Safari.


Обслуживание контента iPhone

Предположим, вы — счастливый владелец онлайнового источника рецептов всевозможных супов Soups OnLine. Ваш сайт отлично смотрится на экране настольного ПК, но вам хочется удовлетворить растущее число пользователей iPhone, которым в дороге может потребоваться информация о первых блюдах. Сейчас они видят то, что показано на рисунке 2.

Рисунок 2. Отображение экрана ПК на iPhone
Отображение экрана ПК на iPhone

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

Здесь стоит упомянуть, что Soups OnLine — сайт, описанный в моей книге Professional Ruby On Rails. Здесь я использую его главным образом потому, что он уже существует и с ним можно экспериментировать, не опасаясь нарушить чьи-то авторские права. В разделе Resources приведен код версии Soups OnLine, используемый для этой статьи, и шаблон, на котором базируется первоначальная версия.

Чтобы обслуживать мобильных пользователей, приложение Rails должно уметь следующее:

  • определять, когда пользователь обращается к сайту через iPhone или iPod touch;
  • позволять ему свободно переходить с мобильной версии сайта на обычную, и наоборот;
  • использовать отдельный макет для пользователей Mobile Safari, включая отдельные файлы Cascading Style Sheets (CSS) и, возможно, библиотеки JavaScript;
  • предоставлять мобильным пользователям отдельный контент.

Код, используемый для решения всех этих задач в настоящей статье, можно применять, как есть. Он также собран в модуль Rails rails_iui, который можно добавить в свой проект, чтобы получить ту же функциональность в одном пакете.


Определение пользователей Mobile Safari

Для обслуживания специального контента iPhone приложение Rails должно иметь возможность распознавать iPhone. Со стороны сервера главным средством идентификации является строка user-agent, переданная браузером на сервер. Строка user-agent iPhone выглядит примерно так (номера версий со временем меняются):

    Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML,
    like Gecko) Version/3.0 Mobile/1A543 Safari/419.3

Строка iPod touch отличается тем, что выражение в скобках начинается с iPod, а не с iPhone. Apple, не ручаясь за достоверность, рекомендует использовать номер сборки WebKit (в данном примере это AppleWebKit/420+) для определения наличия новых тегов или параметров CSS. (При тестировании клиентской, а не серверной части Apple рекомендует вообще не использовать строку user-agent, а проверять наличие специфических функций.)

Внутри Rails нужно иметь возможность задать агент пользователя iPhone в ApplicationController для последующего использования в фильтре before. Нельзя просто искать в строке "iPhone" — можно пропустить iPod touch. Похоже, что на данный момент самым надежным способом определения пользователей iPhone является поиск слов "Mobile" и "Safari":

    def is_iphone_request?
      request.user_agent =~ /(Mobile\/.+Safari)/
    end

Теперь нужно ввести iPhone в среду Rails V2.0 respond_to, так чтобы iPhone автоматически определялся как тип pseudo-MIME и можно было дополнить свои контроллеры, как показано в листинге 1.

Листинг 1. Пример метода контроллера, управляющего iPhone
    def index
      @recipes = Recipe.find_for_index(params[:format])
      respond_to do |format|
        format.html # index.html.erb
        format.xml  { render :xml => @recipes }
        format.iphone # index.iphone.erb
      end
    end

Для этого потребуется пара шагов. Во-первых, добавьте в файл config/initializers/mime_types.rb следующую строку:

    Mime::Type.register_alias "text/html", :iphone

В последних версиях Rails эта строка уже содержится в файле в виде комментария, так что достаточно просто раскомментировать ее. В старых версиях Rails, где нет каталога config/initializers, эту строку можно поместить в config/environment.rb. Это приводит к созданию специального типа MIME iphone для использования в вашем приложении. Внешне тип iphone воспринимается как text/html, но внутренне на эти два типа можно реагировать по-разному.

Добавьте в ApplicationController еще один частный метод в виде фильтра before (листинг 2).

Листинг 2. Добавление формата iPhone как фильтра before (листинг 2)
    before_filter :set_iphone_format
    
    def set_iphone_format
      if is_iphone_request?
        request.format = :iphone
      end
    end

Теперь все запросы от iPhone или iPod touch будут помечаться форматом запроса :iphone. Заметим, что пока в этом коде нет ничего специфического для используемого нами примера сайта, так что эту часть кода можно свободно добавлять к любому сайту, с которым вы работаете.

При использовании модуля rails_iui в ApplicationController или любой контроллер, который должен отвечать на запросы iPhone, достаточно вставить следующую строку:

    acts_as_iphone_controller

Как уже отмечалось, модуль Aptana не посылает приведенную выше строку user-agent. Однако соглашение об именах Rails позволяет легко обойти это. Добавление расширения iphone к любому URL (например, http://localhost:3000/recipies.iphone) автоматически устанавливает формат запроса :iphone и вызывает обслуживание контента iPhone. Это позволяет тестировать код iPhone на имитаторе Aptana. При использовании модуля rails_iui замена приведенной выше команды на acts_as_iphone_controller(true) переводит приложение в режим тестирования, когда все запросы рассматриваются как запросы iPhone, что упрощает тестирование на имитаторе или в другом браузере.


Просмотр контента iPhone при разработке

Я уже упоминал о четырех способах просмотра Web-сайта, оптимизированного для iPhone, в процессе разработки:

  • модуль iPhone Eclipse для Aptana;
  • iPhoney;
  • имитатор iPhone SKD;
  • iPhone или iPod touch.

Модуль iPhone Eclipse для Aptana

Модуль для Aptana имеет ряд преимуществ. Это кроссплатформенный инструмент, который работает везде, где работает Eclipse. Он позволяет одновременно просматривать мобильную и классическую версии сайта и хорошо интегрируется с другими инструментами разработки Eclipse. Этот модуль позволяет просматривать приложение в нескольких браузерах одновременно, что полезно, если вы ориентируетесь как на мобильных, так и на традиционных пользователей. Кроме того, при использовании на iPhone JavaScript со стороны клиента Aptana предлагает мощную консоль, которая позволяет регистрировать события подключенного iPhone и даже посылать в телефон команды JavaScript из своих приложений. Однако статья посвящена главным образом разработке со стороны сервера, и я не буду здесь углубляться в описание этих возможностей.

К недостаткам модуля Aptana можно отнести то, что он тяжеловат, если вы не используете Eclipse в качестве альтернативной среды разработки; его неудобно настраивать на запуск с определенных страниц, и он не точно имитирует поведение iPhone на сайтах, которые шире дисплея iPhone. Еще один недостаток заключается в том, что модуль Aptana не идентифицируется посредством строки user-agent, исходящей от iPhone или iPod touch. Как сказано выше, это означает необходимость дополнительных ухищрений для просмотра контента iPhone на Aptana.

Установив модуль Aptana, начните новый проект типа iPhone и присвойте ему имя. Модуль Aptana по умолчанию тестирует статическую страницу проекта index.html. В данном случае как раз это и требуется. Пусть он перейдет на страницу index вашего приложения. В окне Properties для проекта iPhone:

  • перейдите на вкладку HTML Preview и нажмите Override workspace settings;
  • на панели Preview Type нажмите Use absolute URL;
  • введите URL своего локального сервера Rails. (Проект Rails не должен работать внутри Eclipse. Он должен работать просто по тому URL, который указан в модуле.)

Когда все готово, экран должен выглядеть, как на рисунке 3.

Рисунок 3. Свойства проекта iPhone
Свойства проекта iPhone

iPhoney

Применение iPhoney — еще одна возможность просмотра контента для iPhone. Это легкая программа, которая позволяет вводить в поле адреса произвольные URL и точно сжимает широкие страницы. Недостаток iPhoney в том, что это приложение только для Macintosh. При работе с iPhoney обязательно задайте в меню iPhoney параметры для использования строки user-agent iPhone, так как по умолчанию это не включено.

Имитатор SDK iPhone

Имитатор SDK iPhone работает аналогично. Запустите программу и нажмите кнопку Safari, чтобы войти в браузер. Web-сайты можно вводить прямо в поле адреса с клавиатуры, хотя если нужно, появится экранная клавиатура iPhone. Преимущество этого имитатора заключается в том, что он поддерживает как закладки Mobile Safari, так и функциональность "поместить на домашний экран". С другой стороны, так как это не настоящий имитатор Safari, он не предоставляет простого способа показать обрабатываемый исходный код HTML, что легко делают другие имитаторы.

iPhone или iPod touch

Наконец, можно использовать реальный iPhone или iPod touch. Здесь главным препятствием становятся проблемы сетевых соединений. Если вы, как это обычно бывает, занимаетесь разработкой на сервере, который находится за маршрутизатором и имеет IP-адрес в одном из частных интервалов (10.*.*.*, 172.16-31.*.* или 192.168.*.*), iPhone будет видеть ваш сервер разработки, только если он соединен с Интернетом по локальной сети Wi-Fi, в которой находится этот сервер. (Вы также упростите себе жизнь, если будете пользоваться прямым IP-адресом.) Если такую ситуацию создать не удается (например, при отсутствии сети Wi-Fi, в которой разрешено работать вашему серверу), придется установить тестируемое приложение на общедоступный вспомогательный сервер.

Попытка просмотреть свой сайт

Выбрав способ просмотра контента для iPhone, попробуйте войти на свою страницу. В данном примере это страница http://localhost:3000/recipes. (В браузере Aptana это recipes.iphone, а при использовании модуля rails_iui — тестовый режим.) Если вы внесли в код описанные выше изменения, то увидите пустой экран. Так и должно быть. (В этом можно убедиться, просмотрев сайт на настольном браузере.) Фильтр before определил Mobile Safari, изменил формат отклика, а теперь пытается реагировать в соответствии с соглашениями Rails. В данном случае соглашение Rails состоит в том, чтобы найти в блоке respond_to слово iphone. Если оно там есть, Rails берет макет из файла layout.iphone.erb и заполняет страницу содержимым app/views/recipes/index.iphone. Так как ничего этого еще нет, Rails выдает пустую страницу. В частности, он выдает пустую страницу, потому что ему еще не сказали, что метод index контроллера рецептов должен реагировать на запросы в формате iphone.


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

Зная, что пользователи заходят на ваш сайт через устройства iPhone, можно сделать ряд точных предположений по поводу их среды. На сегодняшний день в экосистеме Mobile Safari всего два устройства с одинаковыми размерами экрана и браузерами. Видимая область изображения в верхней части страницы iPhone составляет 320 пикселей в ширину и 356 пикселей в высоту. Поле URL над страницей добавляет еще 60 пикселей, которые появляются, когда пользователь прокручивает экран вниз. Страницы Mobile Safari доходят точно до краев экрана с обеих сторон, не оставляя полей.

По умолчанию Mobile Safari предполагает, что Web-сайт имеет 980 пикселей в ширину, и сжимает его примерно на одну треть, чтобы уместить в область просмотра iPhone. Для многих сайтов это работает замечательно, но не тогда, когда сайт необычно узкий или когда вы пытаетесь подогнать его под размеры iPhone. К счастью, в Mobile Safari есть механизм, позволяющий точно задать ширину, которую нужно использовать для отображения сайта.

Для описания свойств окна просмотра Mobile Safari можно использовать специальный метатег. В листинге 3 показано, как выглядит этот тег, помещенный в новый файл макета app/views/layouts/recipes.iphone.erb.

Листинг 3. Заголовок файла с тегом окна просмотра Mobile Safari
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
      <meta http-equiv="content-type" content="text/html;charset=UTF-8" />
      <title>Recipes: <%= controller.action_name %></title>
      <meta name = "viewport" 
          content = "width = device-width, user-scalable = no">
      <%= stylesheet_link_tag 'iphone' %>
    </head>

    <body>
      <h1 id="header"><%= "Soups OnLine" %></h1>
      <%= yield %>
    </body>
    </html>

Этот метатег устанавливает два свойства окна просмотра. Первое, width = device-width, сообщает Mobile Safari, что нужно, чтобы сайт обрабатывался с использованием текущей ширины устройства. Можно также задать любое постоянное значение между 200 и 10000. Второе свойство, user-scalable = no, отключает функцию увеличения Mobile Safari, так как сайт в точности совпадает с размером экрана iPhone. В дополнение к этим свойствам можно установить еще и высоту страницы. Если вы хотите точнее управлять возможностями масштабирования для пользователя, можно задать параметры initial-scale (начальный масштаб), minimum-scale (минимальный масштаб) и maximum-scale (максимальный масштаб). Все три используют по умолчанию значение 1,0 и могут меняться в интервале от 0,0 до 10,0.

Другая специфическая для iPhone строка этого файла макета – тег таблицы стилей CSS, который определяет новый файл CSS для iPhone. Некоторые источники рекомендуют использовать для контента iPhone условные CSS. Однако мне этот синтаксис кажется непрозрачным. Так как со стороны сервера известно, с каким браузером вы работаете, в этом нет никакой необходимости — можно указать точный файл, который нужен этому браузеру.

Листинг 4 представляет собой файл CSS, который я создал для управления основным заголовком iPhone-версии сайта Soups OnLine.

Листинг 4. Файл CSS для Mobile Safari
    h1, h2, h3 {
    	font-family: "Trebuchet MS", Arial, Helvetica, sans-serif;
    	color: #000000;
    }

    h1 {
    	font-weight: bold;
    	font-size: 175%;
    	margin: 0;
    }

    body {
    	margin: 0;
    	padding: 0;
    }

    #header {
    	width: 320px;
    	height: 40px;
    	margin: 0 auto;
    	background: url(/images/img02_iphone.gif) no-repeat;
    }

Между этим файлом и соответствующими местами оригинального файла CSS имеется всего несколько различий. Значение элемента размера шрифта h1 меньше (на самом деле я нащупал нужный размер методом проб и ошибок). Тег h1 теперь имеет значение bold, а поля явно установлены нулевыми. Bold делает текст несколько более выделяющимся, а нулевые поля точно совмещают его начало с верхним левым углом экрана. Размеры идентификатора класса #header теперь совпадают с размерами экрана iPhone, и я вручную изменил фоновую картинку, чтобы она занимала все это пространство.

Нужно также создать файл app/views/recipes/index.iphone.erb, но пока его можно оставить пустым. После всех этих изменений версия сайта для iPhone начинает оформляться. Заголовок выглядит, как на рисунке 4.

Рисунок 4. Заголовок Soups OnLine
Soups OnLine header

На большинстве имитаций заметно, что поворот экрана приводит к изменению масштабов изображения в соответствии с новой шириной устройства в 480 пикселей. Ведь мы установили, что в качестве размера масштабирования должна использоваться ширина устройства.


Вход в режим мобильного браузера и выход из него

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

Механизм прост: внизу окна iPhone добавляются ссылки, которые устанавливают cookie, определяющие параметры для конкретного браузера пользователя. Затем вы позволяете заменять этими параметрами строку user-agent при определении формата выходных данных. Сначала добавим ссылку. Замените тег body в файле app/views/layouts/recipes.iphone.erb (листинг 5).

Листинг 5. Макет со ссылкой для выхода из мобильного режима
    <body>
      <h1 id="header"><%= "Soups OnLine" %></h1>
      <%= yield %>
      <br/>
      <%= link_to "Switch To Desktop View",
          {:controller => "browsers", :action => :desktop},
          :class => "mobile_link"  %>
    </body>

Для этой ссылки применяется новый класс CSS, определенный в файле CSS для iPhone (листинг 6).

Листинг 6. Код CSS для ссылки выхода из мобильного режима
    .mobile_link {
      font-size: 14px;
    	font-weight: bold;
    	font-family: Helvetica;
    	color: #00f;
    	text-decoration: none;
    	text-align: center;
      display: block;
    	width: 320px;		
    }

Для ссылок в системе iPhone выбран шрифт Helvetica. Его размер несколько меньше рекомендуемого для основного текста, но это и не должен быть основной текст. Другие элементы располагают ссылку по центру экрана. Результат выглядит, как на рисунке 5.

Рисунок 5. Ссылка для перехода в режим настольного браузера
Switch to desktop link

На следующем шаге устанавливается cookie. Как видно из определения ссылки в листинге 5, чтобы управлять этим кодом, я создал новый класс контроллера BrowsersController. В листинге 7 приведен код установки cookie.

Листинг 7. Код BrowsersController для перехода из режима в режим
    class BrowsersController < ApplicationController

      def desktop
        cookies["browser"] = "desktop"
        redirect_to recipes_path
      end

      def mobile
        cookies["browser"] = "mobile"
        redirect_to recipes_path
      end

    end

Элементарно, не правда ли? Он просто устанавливает cookie и делает переадресацию назад на страницу, используемую в качестве странице index. Затем нужно изменить метод set_iphone_format, чтобы учесть параметры браузера (листинг 8).

Листинг 8. Задание формата iPhone для выхода из режима мобильного браузера
    def set_iphone_format
      if is_iphone_request? or request.format.to_sym == :iphone
        request.format = if cookies["browser"] == "desktop" 
                         then :html 
                         else :iphone 
                         end
      end
    end

По сути, здесь внесены два изменения. В первоначальный оператор if добавлено выражение request.format.to_sym == :iphone. Это позволяет тем URL, которые представляют собой запросы iPhone через расширение .iphone, тоже изменять формат в соответствии с cookie. Это сделано главным образом для того, чтобы этот код можно было тестировать на имитаторе Aptana. Затем выбирается request.format в зависимости от наличия в cookie пользователя значения desktop, установленного методом BrowserController.

Осталось только добавить ссылку для выхода из режима настольного представления. Ее должны видеть только пользователи iPhone, поэтому начнем с добавления в ApplicationController следующей строки:

    helper_method :is_iphone_request?

Эта строка делает метод is_iphone_request? вспомогательным методом, который можно вызывать из любого представления. В частности, его можно использовать для добавления содержимого листинга 9 в конец первоначального макета экрана в файле app/views/layouts/recipes.html.erb.

Листинг 9. Условное размещение тега, если это iPhone
    <% if is_iphone_request? %>
      <%= link_to "Switch To Mobile Safari View",
          {:controller => "browsers", :action => :mobile},
          :class => "big_link"  %>
    <% end %>

Это дополнение включает аналогичную ссылку в настольный браузер, а также добавляет класс CSS в файл настольной CSS (в данном случае public/scaffold.css), как показано в листинге 10.

Листинг 10. Листинг CSS для ссылки входа в режим iPhone
    .big_link {
      font-size: 40px;
    	font-weight: bold;
    	font-family: Helvetica;
    	color: #00f;
    	text-decoration: none;
    	text-align: center;
    	display: block;
    	width: 980px;		
    }

Класс CSS добавляет крупную, броскую ссылку внизу экрана настольного браузера. Она должна быть большой, потому что Mobile Safari сожмет ее, а пользователи все равно должны ее увидеть и нажать, не увеличивая изображения. Эту ссылку можно сделать крупной и броской, так как пользователи настольного браузера ее все равно не видят. На дисплее iPhone она будет выглядеть, как на рисунке 6.

Рисунок 6. Ссылка для возврата в мобильный режим
Switch back to mobile link

Эта ссылка присваивает cookie пользователя значение mobile и возвращает на страницу index, где она опять интерпретируется как ссылка на мобильный браузер.


Заключение и планы на будущее

В этой статье рассказывается о структуре, необходимой для поддержки отдельного контента для пользователей iPhone и iPod. Здесь показано, как управлять окном просмотра для отображения контента Mobile Safari с правильным размером и масштабом, и начинается рассказ о том, что должно быть в макете мобильного сайта.

Во второй части показано, как отображать контент в браузере Mobile Safari, и приведены рекомендации по UI для управления контентом iPhone. Там же рассматривается вопрос о том, как использовать эти рекомендации при разработке своего собственного приложения Rails.

Ресурсы

Научиться

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

Обсудить

Комментарии

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=381270
ArticleTitle=Разработка приложений для iPhone с применением Ruby on Rails и Eclipse : Часть 1. Обслуживание контента для iPhone
publish-date=04102009