Nos meses após o release pela Apple do iPhone e do iPod touch, o Mobile Safari tornou-se o navegador da Web remoto mais comum nos Estados Unidos e sua participação no mercado continua a crescer. Como o fator de formato e o modelo da interface com o usuário (UI) do iPhone são tão diferentes de outros navegadores remotos, muitos desenvolvedores estão optando por reprojetar seus Web sites para suportar o modelo específico da UI do Mobile Safari.

A decisão de criar conteúdo customizado para o iPhone é o campo intermediário entre duas opções mais extremas. Em um extremo, você não poderia fazer nada. A interface de toque e zoom do Mobile Safari é projetada para permitir que usuários naveguem facilmente por Web sites mesmo se os sites não tiverem sido projetados para dispositivos remotos. A Apple usa essa rota baseada na teoria de que os usuários do iPhone esperam acessar toda a Web. No outro extremo, você poderia usar o release do novo kit de desenvolvimento de software (SDK) do iPhone para colocar seu aplicativo no iPhone de forma nativa. Isso fornece uma imensa quantidade de flexibilidade em sua UI, assim como acesso aos recursos do iPhone — como o acelerômetro ou a câmera — que são impossíveis de usar em um aplicativo da Web. O lado negativo é que o gasto adicional com a criação de um aplicativo SDK nativo é maior do que com a criação de um aplicativo da Web e, se você já tiver um aplicativo da Web, criar uma versão da Web customizada para o iPhone é a maneira mais rápida de colocar uma UI limpa para o iPhone nas mãos de seus usuários.

Este artigo mostra como construir um aplicativo Ruby on Rails que reconhece dinamicamente os navegadores do iPhone ou do iPod touch (ao longo deste artigo, faço referência ao iPhone — lembre-se de que tudo aqui também se aplica ao iPod touch), enquanto concede aos usuários do Mobile Safari a opção de verem todo o conteúdo da Web, se quiserem. O artigo foca também as estruturas do lado do servidor necessárias para suportar o fornecimento de conteúdo separado para usuários do iPhone e como iniciar o fornecimento de conteúdo do iPhone. Parte 2 desta série "Desenvolvendo Aplicativos de iPhone Usando Ruby on Rails e Eclipse" foca como dar a esse conteúdo uma aparência e comportamento do iPhone.

Configurando seu Ambiente

Este artigo usa o Eclipse com os plug-ins Aptana para Ruby on Rails e suporte ao iPhone. O plug-in Ruby on Rails fornece realce da sintaxe específica de Ruby e Rails, atalhos, ambientes de execução, etc. O plug-in iPhone fornece um ambiente de visualização para exibir seu aplicativo da Web em uma porta de visualização do tamanho do iPhone.

Há duas opções para adquirir a combinação Eclipse/Aptana: você pode incluir os plug-ins Aptana em um ambiente Eclipse existente ou pode fazer download do Aptana Studio, que é um derivativo do Eclipse, e incluir os plug-ins a partir da tela de inicialização fornecida pelo Aptana. Se você já tiver um ambiente Eclipse configurado, faça a procura típica de plug-in Eclipse. Selecione Ajuda > Atualizações de Software > Localizar e Instalar e inclua as URLs dos plug-ins fornecidas na seção Recursos . Você precisa de dois plug-ins Eclipse para seguir em frente. Se estiver usando o desenvolvimento Eclipse for Rails, você provavelmente já possui o plug-in RadRails. Você também estará usando o plug-in de desenvolvimento do iPhone, que fornece uma tela fictícia do iPhone para que você visualize seu desenvolvimento em uma porta de visualização do tamanho do iPhone. Apesar de esse plug-in ser projetado para visualizar páginas HTML estáticas, também pode ser configurado para apontar para seus aplicativos Rails. A Figura 1 mostra o plug-in em ação.

A primeira coisa que você observará sobre a exibição do plug-in é que é maior do que a de um iPhone real. Isso é para manter compatibilidade pixel-a-pixel — a exibição do plug-in possui as mesmas dimensões de pixel que a exibição do iPhone, mas o iPhone tem uma densidade de pixel muito maior. Se estiver em um Macintosh, há duas outras opções para um simulador de iPhone: iPhoney ou o simulador oficial do iPhone incluídos no SDK do iPhone.

