I am currently working on a cross-platform app using RemObjects Elements with a shared codebase targeting both .NET and Island (Windows/Linux). I am trying to structure a shared data access layer or data module that works cleanly across platforms without duplicating logic.
My goal is to keep the backend logic as unified as possible — ideally in a shared project. However.., I am running into issues with certain APIs that are not available or behave differently between .NET and Island.
Has anyone here implemented a similar pattern successfully: ?? Should I abstract the platform-specific parts into interfaces and inject them: ?? Or is there a better practice within Elements to manage this kind of architecture: ??
What i do for Fire/Water is a micture of two things.
(a) for classes that have some (usually a lot) of shared code but some platform sp[eciifc code (usually, these are clases representing a view or window), i split the code in three parts (usually via three separate files, with a partial) class.
MyClass.pas
MyClass.Cocoa.pas
MyClass.WPF.pas
there the latter two files have a $IFDEF around the entire file. MyClass.pas gets all the core implementatin of the logic etc. the per-platform files have code code thats speciifc to that platform. Sometimes that’s methods of the same name, so rhe main file can just call them on both platforms – ut they do sliggtly different things; sometimes that’s platform-specific event handlers (eg methods that react to action froma. Cocoa or WPF control, etc).
Obviously i try to keep as much as possible in the shared main code. If there is very little per-platform code, I sometimes just $IFDEF it within the main file; but i try not to.
Pretty muc all of Fire/Water’s UI code looks like this, and it usually super easy for me to implement (od change) view for both platforms at the same time.
(b) for classes that are totally different on each platform, or wrap platform logic, i often just declare the same class with the same public API – but different implementationsm – for each platfom. Or i might use a n ative clas son one platform, and declare a class that “mocks” it for the other.
Example for scenario one, i have a SBLClipboardAccess class for eaxh oplatform that lest be do basic stuff like setting or getting the clipboard contents.
For scenario two: i used NSAttributedString a lot, a Cocoa-native class so for WPF i just created a new class that looks like NSAttributedString (and is called the same), but does whatever is neded on WPF to handle and manipulateb a formatted string, under the hood.
You could exted the same logic for any eg hardware specifc access (eg acess the camera or GPS location on iPhone vs Android), or whatnot.
There’s a couple blog posts from while back thayt cover this, let me find them.