To share/ re-use source code between platforms, we can user Sugar on Oxygene. Another way, we can use PCL on Xamarin.
Should I choose Sugar or PCL?
What are strong/weak points if I compare Sugar vs PCL?
Thanks!
Remobjects takes a different approach to Xamarin.
Xamarin is about making .Net run everywhere so you code against the .Net libraries using .Net style events etc regardless of the platform. This can lead to some awkward abstractions and esoteric gotchas (for example the possibility of retain cycles where GC and ARC collide on Cocoa).
Remobjects is about making the languages cross platform not the API. So on .Net you use the .Net API and on Cocoa you’d use the Cocoa API. Sugar is a library which provides a consistent thin wrapper around some of the platform differences - such as arrays, dictionaries etc. You would build different libraries for each platform - but hopefully sugar would help you share much of the business logic.
With a PCL you could use the same built library in all your projects as it all uses .Net. You can only use a PCL in either VS or Xamarin. You can use a built Remobjects library in the platform’s native tools (for example Xcode) as well as Remobjects’.
1 Like
Hi Steveflack,
Thank you so much for your answer!
PMFJI - @steve - The RemObjects approach has it’s own awkwardness and gotchas w.r.t code sharing, at a far more fundamental level. i.e. the ability to share code/assets at all.
Please see my recent post referring to “Code Sharing Projects” for my frustrations. Hopefully you might have some suggestions/insights to share that have eluded me to this point.
I’ve done much the same as you - same files in multiple projects and it’s a poor solution TBH. It’s the same solution Xamarin had to use until a few months back. I would not be surprised if Shared Code Projects were created by Microsoft just for them.
I don’t think it was created specifically for Xamarin (Portable Class Library projects already addressed much of this problem for .NET or Mono projects alike, as I understand it). The community response to the delivery of Shared Code Projects suggests that it came as a welcome relief for many C# developers targeting “Universal” Windows Store apps, Xamarin or no.
It is also worth noting that shared code projects were apparently achievable before the Shared Code Project type arrived, but required hacking around in the MS Build project files - messy to say the least. And I suspect that this in itself was only possible because of the types of project that the MS C# Project System implemented. The Project System architecture is hugely powerful in many respects, but also hugely limiting in that your ability to structure and organise projects seems heavily dependent upon the restrictions and expectations imposed by the Project System implementation for the projects you are dealing with.
I have tried hacking around in Oxygene project files, modelling the hacks on those required for code sharing in MS C# projects, but I cannot get it to work (projects simply become unloadable).
But even if it was created “just for Xamarin”, I don’t see how that is an excuse for not meeting the same need for Elements developers, for whom the need is arguably greater (given that portable libraries are not an option for us)