iPhoney é um aplicativo dedicado que fornece uma exibição fictícia do iPhone semelhante ao plug-in Aptana. As duas exibições diferem no que mostram quando o site é maior do que a porta de visualização do iPhone. Como pode ver, o plug-in Aptana exibe o tamanho integral do conteúdo e oferece barras de rolagem. No iPhoney, a página da Web é compactada para o tamanho da porta de visualização (mantendo a exibição real do iPhone da página). Nenhum dos dois aplicativos suporta o toque duplo do Mobile Safari para aumentar e reduzir o zoom, portanto, não há um substituto completo para testar em um iPhone real.

Se tiver assinado e transferido por download o SDK oficial do iPhone, também pode usar o simulador de iPhone oficial que faz parte desse pacote. Envia o agente de usuário correto e imita todo o comportamento do Mobile Safari, incluindo o zoom de toque duplo. As únicas pequenas desvantagens são que você precisa estar executando o Mac OS X V10.5 e como está simulando todo o sistema operacional do iPhone, é necessário ativar o Mobile Safari na inicialização. Você também pode obter uma lista de origem HTML como poderia a partir de um navegador de desktop. Se poder usá-la, é o simulador mais fiel do Mobile Safari disponível.

Voltar para parte superior

Fornecendo Conteúdo para iPhone

Suponhamos que você seja o proprietário de Soups OnLine, sua fonte on-line para tudo quente e em caldo. Se site tem ótima aparência em um desktop, mas você toma ciência de que um número crescente de usuários precisa de informações de sopa quando estão na rua e estão acessando o site através de um iPhone. Atualmente, seus usuários de iPhone veem o que é mostrado abaixo.

Não é horrível e, graças à bela UI com zoom do Mobile Safari, o usuário pode navegar pelo site. Ainda assim, parece que a aparência poderia ser mais limpa e mais direcionada às necessidades de um usuário remoto.

Devo mencionar aqui que Soups OnLine é o site criado em meu livro Professional Ruby On Rails. Eu o uso aqui principalmente porque é um site completo já existente com o qual posso brincar, sem afetar o copyright de outra pessoa. Consulte Recursos para obter código para a versão do Soups OnLine usado neste artigo e o modelo no qual a versão original foi baseada.

Para atender seus usuários remotos, seu aplicativo Rails precisa gerenciar o seguinte:

• Detectar quando um usuário acessa o site usando um iPhone ou um iPod touch.
• Permitir que o usuário alterne livremente entre as versões remota e regular do site.
• Usar um layout diferente para usuários do Mobile Safari, incluindo arquivos Cascading Style Sheets (CSS) separados e, possivelmente, bibliotecas JavaScript.
• Fornecer conteúdo diferente para usuários remotos.

O código usado para executar essas tarefas neste artigo pode ser usado no estado em que se encontra. Também foi reunido em um plug-in Rails chamado rails_iui, que você pode incluir em seu projeto para obter toda a mesma funcionalidade em um único pacote.

Voltar para parte superior

Detectando Usuários do Mobile Safari

Para fornecer conteúdo customizado para iPhone, seu aplicativo Rails precisa poder reconhecer um iPhone. Do lado do servidor, o principal meio de identificação é a string do agente do usuário enviada pelo navegador ao servidor. A string do agente do usuário do iPhone é semelhante à seguinte (números de versões serão alterados ao longo do tempo):

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

A string do usuário do iPod touch difere em que o início da expressão entre parênteses é iPod, em vez de iPhone. A Apple, mesmo que não seja importante, recomenda usar o número da compilação do WebKit (neste exemplo, AppleWebKit/420+) para determinar se novas tags ou configurações de CSS estão disponíveis. (Se estiver testando do lado do cliente, em vez de do lado do servidor, a Apple recomenda não usar a string do agente do usuário, mas testar a existência de recursos específicos.)

