Hi,
How can I write a library that can be reused under Windows, Android and iOS?
Is there a tutorial already written about this?
Regards,
Mike Ribbons
If you value your sanity I’d suggest looking at the Sugar library as a good point to build your cross platform code around.
Other than that you should try and tease apart your UI code from the logic of your app. I have common cross platform code behind my UIViewControllers/Fragments/whatever that UI code calls into if say a button is clicked.
I actually don’t have a library BTW. My shared code is compiled into each app.
Hi Steve,
Thanks for your replies.
It looks like Sugar requires Oxygene - That makes RemObjects a less palatable solution as when you add the cost it’s the same as a business license for one platform on Xamarin. Not to mention the fact that everything else has to be coded from scratch as there is no .Net framework backing everything.
Compiling shared code directly into each app also sounds less than ideal. Static linking would make sense, but having a separate version of business logic sitting in multiple projects sounds like a nightmare.
Is there no way to write a C# library that can be referenced in other RemObjects projects?
If not, this is something the RemObject guys really should look at. It would put RO on par with Xamarin.
Regards,
Mike Ribbons
It might require Oxygene to build but it should come as part of your C# install ?
Have you looked at add new projects ? You should be able to create static/class libaries for each platform and then add them as a reference to each platforms application.
Hi John,
What I want to achieve is code sharing across platforms.
What your describing sounds like separate libraries for each platform?
Regards,
Mike Ribbons
It looks like Sugar requires Oxygene
It does require Oxygene to build it but it comes precompiled in both Oxygene/C# - you don’t need Oxygene to consume the library.
That makes RemObjects a less palatable solution as when you add the cost it’s the same as a business license for one platform on Xamarin.
That’s one business license for one platform. The RemObjects licenses are for all platforms so you only need one. I presume since you’re asking about cross-platform you would need more than one Xamarin license.
Not to mention the fact that everything else has to be coded from scratch as there is no .Net framework backing everything.
I have used both Xamarin and RemObjects (I even have a Xamarin license) but I chose to use RemObjects in the end. I think it depends where you’re coming from. If you’re a .Net programmer then using the frameworks you know well definitely has a strong attraction. It does add a lot more moving parts though and more to go wrong. I’ve actually converted all my cross platform Xamarin code to Oxygene and apart from the language differences there wasn’t much more coding from scratch. The only thing I needed to write was a couple of classes to parse JSON (which use mapped classes onto the iOS/Android built in classes).
I do agree however that being able to have one project with your common code in it would be an improvement - even if it’s just included somehow. I don’t know if the Shared Code Project stuff Microsoft announced at build will help here.
Steve,
Shared Projects looks like what I’m after.
I’ll give it a try and come back.
I don’t know if it actually works with Oxygene/RemObjects C# so I’d be interested to see what you find.
No go on Shared Projects.
When I try to add the shared project references, VS says
"Unfortunately, the Shared Project Manager is only available for standard C#, C++ and Javascript projects."
Maybe they will open it up down the track…
I tried to get fancy in Visual Studio to manage multiple targets all within the same oxygene project file, but in the end, the enclosing solution broke in almost every attempt (RemObjects C# would likely have similar issues). Consequently, I have a master project for my .net project where I use #ifdefs to differentiate between platforms. I use X-Unit to unit-test my library. I use TFS in the cloud to version all of my sources. When my unit-tests test out under Windows, I copy and paste the latest sources into the project files for my other two targets [iOS and OSX]. I also have entire files within each platform implementation that differ by platform: these files stay distinct. My #ifdef’ed code can be diff’ed using TFS compare either repository-to-repository or file-to-file [the TFS-popup dialog allows you to compare by typing stuff straight into the dialog for projectA\file-1.pas to projectB\file-1.pas. this turns out actually to be somewhat efficient as I can focus on one build target at a time and merge platform differences when it’s convenient (but I don’t allow them to get too far out-of-sync prior to re-syncing). I find my current setup, while not ideal, workable.
Share dProjects in VS2013 are a feature of the Visual C# language integration, not a general VS feature that Oxygene can use. That said — it;'s really no different than just adding the same source file to all three projects, is it?
Can you elaborate on how/what broke, exactly? I’d love to get that fixed.
I wouldn’t say that this is a bug in the oxygene solution. Rather, Visual Studio (VS) has two basic design flaws for platform-portable code:
- VS doesn’t really support more than one project sharing the same directory. You can hack it to almost work; it works at first and then eventually breaks after you add certain target-speciific settings. Everytime I tried this, the hacked solution would crash VS when re-opened.
- VS won’t add references to files in a relative location (e.g. …/shared/whatever). Because when you add the file, it copies the file into the project folder. I considered adding hard-links to my share source files, but I thought that TFS might flake out on hard-links, so I elected to do things its way [the VS way].
So eventually, I settled on the way described in my earlier post:
In summary, this is not an Oxygene/Elements bug. Instead it is a deficiency in the overall design of Visual Studio.
1): It does support it, but unfortunately the New Project dialog doesn’t let you do it at all, which is fairly annoying. What I do is create a new project anywhere and copy the Oxygene/Hydrogene file in the directory it was already in.
2: In the “Add Existing File” dialog, you’ll find a small triangle next to the “Add” button, if you click it and use Add As Link it will create a relative filename.
- I used your same trick to get solutions into a common directory, but since some artifacts of the solution are shared among the various projects, this hack is fragile and eventually breaks.
- I have been using Visual Studio since the original NT beta [forever]. But I never noticed “the small triangle” … THANKS !!!
These works quite well btw, and will end up with the cleanest directories:
Requirements
- A recent RemObjects C#
- A Mac
- The Java SDK
- Visual Studio
Step one: .NET
- Create a new RemObjects C# for .NET project, make sure to select Solution in it’s own folder
- Add a reference to Sugar
- Add the code to be shared to the source file
Step two: Move the source in a directory
- Create a new “Source” directory in your solution folder and move the cs file
- Remove and re-add it to the project as a link
Step three: Java
- Add a new RemObjects C# for Java project to the existing solution
- Add a reference to Sugar
- Add the cs file as a link
Step four: Compile
- Compile
- Notice things that need changing, the using list and “string” needs to become “String”.
Step five: Cocoa
- Add a new RemObjects C# for Cocoa project to the existing solution
- Add a reference to Sugar
- Add the cs file as a link
Step six: Compile
- Compile
- Switch to the OSX project
- Correct the error: Add the elif for Nougat
Step seven: Compile again
- Compile
- Done
1 Like