Posso scrivere un'applicazione multipiattaforma (Mac e Windows) usando C #? [chiuso]

Question

Posso scrivere un'applicazione multipiattaforma (Mac e Windows) usando C #? [chiuso]

#1 da (10 voti)

8

Vedo molte vecchie informazioni su questa domanda e molti articoli che volano intorno all'interweb, ma non so dirti dove siano le cose.

Fondamentalmente, voglio scrivere codice C # che posso poi compilare in un'applicazione nativa di Windows, e anche compilare un'applicazione nativa per Mac (niente Parallels, niente Wine, ecc.). Questo può essere fatto?

I prodotti come Xamarin sono la strada da percorrere? Il sito Web di Xamarin afferma: "Utilizza lo stesso linguaggio, le API e le strutture dati per condividere una media del 75% del codice dell'app su tutte le piattaforme di sviluppo mobile". ma non posso dire che cosa potrebbe comportare il 25% del codice app specifico della piattaforma ... Inoltre non posso dire se hanno come target OSX e Windows, il loro sito web è molto incentrato sui dispositivi mobili.

[aggiunto dopo]

Riepilogo: Xamarin non è progettato per creare applicazioni multipiattaforma: ciò che ti danno è un modo per scrivere applicazioni Mac in C #, utilizzando le operazioni della GUI del Mac. Quello che loro raccomandano è di scrivere tutta la tua "business logic" multipiattaforma, e quindi scrivere 2 GUI completamente separate - una per Windows, una per Mac.

C # / Qt sembra essere nelle sue primissime fasi (sebbene se qualcuno stia inciampando su questo articolo nel 2016 o più tardi, vai a dare un'occhiata).

Sembra che il mono farà cross-platform inclusa la GUI, ma solo se usi Windows Form.

c# windows cross-platform mac osx

posta Betty Crokker 15.06.2015 - 14:29

fonte

1 risposta

Leggi altre domande sui tag c# windows cross-platform mac osx

È possibile rappresentare la mutazione del grafico di un oggetto in modo efficiente con stati immutabili? È possibile fare una porta da un'applicazione C ++ a Java attraverso LLVM

score 10 · Accepted Answer

Xamarin non "indirizza" Windows, perché non ha senso - qualsiasi cosa tu scriva in C #, è pronto per essere eseguito su Windows in sé e per sé. Ecco perché vendono solo licenze per Xamarin.Android, Xamarin.iOS e Xamarin.Mac. Ma cosa dovrebbe fare un livello di astrazione di Xamarin.Windows? Quello sarebbe un prodotto a base di olio di serpente da manuale:)
"Applicazione nativa di Windows" - nativo è una parola difficile quando si tratta di C #. Le app in C # richiedono in genere il runtime .NET o Mono, creato o meno con Xamarin. Se desideri creare binari nativi anziché IL , esistono soluzioni come .NET Native o ngen , ma è una questione indipendente dall'uso di Xamarin. Non credo che tu intendessi "nativo" in questo senso stretto, ma è bene essere consapevoli di questa distinzione. Con C #, anche su Windows in genere usi una macchina virtuale di sorta.
Xamarin.Mac richiede il runtime Mono.OSX in modo che il codice C # possa essere creato del tutto. E collega il runtime Objective-C con Mono.OSX come descritto in Xamarin.Mac Internals :

There is the Objective-C based runtime containing instances of native classes (NSString, NSApplication, etc) and there is the C# runtime containing instances of managed classes (System.String, HttpClient, etc). In between these two works Xamarin.Mac creates a two way bridge so you can call methods (selectors) in Objective-C (such as NSApplication.Init) and Objective-C can call you back (like methods on your app delegate)

Quindi sì, l'applicazione risultante è "nativa" nel senso che non è, ad esempio, un pezzo di HTML avvolto in un componente WebView. Hai accesso agli elementi e alle API dell'interfaccia utente nativa. Non è nativo nel senso che richiede l'installazione di Mono.OSX. In altre parole, è nativo come C # su Windows che si trova in circostanze predefinite.
Potresti anche voler familiarizzare con link - potrebbe essere datato (2013), ma credo che le verità fondamentali siano credibili. Dai uno sguardo alla diapositiva # 7.
"Non posso dire che quel 25% di codice app che è specifico della piattaforma possa comportare" - per definizione, tutto ciò che non è indipendente dalla piattaforma, quindi, piuttosto molta logica di business "pura" e qualsiasi cosa tu astragga dalle implementazioni concrete (come alcune interfacce "IRepository" ecc.). Qualunque sia la piattaforma specifica però: l'interfaccia utente, la persistenza del database, le librerie di terze parti per Windows o Mac, non possono essere condivise. La proporzione 75/25 è molto semplice, il tuo chilometraggio può variare molto a seconda della natura della tua applicazione.

Nota che ho avuto solo un'esperienza non commerciale con Xamarin per piattaforme mobili, e non riguardava iOS (solo Windows Phone e Android). Se non sono preciso su ciò, per favore correggimi.