The runNow method here has the documentation:
/**
* Executes this callback, on the current thread, right now, blocking until complete.
*
* In most cases, this type is passed to scalajs-react such that you don't need to call this method yourself.
*
* Exceptions will not be caught. Use [[attempt]] to catch thrown exceptions.
*/
This is a little bit vague and leads to four questions:
when I am not supposed to call runNow() ? why ?
is it so that the only situation when I should not (or don't have to) call runNow() is when I am using a Callback with ==> or --> (as described here) ? (my guess that this is true) or is there any other situation when runNow() is called for me by the framework ?
when I am allowed to call runNow()? why ?
why not just use runNow all the time ? would that cause any problems ? if yes, what ?
My current understanding is that it is ok (and even needed) to call runNow() from a scala-function that has been passed as a callback to a wrapped native JS react component. For example here.
I am not sure however.
Can someone clarify when it is OK and when it is not OK to call runNow() ?
I'll provide a more detailed answer tomorrow but first, have you read through the Callback docs? https://github.com/japgolly/scalajs-react/blob/master/doc/CALLBACK.md
Related
I was wondering if there is some way to provide two methods to Micronaut which are guaranteed to run before and after a request was passed to the handler.
In my case, this would be to initialize some thread-local data.
I know this would also be possible to put in the handler itself but putting the same lines of code in every handler isn't really the greatest solution.
Use a filter - see the docs at https://docs.micronaut.io/latest/guide/#filters
If I have a function call that returns true or false as the condition of an if statement, do I have to worry about Swift forking my code for efficiency?
For example,
if (resourceIsAvailable()) { //execute code }
If checking for the resource is computationally expensive, will Xcode wait or attempt to continue on with the code?
Is this worth using a completion handler?
What if the resource check must make a database call?
Good question.
First off... can a function be used? Absolutely.
Second... should it be used?
A lot of that depends on the implementation of the function. If the function is known (to the person who wrote it) to take a long time to complete then I would expect that person to deal with that accordingly.
Thankfully with a lot of iOS things like that are taken out of the hands of the developer (mostly). CoreData and Network requests normally come with a completion handler. So any function that uses them would also need to be async and have a completion handler.
There is no fixed rule for this. My best advice would be...
If you can see the implementation of the function then try to work out what it’s doing.
If you can’t then give it a go. You could even use the time profiler in Xcode profiler to determine how long it is taking to complete.
The worst that could happen is you find it is slow and then change it for something else.
In the past, I have used libraries that would allow me to register a callback so that the library can call my method when some event happens (e.g. it is common to see in code that use GUI libraries to look like button.onClick(clickHandler)).
Naively, I suppose the library's handling mechanism could be implemented like:
while(1){
if (event1) { event1Handler(); }
if (event2) { event2Handler(); }
...
}
but that would be really wasteful right? Or is that really how it is done (for instance do well known GUI libraries like java swing, or GTK+ do it this way)?
background:
This question hadn't really occured to me until I encountered curses. I thought about implementing my own callback system, until I realized I didn't know how.
The while loop will typically wait for an interrupt from the user (GetMessage in Windows). When an interrupt arrives GetMessage returns and then it ends up in the callback function. The if statements are typically implemented as a switch-case. See Windows Message Loop on Wikipedia.
In more detail, what happens is the following:
The user application calls GetMessage, which forces the process to sleep until an input message for that application arrives from the systems queue. When a message arrives, the user app calls DispatchMessage, which calls the callback function associated with the window that the message was aimed at.
Windows API uses one callback which handles all events in a switch case. Other libraries use one callback per event class instead.
The function pointers themselves are stored together with other window data in a struct.
Callback system implementation probably has different implementation in different technologies, however, I suppose they should be working this way:
A data structure stores the callback IDs and pointers to the handlers.
A callback handler has a validator
Event handlers have callback callers, which know what are the possible callbacks and check their validity this way:
for each callback in event.callbacks
if (callback.isValid())
call callback()
end if
end for
When you add a handler to a function the system will automatically know where the callback is valid and will add the callback to the datastructure described in 1.
Correct me if I'm wrong, this description is just a guess.
Is it a function?
Is it a function being called from the source?
Or, is it a function being returned from the destination?
Or, is it just executing a function at the destination?
Or, is it a value returned from a function passed to the destination?
A callback is the building block of asynchronous processing.
Think of it this way: when you call someone and they don't answer, you leave a message and your phone number. Later on, the person calls you back based on the phone number you left.
A callback works in a similar manner.
You ask an API for a long running operation and you provide a method from within your code to be called with the result of the operation. The API does its work and when the result is ready, it calls your callback method.
From the great Wikipedia:
In computer programming, a callback is
executable code that is passed as an
argument to other code. It allows a
lower-level software layer to call a
subroutine (or function) defined in a
higher-level layer.
Said another way, when you pass a callback to your method, it's as if you are providing additional instructions (e.g., what you should do next). An attempt at making a simple human example follows:
Paint this wall this shade of green (where "paint" is analagous to the method called, while "wall" and "green" are similar to arguments).
When you have finished painting, call me at this number to let me know that you're done and I'll tell you what to do next.
In terms of practical applications, one place where you will sometimes see callbacks is in situations with asynchronous message passing. You might want to register a particular message as an item of interest for class B.
However, without something like a callback, there's no obvious way for class A to know that class B has received the message. With a callback, you can tell class B, here's the message that I want you to listen for and this is the method in class A that I want you to call when you receive it.
Here is a Java example of a callback from a related question.
I am cleaning up the DataReaders in an old .NET 1.1 project that I inherited.
The previous developer coded the data-access-layer in such a way that most of the DAL methods returned SqlDataReaders (thus leaving it up to the caller to properly call the .Close() or .Dispose() methods).
I have come across a situation, though, where a caller is not catching the returned SqlDataReader (and therefore is not disposing of it properly). See the code below:
Data Access Method:
Public Shared Function UpdateData() As SqlDataReader
...
drSQL = cmdSQL.ExecuteReader(CommandBehavior.CloseConnection)
Return drSQL
End Function
Calling code:
...
DataAccessLayer.UpdateData()
...
As you can see, the calling method does not receive/catch the returned SqlDataReader. So what happens? Is that SqlDataReader still out there and open? Or does it automatically get garbage collected since nothing is addressing it?
I couldn't think of a way to debug and test this. If anybody has any ideas or suggestions that would be great.
i believe that it will get closed but not until the garbage-collector gets 'round to it, which may not be for a very long time...