That depends on the APIs you use. for platform-specific APIs, yes. for stuff encapsulated already in Elements RTL, you wont need this. Also for stuff that isn’t encapsulated yet but available on all platforms (just slightly differently) you could either ask us to expand Elements RTL, or just create a wrapper yourself, eg in one place you could define
void mySync(...) {
#if cocoa
cocoaFetchAsync(...)
#elif java
javaFetchAsync(...)
#endif
}
and then in the dozens of places you need this, Warner than #ifdef’ing everywhere, you can just sue mySync().
for example, for Fire/Water I have ba class called SBLDispatch that as a whole bunch of methods to dispatching calls to background threads or the main thread on different ways, and uses Cocoa or .NET/WPF-specific calls under the hood. That way, I dont have too think abut platform differences when working on “app logic” code.
SBLDispatch itself is pretty specific to Fire/Water, but I could share it for reference.
Another class to look at is BroadcastManager in Elements RTL. It uses Cocoa NSNotification and custom logic on all other platforms to provide a broadcast/callback mechanism. Fire/Water use that extensively, as well.
hth,
marc