No Rails, você deve poder identificar um agente do usuário de iPhone em ApplicationController para uso eventual em um filtro before . Você não pode simplesmente procurar "iPhone" na string, pois não encontrará o iPod touch. No momento, parece que a maneira mais à prova do futuro para identificar usuários de iPhone é correspondendo "Mobile" e "Safari", desta forma:

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

Agora, a meta é integrar o iPhone à estrutura respond_to do Rails V2.0, de forma que o iPhone seja tratado automaticamente como um tipo pseudo-MIME e você pode aprimorar seus controladores conforme mostrado abaixo.

                
    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
  

Isso usa umas duas etapas. primeiro, inclua a linha a seguir no arquivo config/initializers/mime_types.rb:

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

Versões recentes do Rails têm essa linha como um comentário no arquivo, portanto, você pode apenas remover a indicação de comentário. Para versões mais antigas do Rails que não têm um diretório config/initializers, você pode colocar essa linha em config/environment.rb. Isso cria um tipo MIME iphone customizado para ser usado em seu aplicativo. Externamente, o tipo iphone é tratado como text/html, mas, internamente, é possível responder aos dois tipos de forma diferente.

De volta ao ApplicationController, inclua outro método privado como um filtro before .

                
    before_filter :set_iphone_format

    def set_iphone_format
      if is_iphone_request?
        request.format = :iphone
      end
    end
  

Nesse ponto, todos os pedidos de um iPhone ou iPod touch serão sinalizados com um pedido de formato igual a :iphone. Observe que nenhuma parte desse código até o momento é específica do exemplo do site que estou usando, portanto, você deve se sentir livre para incluir esse trecho de código em qualquer site no qual esteja trabalhando.

Se estiver usando o plug-in rails_iui, tudo o que você precisa fazer é inserir a linha a seguir em seu ApplicationController ou em qualquer controlador que você deseja para responder a pedidos do iPhone:

    acts_as_iphone_controller
  

