Asynchronization in RTL

Im wondering how asynchronization works in RTL. Im using C# but I don’t have access to Task<>. Is there some sample to look at?

Can you elaborate? Task<T> should be available, as are the standard C# async/await paradigms.

public class Api
    {
        public static List<OsmPlace>> Search()
        {
            var testA = new OsmPlace("placeA", new Location(0,0));
            var testB = new OsmPlace("placeB", new Location(0,0));
            var testC = new OsmPlace("placeC", new Location(0,0));
            return new List<OsmPlace>() { testA, testB, testC };
        }
    }

I would like to call a web api from that method, so I need async, future - something like that


I can’t seem to import Task<>. And there is no System namespace.

But It could be because Im inside a Shared Project?

What platform are you on, .NET?

If you work in a shared project, you have to select a real “work in” project to get code completion, if thats what you are referring to. Right-click the File (or the project) in the Solution pane, and choose one of the projects that use this shared project under “Work In”. e.g.:

I intended to have a shared rtl based api. And compile it into java and cocoa platforms

Okay. there is indeed no System namespace on Java and Cocoa. If you want to use shared Apis across the two, I recommend using Elements RTL.

The best way to get started with a project would be to use the Multi-Target Library template, and then delete all the targets you dont need, leaving only Cooper (Java) and the Toffee (Cocoa) one(s) you need (eg macOS, iOS, tvOS and.or watchOS). You then have a project that can compile for Cocoa and Java, and no need for a “Shared” project.

gives you

right-click and re move the targets you dont need:

Ok. Ill try that

1 Like

Another question regarding this. Does multiplatform project mean I need to have a method each of the platforms in some cases, like asynchronies Task, Future, Promise etc

cocoaFetchAsync(), javaFetchAsync() - and compiling I would make it call the specific method via conditional compilation like:

#if cocoa
    cocoaFetchAsync()
#elif java
    javaFetchAsync()
#endif

?

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

Could you do an example showing how you use this ?

Sure:

typically, you’d subscribe to a broadcast, say in there constructor of a class. Here’s the Build Log view subscribing to two broadcasts that would affect its appearance:

BroadcastManager.subscribe(this) toBroadcast(Solution.NOTIFICATION_SOLUTION_BUILD_STATUS_CHANGED) block(buildStatusChanged) @object(_solution);
BroadcastManager.subscribe(this) toBroadcast(FCECodeEditorSettings.NOTIFICATION_CODE_EDITOR_SETTINGS_CHANGED) block(themeChanged) @object(FCECodeEditorSettings.sharedInstance);

when these broadcasts hit, the respective block gets called

        private void buildStatusChanged(Notification notification)
        {
                .. change color, etc

elsewhere, the class that — say — encapsulates the code editor settings, will trigger the broadcast when needed (eg when the user changes a settings in Preferences(

        internal static void triggerSettingChanged()
        {
            BroadcastManager.submitBroadcast(NOTIFICATION_CODE_EDITOR_SETTINGS_CHANGED) @object(sharedInstance);
        }

and when that broadcast is submitted, every subscriber across the process gets a callback. submitBroadcast can also take optional data in a dictionary, and it can force the callbacks to sync back to main, regardless from where it was called.

1 Like