-3

So we are currently working on an app in java and a colleague introduced me to asynchronous programming and it doesn't matter how much I research it, to me it seems that is synchronous. So the main advantage of asynchronous code appears to be the non freezing of the UI while some action takes long time to be performed and get us the result back, all we need to do is give that function a callback function which is going to be called when the job is done. From what I have understood from online sources and similar questions on stackoverflow is that the code can be single threaded and async, someone even drew it like this:

Asynchronous (one thread)(credit: Asynchronous vs synchronous execution, what does it really mean?):

     A-Start ------------------------------------------ A-End   
       | B-Start -----------------------------------------|--- B-End   
       |    |      C-Start ------------------- C-End      |      |   
       |    |       |                           |         |      |
       V    V       V                           V         V      V      
1 thread->|<-A-|<--B---|<-C-|-A-|-C-|--A--|-B-|--C-->|---A---->|--B-->|

so from what I understand the single threaded asynchronous code is still synchronous but it gives every task a little bit of time and if there is much to do the async code basically says call me back when the job is done, ok but if we only have one thread who is going to do the job while you give the resources to the other code?

to show you the Problem lets look at the example from our project:

 public void getAllExercises(RequestListener<List<Exercise>> listener) {
        getAllExercisesRequest().getAsObjectList(Exercise.class, listener);
    }

usage of that method: when the user clicks a button to see all exercises, this method is called and what it does is that it gets all exercises from server, here is an example of usage:

class sometingAdapter extends something{

someMethod(param){
         .
         . 
         .  
    //some code before the Method call 
    DBClient.getstandardDBClient().getAllExercises(new RequestListener<List<Exercise>>() {
                @Override
                public void onResponse(List<Exercise> response) {
                    arrayAdapter.addAll(response);
                    arrayAdapter.notifyDataSetChanged();
                }
            });
    
            //some additional code 
            return v;
        }-> end of the method

}

The claim is that now while the Method is fetching the data from server, our UI is not blocked, and other actions can be performed, but how ? when the code execution comes to the line DBClient.getStandardDBClient().getAllExercises then the method getAllExercises gets called the execution jumps into the method. Inside that method a Request is built and getAsObject(MyClass.class, listener) method is called (I dont know how getAsObject() method works, its from FAN API),

but where in all of this do we or the system tells the code, listen you can go back and do your stuff and when I have the data (the response) I will call you back with the onResponse() method from the listener that you passed as argument

and who does the job of fetching the data we only have one thread, there are no magical resources that fetch the data while our thread is busy executing other code? and how does the system know where to jump back while the other code is running? its not like system is like "oh he's doing it async I will magically jump around"

so after this magic happens there is one more stuff that confuses me, while the call to getAllExercises is still active when the further execution of the code reaches the return v statement isn't it so that the function call gets removed from stack, which would further mean that the execution of getAllExercise method would be interrupted ? which further means that the fetching would also be interrupted etc. basically it would cause a chain reaction and the onResponse() method would never be called or would it ?

What does make the code async, is it only passing a callback method i.e object whose method is used as callback? if so, how is that not blocking the UI, if I call a method and pass this method another method then the execution of the code will be inside of the Method, until the method that is passed is called, then the execution of that code will start so there is still a blockage of UI there is no magical jumping around and doing work in the background, what am I missing ?

                           void Method1(Method2);

                                    |Start 
                                    |call Method1------------>|
                                    |                         |                         
                                    | Blocked??               |Execution of Method 1
                                    |                         |
                                    | <-----------------------|
                                    |    callback Method2
                                    | continued execution 
                                    | 
                                    |
                                    |End

So where does the magic happen where the blocked part becomes unblocked? and the execution of method1 and the rest are happening simultaneously?

My understanding is that somehow following happens:

                              void Method1(Method2);

                                    |Start 
                                    |call Method1------------------>|
  continues execution of main thread|<------------------------------|                         
                                    |(okay thanks for the Method    |Execution of Method 1
                                    |I will call you when I am done)|but what resource is executing 
                                    | <---------------------------- |Method 1????
                                    |    callback Method2: Iam done 
                                    | ------------------------------>|execution of method 2 
                                    |  Blocked                       |very quick not noticable 
                                    |<-------------------------------
                                    |continued execution
                                    |End