Conforme mencionado, o plug-in Aptana não envia a string do agente do usuário listada acima. No entanto, as convenções de nomenclatura do Rails criam uma fácil solução alternativa. Usando a extensão iphone em qualquer URL (como em http://localhost:3000/recipies.iphone) configura automaticamente o formato do pedido para :iphone e faz com que o conteúdo para iPhone seja fornecido. Isso permite testar seu código para iPhone no simulador Aptana. Se estiver usando o plug-in rails_iui, alterar o comando acima para acts_as_iphone_controller(true) coloca o aplicativo em um modo de teste onde todos os pedidos são tratados como pedidos do iPhone, fazendo com que os testes no simulador ou em outro navegador sejam muito fáceis.

Voltar para parte superior

Visualizando Conteúdo para iPhone Durante o Desenvolvimento

Mencionei quatro maneiras de visualizar seu Web site otimizado para iPhone enquanto em desenvolvimento:

• Plug-in Eclipse para iPhone do Aptana
• iPhoney
• Simulador do SDK do iPhone
• iPhone ou iPod touch

Plug-in Eclipse para iPhone do Aptana

O plug-in Aptana possui algumas vantagens. É uma ferramenta para várias plataformas que é executada em qualquer lugar que o Eclipse seja. Permite ver versões remotas e clássicas de seu site lado a lado e integra-se bem a outras ferramentas de desenvolvimento Eclipse. O plug-in permite visualizar seu aplicativo em diversos navegadores ao mesmo tempo, o que é útil se você tiver como alvo usuários remotos e tradicionais. Além disso, se você estiver usando o JavaScript do lado do cliente no iPhone, o Aptana possui um belo recurso de console que permite registrar eventos de um iPhone conectado e, até mesmo, enviar comandos JavaScript ao telefone a partir de seus aplicativos. Como o foco deste artigo é desenvolvimento do lado do servidor, não vou discutir esses recursos aqui.

O lado negativo é que o plug-in Aptana é meio pesado se você não estiver usando o Eclipse como seu outro ambiente de desenvolvimento, apontá-lo para iniciar em páginas específicas é um pouco estranho e não imita bem o comportamento real do iPhone em sites mais amplos do que a exibição do iPhone. Outro ponto negativo é que o plug-in Aptana não se identifica usando a string do agente do usuário do iPhone ou iPod touch. Conforme descrito, isso significa que você precisa de uma solução alternativa para visualizar o conteúdo para iPhone no Aptana.

Com o plug-in Aptana instalado, inicie um novo projeto do tipo iPhone e dê um nome ao projeto. O plug-in Aptana é usado como padrão para testar a página index.html estática no projeto. Isso não é o que você realmente quer aqui. Você quer que vá para a página de índice de seu aplicativo. Na janela Propriedades para o projeto iPhone:

1. Vá para a guia Visualização de HTML e clique em Substituir Configurações da Área de Trabalho.
2. No painel Tipo de Visualização, clique em Usar URL Absoluta.
3. Insira a URL para seu servidor Rails em execução localmente. (O projeto Rails não precisa estar em execução no Eclipse. Precisa apenas estar em execução na URL que você fornecer o plug-in.)

Quando tiver terminado, tudo deve ter a aparência da Figura 3.

iPhoney

Usar o iPhoney é outra opção para visualizar conteúdo para iPhone. É mais leve, permite inserir URLs arbitrárias na barra de endereço e compacta páginas amplas de forma precisa. O lado negativo é que é um aplicativo somente para Macintosh. Se você usar o iPhoney, certifique-se de configurar as preferências no menu iPhoney para usar a string do agente do usuário do iPhone, que não é o comportamento padrão.

Simulador do SDK do iPhone

O simulador do SDK do iPhone funciona de forma semelhante. Ative o programa e clique no botão Safari para entrar no navegador. Você pode inserir Web sites diretamente na barra de endereço com o teclado, apesar de se você simplesmente precisar, o teclado virtual do iPhone também aparecerá. Um belo recurso desse simulador é que suporta os marcadores do Mobile Safari e a funcionalidade "local na tela inicial". Do lado negativo, como não é realmente um simulador do Safari, não tem uma maneira fácil de mostrar a origem de HTML que está sendo apresentada, que todos os outros simuladores podem fazer facilmente.

iPhone ou iPod touch

Por fim, você pode usar somente um iPhone ou iPod touch real. Problemas de rede são seus principais obstáculos aqui. Se você estiver na situação comum de desenvolver em um servidor que fica por trás de um roteador e tem um endereço IP em um dos intervalos privados (10.*.*.*, 172.16-31.*.* ou 192.168.*.*), o iPhone poderá ver somente seu servidor de desenvolvimento se estiver conectando à Internet através de uma rede Wi-Fi local na qual está seu servidor. (Você também terá maior facilidade se usar o endereço IP diretamente.) Se não puder configurar essa situação (por exemplo, se não houver nenhuma rede Wi-Fi disponível com permissão para alcançar seu servidor), será necessário implementar seu aplicativo em um servidor intermediário disponível publicamente para testá-lo.

Tente Visualizar seu Site

Independentemente da opção usada para visualizar o iPhone, tente e toque uma página em seu site. Neste exemplo, a página foi configurada para http://localhost:3000/recipes. (Que deveria ser recipes.iphone no navegador Aptana ou estar no modo de teste se você estiver usando o plug-in rails_iui.) Se tiver feito as mudanças de código descritas anteriormente, verá uma página em branco. Esse é o comportamento esperado. (Pode verificar isso visualizando o site no navegador do desktop de sua opção — funcionará bem.) O filtro before identificou o Mobile Safari, alterou o formato de resposta e agora está tentando fornecer a resposta sequencialmente com as convenções Rails. Neste caso, a convenção Rails é tentar localizar um bloco respond_to para iphone. Se um for localizado, Rails procura o arquivo layout.iphone.erb para obter o layout e, em seguida, preenche o interior da página com o conteúdo de app/views/recipes/index.iphone. Como nada disso existe ainda, Rails fornece uma página em branco. Especificamente, fornece uma página em branco, pois você ainda não indicou que o método index do controlador de receita deve responder aos pedidos formatos para iphone.

Voltar para parte superior

Criando um Layout para iPhone

Quando você sabe que seus usuários estão navegando por seu site com iPhones, você pode fazer diversas fortes suposições sobre seus ambientes. No momento, o ecossistema do Mobile Safari possui somente dois dispositivos com telas e software de navegador com dimensionamento idênticos. A área de visualização visível na parte superior de uma página em um iPhone tem 320 pixels de largura e 356 pixels de altura. A barra da URL na parte superior da página é 60 pixels adicionais que você obterá à medida que seu usuário rolar para baixo. As páginas do Mobile Safari vão até a borda da tela em ambos os lados sem nenhuma margem.

O comportamento padrão do Mobile Safari é assumir que o Web site tem 980 pixels de largura e reduzi-lo em aproximadamente um terço para se ajustar na área visualizável do iPhone. Isso funciona bem para muitos sites, mas não se seu site for estreito de forma incomum e não se você estiver tentando realmente fazer seu site se ajustar às dimensões exatas do iPhone. Felizmente, o Mobile Safari tem um mecanismo para você especificar exatamente qual largura você deseja usar para exibir seu site.

Você pode usar uma meta tag especial para especificar as propriedades da porta de visualização do Mobile Safari. A Lista 3 mostra a aparência da tag colocada no novo arquivo de layout app/views/layouts/recipes.iphone.erb.

                
    <!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>
  

A meta tag da porta de visualização configura duas propriedades da porta de visualização. A primeira, width = device-width, indica ao Mobile Safari que você deseja que seu site seja apresentado usando a largura atual do dispositivo. O valor também pode ser configurado para qualquer valor constante entre 200 e 10.000. A segunda propriedade, user-scalable = no, desativa o comportamento do zoom de toque duplo do Mobile Safari com base em você estar configurando o site para se ajustar à tela de visualização do iPhone. Além dessas propriedades, você também pode configurar a altura de sua página. Se quiser controle mais granular do comportamento de escala do usuário, você pode configurar uma initial-scale, uma minimum-scale e uma maximum-scale. Todas as três usam 1,0 como o padrão e podem variar entre 0,0 e 10,0.

A outra linha específica do iPhone nesse arquivo de layout parcial é a tag de folha de estilo CSS, que especifica um novo arquivo CSS específico do iPhone. Você pode ver algumas referências que recomendam usar CSS condicional para conteúdo para iPhone. Você pode fazer isso, mas acho a sintaxe meio opaca. Como você sabe do lado do servidor em qual navegador está renderizando, não há, na verdade, nenhuma necessidade — você pode especificar o arquivo exato que você deseja para esse navegador.

A Lista 4 á o arquivo CSS I criado para tratar do cabeçalho inicial para a versão para iPhone do Soups OnLine.

                
    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;
    }
  

