Very simply, a callback needn’t be asynchronous.
- Synchronous:If an API call is synchronous, it means that code execution will block (or wait) for the API call to return before continuing. This means that until a response is returned by the API, your application will not execute any further, which could be perceived by the user as latency or performance lag in your app. Making an API call synchronously can be beneficial, however, if there if code in your app that will only execute properly once the API response is received.
- Asynchronous:Asynchronous calls do not block (or wait) for the API call to return from the server. Execution continues on in your program, and when the call returns from the server, a “callback” function is executed.
In Java, C and C#, “callbacks” are usually synchronous (with respect to a “main event loop”).
PS: To answer your additional questions:
- Yes, callbacks may be invoked from a different thread – but it’s certainly not a requirement.
- Callbacks may also (and often do) spawn a thread (thus making themselves “asynchronous”).
‘Hope that helps
Q: @paulsm4 can you please elaborate with an example how the callback and asynchronous call works in the execution flow? That will be greatly helpful
- First we need to agree on a definition for “callback”. Here’s a good one:https://en.wikipedia.org/wiki/Callback_%28computer_programming%29In computer programming, a callback is a piece of executable code that is passed as an argument to other code, which is expected to call back (execute) the argument at some convenient time. The invocation may be immediate as in a synchronous callback, or it might happen at a later time as in an asynchronous callback.
- We must also define “synchronous” and “asynchronous”. Basically – if a callback does all it’s work before returning to the caller, it’s “synchronous”. If it can return to the caller immediately after it’s invoked – and the caller and the callback can work in parallel – then it’s “asynchronous”.
- The problem with synchronous callbacks is they can appear to “hang”. The problem with asynchronous callbacks is you can lose control of “ordering” – you can’t necessarily guarantee that “A” will occur before “B”.
- Common examples of callbacks include:a) a button press handler (each different “button” will have a different “response”). These are usually invoked “asynchronousy” (by the GUI’s main event loop).b) a sort “compare” function (so a common “sort()” function can handle different data types). These are usually invoked “synchronously” (called directly by your program).
- A CONCRETE EXAMPLE:a) I have a “C” language program with a “print()” function.b) “print()” is designed to use one of three callbacks: “PrintHP()”, “PrintCanon()” and “PrintPDF()”.c) “PrintPDF()” calls a library to render my data in PDF. It’s synchronous – the program doesn’t return back from “print()” until the .pdf rendering is complete. It usually goes pretty quickly, so there’s no problem.d) I’ve coded “PrintHP()” and “PrintCanon()” to spawn threads to do the I/O to the physical printer. “Print()” exits as soon as the thread is created; the actual “printing” goes on in parallel with program execution. These two callbacks are “asynchronous”.