Obiettivo C <-> Mono bridge

Question

Sto pensando di scrivere un'applicazione desktop multipiattaforma, inizialmente per Mac/Windows, ma alla fine anche per Linux.

Attualmente, ho intenzione di strutturare in questo modo:

• Mac UI utilizzando Cocoa/Objective C/Interface Builder
• interfaccia utente di Windows utilizzando WPF
• In futuro, Linux UI utilizzando GTK #
• Livello di accesso business/dati in C#, ad esempio .NET su Windows, Mono su Mac/Linux

Questo ovviamente andrà bene su Windows, sono p sono sicuro che andrà bene su Linux/Gnome basato sulle app GTK # che ho visto. Chiamando in Mono su Mac, ma ... immagino che ho queste opzioni:

• ObjC#
• Dumbarton (sguardi un po morti)
• Monobjc (ciò significherebbe scrivere il Mac interfaccia utente in C# invece di Objective C - non così appassionato di questo)

La mia domanda: qualcuno ha mai avuto esperienza nello sviluppo di app in modo simile? Qualche consiglio? Sono pazzo?

FYI - Sono abbastanza esigente sul desktop di interfacce utente di essere "in uno" con i loro sistemi operativi host, quindi io non sono interessato a WinForms/soluzioni goffo Java/QT ...

Answer 1

Se qualcuno inciampa su questo ...

MonoMac sembra che sarà il modo più ovvio in avanti.

Answer 2

Per quello che vale la pena, sto venendo dal lato Mac qui., ma penso che i miei commenti siano universalmente applicabili.

Dato il desiderio dichiarato di scrivere applicazioni con l'interfaccia utente specifica della piattaforma, penso che ObjC# sia l'unica scelta ragionevole. Ci sono una gran quantità di risorse sull'implementazione delle interfacce utente lato Mac in Objective-C; Penso che sarebbe uno spreco di tempo per cercare di tradurre tutti i consigli che trovi su Monobjc, specialmente quando ti imbatti in un'API che ti chiede di raggirare alcuni puntatori e passare un handle di funzione e oh no, cosa fai ora? . L'unica cosa che è può condividere tra le applicazioni è il codice del modello; Ho postulato che non vi è alcun motivo per cercare di mantenere le cose nella stessa lingua sul lato della presentazione a meno che non si pensi di non poter o non si sarà in grado di familiarizzare con Objective-C.

Answer 3

Ho lavorato a un'applicazione desktop Mac desktop per 2 anni scritta in C#. Abbiamo una libreria scritta in Objective C, con le funzioni C semplici esposte. Il nostro codice C# PInvince le semplici funzioni C.

In origine, l'applicazione utilizzava MonobjC, tuttavia, MonobjC si dimostrava troppo complicato con cui lavorare. Molte API Mac non si traducono molto bene in C#, oppure devi essere un esperto di semantica Objective C e MonobjC per fare una semplice chiamata di funzione. Il sistema di passaggio dei messaggi di Objective C non sempre si traduce in una chiamata al metodo C#.

Quando ho valutato MonoMac, era meno maturo di MonobjC.Non ho avuto l'impressione che abbia apportato alcun miglioramento reale rispetto a MonobjC, tranne per rimanere coerente con lo stile e i modelli di MonoTouch.

Pertanto, raccomando vivamente di utilizzare una qualche forma di PInvoking nell'Obiettivo C da C#, o seguendo la guida Mono di incorporamento. http://www.mono-project.com/Embedding_Mono

Answer 4

Dai uno sguardo allo Dubrovnik. Questa è una versione aggiornata di Dumbarton che include un generatore di codice.

Il generatore di codice riduce notevolmente la necessità di codificare direttamente l'API incorporata. Basta puntare il generatore sugli assiemi gestiti e integrare l'output Obj-C nel progetto.