Há somente algumas diferenças entre esse arquivo e as entradas correspondentes no arquivo CSS original. O tamanho da fonte do elemento h1 é menor (na verdade, eu ajustei o tamanho que desejava através de um pouco de tentativa e erro). A tag h1 agora está em negrito e tem uma configuração de margem explícita igual a zero. O negrito ajuda a ser destacada um pouco mais e a margem zero coloca a mesma bem próxima do canto superior esquerdo da porta de visualização. As dimensões da classe do ID #header agora estão na linha com a porta de visualização do iPhone e eu alterei manualmente a imagem de plano de fundo para se ajustar no espaço.

Você também precisa criar o arquivo app/views/recipes/index.iphone.erb, mas, no momento, pode deixá-lo em branco. Com essas mudanças realizadas, a versão para iPhone do site está a caminho. o cabeçalho parece a Figura 4.

Na maioria dos simuladores, você aprenderá que a rotação da porta de visualização faz com que a imagem seja escalada para corresponder a nova largura de 480 pixels do dispositivo. Isso porque você especificou que a largura do dispositivo deve ser usada como a dimensão de escala.

Voltar para parte superior

Aceitando e Cancelando a Opção

A última coisa a incluir é um mecanismo para que os usuários do Mobile Safari possam cancelar a opção da visualização remota e, em seguida, aceitar a opção novamente. Isso concede a um usuário remoto a chance de ver a interface integral, que provavelmente possui mais recursos (apesar de poder ser mais difícil de navegar), em seguida, alternar de volta à interface do iPhone, conforme desejado. Você não deve configurar um link semelhante para usuários de desktop para optar pela interface de iPhone, pois, na Parte 2, você tem código CC e JavaScript específico do Mobile Safari e o site não funcionará.

