Windows Bridge para iOS

Dando continuidade a série de posts sobre como trazer o seu aplicativo para o Windows vamos falar hoje do Windows Bridge para iOS (anteriormente chamado de “Project Islandwood”), essa ponte permite que desenvolvedores iOS tragam o seu código e conhecimento para o Windows. E o melhor, é open-source e está no GitHub!

Como a versão final ainda está em desenvolvimento é importante cautela no uso. O mais interessante é ir aprendendo e testando essa funcionalidade incrível que é trazer os apps prontos de iOS para o Windows 10.

A bridge é composta por quatro componentes:

  1. Compilador Objective-C: Para fazer a maior parte do trabalho pesado, o Visual Studio vai incluir um compilador que sabe extrair código Objective-C e compilá-lo em um aplicativo nativo Windows Universal. Por enquanto a Microsoft está fornecendo uma pequena parte do binário do compilador via GitHub (não vai ser aberto o código do compilador). A versão final do compilador vai ser parte do Visual Studio 2015 desse ano.
  2. Objective-C runtime: Vai fornecer recursos de linguagem, como envio de mensagens, delegação e contagem de referência automática.
  3. API iOS headers/libs: Com base nas APIs do Objective-C, a Microsoft fornece uma ampla compatibilidade com as APIs do iOS. Contribuições e comentários são bem vindos, caso encontre algumas APIs que ainda não são suportadas ou que possam ser melhorada.
  4. Integração com Visual Studio: Por fim, o seu projeto Xcode vai ser importado pelo Visual Studio 2015.

Por que uma bridge e não um port

O objetivo da bridge para iOS não é simplesmente executar um aplicativo iOS no Windows, ajudando os desenvolvedores a escreverem excelentes apps para Windows e usarem o máximo de códigos e conhecimentos já existentes.

Atrás disso tem três princípios fundamentais que levaram a arquitetura e o design da ponte:

  1. Acesso total as APIs do Windows: Tornar fácil o uso de APIs do Windows no código Objective-C.
  2. Compatibilidade com iOS: Permitir que desenvolvedores reutilizem o máximo de código iOS já existente.
  3. Sem sandboxing: APIs de iOS e Windows devem trabalhar juntas.

O primeiro princípio é muito importante, porque o Windows tem um conjunto APIs rica e totalmente funcional que cresce e evolui constantemente. Se a versão atual da bridge não suporta um recurso que você precisa, você não vai ficar “preso” até a próxima atualização, em vez disso, é feita uma versão simples para você usar a API do Windows e integrar tudo no seu código.

Quando APIs do Windows e Objective-C se encontram

Como introduzido no Build, a bridge usa um compilador personalizado (clang + cl) para compilar o código fonte Objective-C, e os arquivos de objeto gerados são ligados em conjunto, utilizando um vinculador da Microsoft. Esta abordagem é grande porque permite que Objective-C e C++/CX trabalhem juntos – eles podem coexistir no mesmo projeto e chamar um ao outro usando C ou interfaces C++.

A abordagem funciona, mas há uma pequena complicação, pois o clang não entende as extensões CX (que são necessárias para chamar APIs do Windows), então você é obrigado a criar os arquivos .cpp e conectar ao Objective-C e C++/CX manualmente, para que você possa tirar o máximo proveito do conjunto de APIs do Universal Windows Platform (UWP). Como isto é perfeitamente factível, a Microsoft acreditou que poderia fazer melhor, e aí que as “projeções” entram.

Projeção e a maneira que a Microsoft exporta a API do Windows para novas linguagens de programação. A Microsoft criou esse schema para que você possa consumir APIs do Windows diretamente do Objective-C.

Como exemplo, vamos examinar como invocar um navegador em seu aplicativo de forma assíncrona. Usando a bridge, você pode fazer isso de duas maneiras:

Usando c++/cx code:

auto uri = ref new Windows::Foundation::Uri("http://www.example.com");
concurrency::task<bool> launchUriOperation(Windows::System::Launcher::LaunchUriAsync(uri));
launchUriOperation.then([](bool success)
{
 if (success)
 {
  // URI launched
 }
 else
 {
  // URI launch failed
 }
});

Usando a mesma API no seu código Objective-C:

[WSLauncher launchUriAsync:[WFUri createUri:@"http://www.example.com/"] success:nil failure:nil];

Neste exemplo, não só estamos consumindo as classes de Windows::System ("Launcher") e Windows::Foundation("Uri"), mas estamos passando em um NSString e o sistema de projeção trata isso “magicamente” como um HSTRING em tempo de execução. Mas vai mais longe: IVectors e IVectorViews pode ser tratado como NSMutableArrays e NSArrays respectivamente, com mapeamentos semelhantes para iterators, enumerators, mapas e alguns novos que chegam em breve. E, para tornar as coisas mais fáceis, a vida útil dos objetos – sejam eles UWP ou Objective-C – são administrados por meio a mesma semântica de contagem automática de referências (ARC) que você já está acostumado.

Há muita coisa acontecendo aqui e reitero que isso ainda está em desenvolvimento. Nesse meio tempo, dê uma olhada em alguns samples no GitHub para ver isso com mais detalhes.

XAML e UIKit: Finalmente juntos

Agora que você pode chamar as APIs do Windows a partir de Objective-C, nós não queremos limitar a utilização desse conjunto de APIs.  Em vez de implementar um modelo separado para elementos iOS / UIKit, todo o aplicativo usa o XAML, com os CALayers (todas as Views em iOS) correspondente no XAML.

Então, vamos imaginar que o seu aplicativo gostaria de executar um vídeo, mas infelizmente, a bridge iOS ainda não suporta MPMoviePlayerController. Através deste mecanismo, você pode criar um XAML MediaElement, e então fazer um wrap para CALayer, e colocar todas as outras UIViews. É muito fácil e todas as suas animações e transformações vão trabalhar para este elemento como qualquer outro.

// WXCMediaElement is the Objective-C projection of
// Windows::UI::Xaml::MediaElement
WXCMediaElement *mediaElement = [WXCMediaElement create];
mediaElement.autoPlay = YES;
CALayer *mediaElementLayer = [CALayer layer];
[mediaElementLayer setFrame:CGRectMake(10, 10, 320, 240)];
[mediaElementLayer setContentsElement: mediaElement];
mediaElement.source = [WFUri createUri: @"ms-appx:///myvideo.mp4"];

// Now we just add the layer to be part of a UIView
 [[containingView layer] addSublayer: mediaElementLayer];

O objetivo ao longo prazo da Microsoft é ter a cobertura da maioria das classes comuns no SDK, com contribuições da comunidade. Nesse período, estarão disponíveis versões mais simples, para os desenvolvedores poderem usar os controles XAML onde o elemento equivalente do UIKit ainda não é suportado.

Olhando para o futuro

O source da bridge para iOS está no GitHub (https://github.com/Microsoft/WinObjC/). Este é o começo de uma jornada, a Microsoft está empenhada para trabalhar com a comunidade para evoluir a ponte para iOS e ajudar os desenvolvedores a transformar os seus aplicativos iOS em apps Universal Windows Platform. Esse compartilhamento do GitHub é uma prévia do SDK que pode ser usado para apps Windows 10 e Windows 8.1, aplicações para arquitetura x86 e x64. Em breve estará disponível para arm, ou seja, para dispositivos móveis!

Não deixe de acompanhar aqui no talkitbr todas as novidades do Windows 10, em breve traremos mais informações sobre esses assuntos.

Até a próxima!

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s