Portando WPF de cacau (e / ou vice-versa)

Question

Eu estou em estágios iniciais de criação de software para uma mISV-a-ser. O programa é uma aplicação desktop e no longo prazo, eu quero ter uma versão nativa para Windows e OS X (tenho um olhou para várias APIs de plataforma cruzada, e nenhum deles atender às minhas necessidades). Inicialmente, porém, eu não acho que isso faz sentido desenvolver para duas plataformas de uma só vez. Com isso em mente, eu tenho estado a olhar para WPF para Windows e Cacau para OS X, e eles parecem semelhantes.

Alguém já teve experiência de portar um para o outro? Há determinadas técnicas / paradigmas a seguir que vai fazer a portabilidade mais fácil? Ignorando considerações comerciais, que você recomendaria desenvolver em um deles pela primeira vez?

Answer 1

Atualmente estou trabalhando em ferramentas portar neste espaço e têm muitos anos de experiência frequentemente dolorosa usando ou escrever estruturas de plataforma cruzada em Mac e Windows.

Um dos maiores problemas no passado tem sido a recusa da Apple de abrir o formato de ponta para Cacau (nibs de carbono foram abrir arquivos XML anos atrás). Isso mudou com o Xcode 3 eo href="http://developer.apple.com/documentation/developertools/conceptual/IB_UserGuide/BuildingaNibFile/chapter_3_section_2.html" rel="nofollow noreferrer"> .xib formato , bem explicado por Frasier Speirs .

No nível de layout básico, pelo menos, existe agora uma oportunidade para automatizar a portabilidade de um formato XML para outro. Considero WPF (XAML) como mais limpo e por isso estou usando isso como meu formato de base e migrando para Cacau.

Quando se trata de trás do código, enquanto você pode usar C # sob Mono, o CocoaSharp projeto parece tanto parado ou muito lento e eu não recomendo.

Se você estiver confortável com C ++, considere ter tanta lógica quanto possível em C ++ com uma camada específica da plataforma thin em C # e Objective-C.

Outra pena abordagem investigando está usando uma linguagem dinâmica como Python ou Ruby. Eu não tenho certeza que é mais maduro neste momento entre IronPython e IronRuby mas ambos são agora suportadas pelo Microsoft pessoas. No lado do Cacau, eu acho que a flexibilidade da sintaxe Ruby vai triunfar e RubyCocoa é provavelmente a ultrapassagem PyObjC .

Caso contrário, o trabalho em C # e Objective-C e manter duas bases de código completamente independentes com projetos idênticos. Felizmente, os quadros têm semântica comparáveis ??para a maioria das coisas, especialmente se você faz uso de ligações.

Answer 2

Eu acho que você está no caminho certo, escolhendo ambientes de janelas que são específicos para cada plataforma. Esta abordagem permite que você crie uma experiência de usuário em cada plataforma que não se restringe pela compromete inerente a multi-plataforma de janelas toolkits.

Um bom primeiro passo é quebrar o seu projeto para baixo em duas partes: específicos plataforma e elementos neutros de plataforma. Você já pode colocar qualquer código de UI para a coluna específica da plataforma, mas talvez a sua aplicação vai precisar de algum persistência de dados que pode ser escrito em plataforma neutra C ++. O que você pode encontrar com esta abordagem é que há um pouco de lógica e de infra-estrutura que você pode escrever de uma forma de plataforma neutra, deixando apenas a interface do usuário e código de cola como específico da plataforma.

Houve um episódio recente de Late Night Cacau intitulado portar aplicativos grandes para a plataforma Mac . Seu aplicativo não pode qualificar como "grande", mas este podcast dá um pouco de grande conhecimento portabilidade de alguém que já fez isso algumas vezes.

Answer 3

Bem. Uma vez que você tenha escrito um aplicativo para Cocoa, é possível transportá-lo para o Windows. Isso poderia ser feito usando gnustep ou Cocotron .

Se você fazê-lo de outra maneira, VINHO se destina a tornar a portabilidade mais fácil.

Eu prefiro escrever a versão OSX primeiro. Isso ocorre porque os usuários do Windows não tem idéia clara o que eles querem uma aplicação a aparência. Na minha experiência, eles são bastante capazes de sofrer com todos os tipos de interfaces de usuário. Consistência tem pouco valor para eles. Como não há acordo comum, o que um aplicativo do Windows deve ser semelhante, nada impede que os usuários do Windows a partir de realmente gostando projeta OSX, e eles ainda fazem com freqüência. iTunes para aparência do Windows como um aplicativo muito típico OSX e você ouve muito poucas queixas que não seria suficiente do Windows-ish.

Indo na outra direção, isso não é verdade. usuários OSX tem uma clara preferência por aplicativos de cacau e muito pouca tolerância para, por exemplo, coisas como GIMP ou Inkscape que funcionam sob OSX tão bem como em qualquer outro lugar, mas se parecem claramente feio para o OSX treinado olho.

Answer 4

Bem, não é um caminho fácil. O melhor método é usar algo como padrão Model-View-Controller ou alguma outra arquitetura de lógica de negócios separada e assim por diante a partir da apresentação. No entanto, a menos que você estiver usando Mono, haverá muito pouco código para você compartilhar, eu think.If você está desenvolvendo WPF então você certamente fazendo .NET e, diferente de Mono, Objective-C é a ferramenta de programação padrão no Mac OS X.

Mantenha um bom design e você pode ter mais do seu código ser simplesmente uma versão Objective-C do seu código .NET e vice-versa, em vez de tentar encontrar um caminho de migração.