O mecanismo é simples: você inclui links no rodapé da interface do iPhone que configuram um cookie, especificando a preferência do tipo de navegador do usuário. Em seguida, você permite que essa preferência substitua a string do agente do usuário ao determinar qual formato enviar. Primeiro, inclua o link. Altere a tag body no arquivo app/views/layouts/recipes.iphone.erb.

                
    <body>
      <h1 id="header"><%= "Soups OnLine" %></h1>
      <%= yield %>
      <br/>
      <%= link_to "Switch To Desktop View",
          {:controller => "browsers", :action => :desktop},
          :class => "mobile_link"  %>
    </body>
  

O link tem uma nova classe CSS definida no arquivo CSS do iPhone.

                
    .mobile_link {
      font-size: 14px;
    	font-weight: bold;
    	font-family: Helvetica;
    	color: #00f;
    	text-decoration: none;
    	text-align: center;
      display: block;
    	width: 320px;		
    }
  

Helvetica é a fonte de opção para links de sistema do iPhone. O tamanho da fonte é um pouco menor do que o recomendado para o texto do corpo, mas isso não deve ser texto do corpo. Os outros itens centralizarão o link na porta de visualização. O resultado é semelhante à Figura 5.

A próxima etapa é configurar o cookie. Como pode ver na definição do link na Lista 5, criei uma nova classe de controlador BrowsersController para gerenciar esse código. A Lista 7 fornece o código para configurar o cookie.

                
    class BrowsersController < ApplicationController
      def desktop
        cookies["browser"] = "desktop"
        redirect_to recipes_path
      end
      def mobile
        cookies["browser"] = "mobile"
        redirect_to recipes_path
      end
    end
  

Você pode ver que é bem simples. Simplesmente configura o cookie e redireciona de volta à página que está sendo usada como a página de índice. Após isso, é necessário alterar o método set_iphone_format para levar a preferência do navegador em consideração.

                
    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
  

Na verdade, há duas mudanças aqui. A instrução if inicial inclui a cláusula request.format.to_sym == :iphone. Isso permite que as URLs que são pedidos do iPhone através da extensão .iphone também tenham a oportunidade de ter seu formato substituído pelo cookie. Isso está lá principalmente para permitir que esse código seja testado no simulador Aptana. Após isso, request.format é configurado com base se o cookie do usuário tem o valor desktop, conforme configurado no método BrowserController .

A única tarefa remanescente é incluir o link de cancelamento da opção para a visualização do desktop. Você deseja que os usuários do iPhone vejam somente isso, portanto, comece incluindo a linha a seguir no ApplicationController:

    helper_method :is_iphone_request?
  

Essa linha torna o método is_iphone_request? um método auxiliar que pode ser chamado de qualquer visualização. Especificamente, você pode usá-lo para incluir o conteúdo da Lista 9 no final do layout do desktop original no arquivo app/views/layouts/recipes.html.erb.

                
    <% if is_iphone_request? %>
      <%= link_to "Switch To Mobile Safari View",
          {:controller => "browsers", :action => :mobile},
          :class => "big_link"  %>
    <% end %>
  

Essa inclusão configura o link análogo no navegador de desktop. Também inclui uma classe CSS no arquivo CSS do desktop (neste caso, public/scaffold.css).

                
    .big_link {
      font-size: 40px;
    	font-weight: bold;
    	font-family: Helvetica;
    	color: #00f;
    	text-decoration: none;
    	text-align: center;
    	display: block;
    	width: 980px;		
    }
  