user12394078
  • 63
  • 6
  • ok, I got it from here:https://stackoverflow.com/questions/748175/asynchronous-vs-synchronous-execution-what-does-it-really-mean – user12394078 Dec 01 '20 at 17:10
  • 1
    Does this answer your question? [Asynchronous vs synchronous execution, what does it really mean?](https://stackoverflow.com/questions/748175/asynchronous-vs-synchronous-execution-what-does-it-really-mean) – Toerktumlare Dec 01 '20 at 17:10
  • no unfortunately not – user12394078 Dec 01 '20 at 17:11
  • 1
    then update what it doesn't answer. – Toerktumlare Dec 01 '20 at 17:12
  • also, what says that the implementation of `RequestListener` isn't threaded? since you have not provided the implementation for it. Also in your first example you claim that a single thread is async, well a single thread is never async. What you have drawn out in your first picture is a single thread performing synchronous precessing by switching work on multiple different tasks. – Toerktumlare Dec 01 '20 at 17:19
  • @Toerktmulare I call a method, method does work, while method is doing work the main thread does work also, but we only have one thread ? How ? How does the system know where to jump back because the method is still working, how does it know where to jump back and continue execution of other code on main thread? how does the system interrups execution of the main thread code when the callback funtion is called ??????? – user12394078 Dec 01 '20 at 17:20
  • provide a working example that we can run, and we can explain. Voted to close. – Toerktumlare Dec 01 '20 at 17:22
  • "also, what says that the implementation of RequestListener isn't threaded? since you have not provided the implementation for it. Also in your first example you claim that a single thread is async, well a single thread is never async. What you have drawn out in your first picture is a single thread performing synchronous behaviour precessing small bits at a time of multiple different tasks." again i got the explanation from here https://stackoverflow.com/questions/748175/asynchronous-vs-synchronous-execution-what-does-it-really-mean – user12394078 Dec 01 '20 at 17:23
  • @user12394078 This is all what an *operating system* does. Research how a program actually exists in memory and how a CPU actually executes a program. Then check out the role of multithreading in that. – akuzminykh Dec 01 '20 at 17:25
  • @akuzminykh so based upon on how code is written OS can recognize stuff and execute it asynchronously? so the key to async code is providing callback methods ? that all to it? – user12394078 Dec 01 '20 at 17:32

1 Answers1

1

Generally in Java, if you do not want to have your UI blocking, you will have to run complex tasks on another thread. Without knowing this "FAN API" I can almost certainly say, that getAsObjectList(...) is starting this second thread.

This method will return without noticeable delay, and allow the current thread to proceed, i. e. prevent the UI from blocking. Instead of initiating the request synchronously, it starts a new thread (or rather takes a thread from a thread pool) and uses it to send and await the request. When receiving the response it will call your RequestListener from this thread (or possibly yet another). That is to say, it will not use the thread, that called getAsObjectList(...) to run the RequestListener, since that thread has returned from getAsObjectList(...) a long time ago and cannot be "controlled" anymore.¹ Particularly there will not be some "magic" freely interrupting the thread at any random point of continued execution and forcefully stuffing the execution of the RequestListener into its control flow.

¹: If getAllExercises(...) was called from some thread, that is part of a thread pool/some event queue based concurrency framework (possibly part of the UI framework), it in fact is possible, that this thread will intentionally (or even just accidentally) be reused to call the RequestListener. See, for example JavaScript's concurrency model, where all the (client) code is only ever run in a single thread, while still allowing/encouraging/enforcing asynchronicity. However, this will still not happen, before your client code around the call of getAsObjectList(...) was smoothly executed. Only after that execution finished, and the thread has returned to some resting state in its pool, waiting for some more tasks to run, it can be selected as the thread to now call the RequestListener on.

Reizo
  • 1,374
  • 12
  • 17
  • https://amitshekhar.me/Fast-Android-Networking/ -> this is the API , "Generally in Java, if you do not want to have your UI blocking, you will have to run complex tasks on another thread." suppose that getAsObject doesn't do this, just by providing a callback function will not make the code asynchronous? the Problem that we were getting was `NetworkOnMainThreadException` and just by adding a listener solved it, explanation being that the code is now asynchronous, but I just failed to se how? – user12394078 Dec 01 '20 at 21:21
  • 1
    "suppose that getAsObject doesn't do this", what do you mean by "this", the thing I described (i. e. issuing the request to another thread and immediately returning)? Well there is not an option it "does't do this". The asynchrousicity needs to be initiate at some place and since you don't do it manually, it's the API doing it _internally_ (that's why you don's see it). The callback is not by itself inducing any asyncroucity, after all it's just some "dull" object instance. The way its `onResponse`-method is called is what's making the difference. – Reizo Dec 01 '20 at 22:23
  • 1
    As a tip: Add some `System.out.println(Thread.currentThread() + " " + System.getCurrentTimeMillis() + " )` in your code and observe. – Reizo Dec 01 '20 at 22:26
  • 1
    As for the `NetworkOnMainThreadException`: This indicates, the FAN API has skme understanding of what a "main"-Thread is and how to identify such. There may be some standardized threads/thread groups in android, which the API checks - I am not an expert on Android. A "regular" (meaning non-Android) Java library is oblivious of the surrounding threading framework (as long as it does no support some form of integration), since there possibly even isn't any. – Reizo Dec 01 '20 at 22:35
  • "_The callback is not by itself inducing any asyncroucity, after all it's just some "dull" object instance. The way its onResponse-method is called is what's making the difference_" this is what I needed, thank you very much. I was starting to question everything I know about code execution. I also think that it is the internal implementation of the `getAsObject()` that is making the code async it's the only possible explanation. – user12394078 Dec 01 '20 at 23:27