Posso escrever um aplicativo de plataforma cruzada (Mac e Windows) usando C #? [fechadas]


8

Vejo muitas informações antigas sobre essa questão, e muitos artigos circulando pelas Interwebs, mas não sei dizer exatamente onde estão as coisas.

Basicamente, quero escrever código C # que possa ser compilado em um aplicativo nativo do Windows e também em um aplicativo nativo do Mac (sem Parallels, Wine, etc.). Isso pode ser feito?

Produtos como o Xamarin são o caminho? O site da Xamarin diz "Use o mesmo idioma, APIs e estruturas de dados para compartilhar uma média de 75% do código do aplicativo em todas as plataformas de desenvolvimento móvel". mas não sei dizer o que esses 25% do código do aplicativo específico da plataforma podem acarretar ... Também não sei dizer se eles são direcionados ao OSX e Windows, o site deles é muito centralizado em dispositivos móveis.

[adicionado mais tarde]

Resumo: O Xamarin não foi projetado para criar aplicativos de plataforma cruzada - o que eles oferecem é uma maneira de escrever aplicativos Mac em C #, usando as operações da GUI do Mac. O que eles recomendam é escrever toda a sua "lógica de negócios" em várias plataformas e, em seguida, escrever duas GUIs completamente separadas - uma para Windows e outra para Mac.

O C # / Qt parece estar em suas fases muito iniciais (embora se alguém tropeçar neste artigo em 2016 ou mais tarde, vá conferir).

Parece que o mono fará várias plataformas, incluindo a GUI, mas somente se você usar o Windows Forms.


Você pode verificar docs.asp.net/en/latest/getting-started/index.html e code.visualstudio.com . O Visual Studio e o .NET foram criados de código aberto. Hoep que resolve o seu propósito. Mas sim, se você deseja criar um aplicativo GUI, acho que ainda não é possível.
Krishnandu Sarkar

Eles têm o Xamarin.Forms agora na versão paga. Não faz tudo, mas faz um pouco. Ele permite que você desenvolva uma GUI de plataforma cruzada.
MetalMikester

@KrishnanduSarkar do que você está falando? O que o ASP .NET tem a ver com isso? :)
Konrad Morawski

@KrishnanduSarkar, mais essa é a primeira vez que ouço sobre o Visual Studio de código aberto. Você poderia fornecer um link para essas informações?
Konrad Morawski

@KonradMorawski Não é. Eu pensei em apenas informá-lo. É por isso que mencionei que, se ele estiver ansioso para criar um aplicativo GUI, isso não servirá a seu propósito. Bem link já é dado no meu comentário.
Krishnandu Sarkar

Respostas:


10
  1. O Xamarin não "mira" no Windows, porque não faz sentido - o que quer que você escreva em C #, está pronto para ser executado no Windows por si só. É por isso que eles estão apenas vendendo licenças para o Xamarin.Android, Xamarin.iOS e Xamarin.Mac. Mas o que uma camada de abstração do Xamarin.Windows deveria fazer? Isso seria um livro de óleo de cobra :)

  2. "Aplicativo nativo do Windows" - nativo é uma palavra complicada quando se trata de c #. Os aplicativos C # normalmente requerem o .NET ou o Mono runtime, criados com o uso do Xamarin ou não. Se você deseja criar binários nativos em vez de IL , existem soluções como .NET Native ou ngen , mas é uma questão independente do uso do Xamarin. Suponho que você não quis dizer "nativo" nesse sentido estrito, mas é bom estar ciente dessa distinção. Com o C #, mesmo no Windows, você normalmente usa uma espécie de máquina virtual.

  3. O Xamarin.Mac requer o tempo de execução Mono.OSX para que o código C # possa ser criado. E cria uma ponte sobre o tempo de execução do Objective-C com o Mono.OSX, conforme descrito em Xamarin.Mac Internals :

    Há o tempo de execução baseado em Objective-C que contém instâncias de classes nativas (NSString, NSApplication, etc) e há o tempo de execução C # que contém instâncias de classes gerenciadas (System.String, HttpClient, etc.). Entre esses dois trabalhos, o Xamarin.Mac cria uma ponte bidirecional para que você possa chamar métodos (seletores) no Objective-C (como NSApplication.Init) e Objective-C pode ligar de volta (como métodos no delegado do aplicativo)

    Então, sim, o aplicativo resultante é "nativo" no sentido de que não é - digamos - um pedaço de HTML envolvido em algum componente do WebView. Você tem acesso a elementos da interface do usuário nativos e APIs. Não é nativo no sentido em que requer a instalação do Mono.OSX. Em outras palavras, é tão nativo quanto o C # no Windows fica em circunstâncias padrão.

  4. Você também pode se familiarizar com http://blog.xamarin.com/introduction-to-xamarin.mac-seminar/ - ele pode ser datado (2013), mas acredito que as principais verdades sejam verdadeiras. Dê uma olhada no slide 7.

  5. "Não sei dizer o que esses 25% do código de aplicativo específico da plataforma podem implicar" - por definição, tudo o que não é independente de plataforma, portanto, praticamente a lógica de negócios "pura" e tudo o que você abstrai implementações concretas (como alguma interface "IRepository" etc.). O que quer que seja específico da plataforma: interface do usuário, persistência do banco de dados, bibliotecas de terceiros para Windows ou Mac, não podem ser compartilhadas. A proporção 75/25 é muito simples, sua milhagem pode variar muito, dependendo da natureza do seu aplicativo.

Observe que eu só tive uma experiência não comercial com o Xamarin para plataformas móveis e não abrangeu o iOS (apenas Windows Phone e Android). Se estou impreciso quanto a isso, corrija-me.


Você também pode mencionar github.com/mono/xwt , é uma camada de abstração para GTK #, MonoMac, Xamarin.Mac e WPF para GUI.
Residuum
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.