A classe CSS inclui um belo link grande impossível de não ver na parte inferior da área de janela do desktop. Precisa ser realmente grande, pois o Mobile Safari vai reduzi-lo para ser ajustado e você vai querer que os usuários possam vê-lo e clicá-lo mesmo se não usarem zoom na exibição. Você pode fazê-lo grande e chamando a atenção, pois usuários de desktop não verão esse link. Em uma exibição de iPhone, o link tem a aparência da Figura 6.

O link configura o cookie do usuário para mobile e redireciona de volta à página de índice, onde o link é interpretado como sendo para um navegador remoto novamente.

Voltar para parte superior

Resumo e Visão à Frente

Este artigo focou a estrutura necessária para suportar a separação do conteúdo para usuários de iPhone e iPod touch. Cobriu como gerenciar a porta de visualização para exibir o conteúdo do Mobile Safari no tamanho e escala certos e começou a discutir o que colocar no layout básico de seu site remoto.

Parte 2 cobre como exibir seu conteúdo em um navegador Mobile Safari. Também dá uma olhada nas diretrizes da UI para gerenciar conteúdo de iPhone e explorar como ativar essas diretrizes em seus próprios aplicativos Rails.

Recursos

Aprender

• Leia Professional Ruby on Rails do autor deste artigo para aprender como pegar um Web site principiante e torná-lo maravilhoso.
  
  
• Consulte Plugging Aptana into an existing Eclipse configuration para obter instruções sobre como integrar o Aptana Studio no Eclipse.
  
  
• " iPhone on Rails - Creating an iPhone optimised version of your Rails site using iUI and Rails 2" é um blog sobre como usar iPhone e Rails.
  
  
• Visite Apple Developer Connection para obter mais recursos para aplicativos da Web para iPhone (registro necessário).
  
  
• Para obter uma introdução para o plug-in de desenvolvimento para iPhone do Aptana, consulte o artigo do developerWorks " Desenvolver Aplicativos da Web para iPhone com o Eclipse."
  
  
• Para ouvir entrevistas e discussões interessantes para desenvolvedores de software, verifique os podcasts do developerWorks.
  
  
• Mantenha-se atualizado com Eventos Técnicos e Webcasts do developerWorks.
  
  
• Verifique conferências, feiras comerciais, webcasts e outros Eventos futuros no mundo que sejam de interesse de desenvolvedores de software livre da IBM.
  
  
• Visite Zona de Software Livre do developerWorks para obter informações extensivas sobre como executar ações, sobre ferramentas e atualizações de projetos para ajudá-lo a se desenvolver com tecnologias de software livre e usá-las com produtos IBM.
  
  
• Assista e aprenda sobre as tecnologias IBM e de software livre e funções de produtos gratuitamente com os Demos On Demand do developerWorks.
  
  

Obter produtos e tecnologias

• Visite Aptana para fazer download do Aptana Studio, assim como plug-ins RadRails e iPhone.
  
  
• Vá para o Site de Atualização do Aptana para obter os plug-ins Aptana RadRails e iPhone .
  
  
• Explore iPhoney.
  
  
• Verifique o código para a versão do Soups Online usado neste artigo.
  
  
• O design e CSS do site Soups OnLine original foram adaptados de um modelo no endereço FreeWebTemplates.com.
  
  
• Verifique o plug-in rails_iui .
  
  
• Inove seu próximo projeto de desenvolvimento de software livre com software de avaliação da IBM, disponível para download ou em DVD.
  
  
• Faça download do versões de avaliação de produtos IBMe entre em contato com ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli®e WebSphere®.
  
  

Discutir

• Participe de Blogs do developerWorks e envolva-se na comunidade developerWorks.
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Configurando seu Ambiente
• Fornecendo Conteúdo para iPhone
• Detectando Usuários do Mobile Safari
• Visualizando Conteúdo para iPhone Durante o Desenvolvimento
• Criando um Layout para iPhone
• Aceitando e Cancelando a Opção
• Resumo e Visão à Frente
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais