This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
I never went beyond returning Task.FromResult(computedValue) in my asynchronous programming.
I was wondering if it is possible to return a Task even when computedValue is yet to be determined from another pending Task as illustrated below.
THE EASY ONE:
public Task<bool> IsFileNameExists(string fileName)
{
bool isFileExists = CheckIfFileNameExists(fileName);
return Task.FromResult(isFileExits );
}
THE NOT EASY:
public Task<bool> IsFileNameExists(string fileName)
{
var objectResult = Database.Table<DataEntriesModel>().Where(x => x.FileName == fileName).FirstOrDefault(); // this is returning Task
// What I want to return is CompletedTask result is not null.
// I cannot use the following because objectResult is a pending, and pending Task is not null even if completed task is null
// and objectResult != null will always be true.
return Task.FromResult(objectResult != null);
}
Yes, I can make the method async Task<bool> and return an awaited result.
I just wondered if Task<bool> can still be returned when the <bool> evaluation is dependent on a pending Task.
Can this be done and how?
Check if this works:
public Task<bool> IsFileNameExists(string fileName)
{
return Task.Run( () => Database.Table<DataEntriesModel>().Where(x => x.FileName == fileName).FirstOrDefault() != null);
}
You can do the waiting in the caller if you really want to but I don't know that I'd recommend that approach. But honestly your method isn't doing anything that needs additional work so there shouldn't be any awaiting needed at all.
public async Task<bool> IsFileNameExists(string fileName)
{
var objectResult = await Database.Table<DataEntriesModel>().Where(x => x.FileName == fileName).FirstOrDefault(); // this is returning Task
return objectResult != null;
}
But if you wanted to do this in the caller then you'd do something like this.
bool result = Database.Table<...>.Where().FirstOrDefault()
.ContinueWith(x => x != null);
But the problem I'm having is that neither Where nor FirstOrDefault are async. Therefore I don't see where in this line of code you are actually using async logic. If Table<> where to return an async object then the Where call would be invalid. Hence your first line of code is actually just synchronous.
Hi @Michael Taylor ,
May be I didn't make this clear and just looking at the code can be confusing. I tried to simplify the original code and lost clarity in the process although I stated with a comment the long statement returns a Task.
The key point is that Database.Table<...> is asynchronous and for clarity/consistency I should have used FirstOrDefaultAsync() which indeed is the case in the original code. I said the equivalent with a comment.
I got into this situation simply to keep uniformity of my CRUD methods which are all returningTask except a few of them. I just thought there may be a way to deal with a pending Task as shown.
Continuations are how you handle work post pending task. Using await is the easiest but ContinueWith is the same thing as that is all await does.
I don't understand what problem you're trying to solve that await or ContinueWith doesn't already handle. Both code samples I posted handle the "pending task" thing that you mention. They take the object that is eventually returned by your DB call and return a boolean result from it. Perhaps you can provide a concrete example if that doesn't address your concern.
Your code queries a collection of Tasks and returns the first task in the sequence?
var objectResult = Database.Table<DataEntriesModel>().Where(x => x.FileName == fileName).FirstOrDefault(); // this is returning Task
If this is true, which I kinda' doubt, then the syntax to get the result is Task.Wait(). It would help the community greatly if you showed the actual type rather than using var. Then we could see the actual type which will clarify things a bit. Click on the line, Visual Studio will display a help icon where you can select the option, "Use explicit type rather than var".
objectResult.Wait()
The Task.FromResult() method is a way to short cut a result rather than needing to execute a task process. The reference documentation has a code example that illustrate this pattern.
Task.FromResult<TResult>(TResult) Method
Therefore, your first code snippet can be refactored as below if the intent is to return a bool.
public bool IsFileNameExists(string fileName)
{
return CheckIfFileNameExists(fileName);
}
If you can provide complete code, then I think we can help you understand how to use Task<T> and async/await.
Hi @Michael Taylor ,
It is not for lack of a workaround; I can solve using async and await as follows, and perhaps this makes it clear:
THE FOLLOWING WORKS:
public async Task<bool> IsFileNameExists(string fileName)
{
return await Database.Table<InfoFolder>().Where(x => x.FileName == fileName).FirstOrDefaultAsync() != null;
}
It works because the pending Task is completed due to await and the resulting object or a possible null value is compared to null. But, what I don't yet know is what it takes to compare a pending Task, essentially if at all possible to effect a delayed comparison when the pending Task is completed -- am I asking the impossible here?
It's because I'm assuming there may be clever ways of async programming which I haven't yet mastered, in this specific case returning a Task that works as expected.
My question, therefore, is, can you do the equivalent of the above without the async and await, that is, return Task<bool> and let the caller use the await?
PS: As I mentioned in my previous comment, for better clarity, I should have used FirstOrDefaultAsync() from the outset.
Use the Task.Wait() method to wait for a task to complete.
MyTask.Wait()
var results = MyTask.Result;
My question, therefore, is, can you do the equivalent of the above without the async and await, that is, return Task<bool> and let the caller use the await?
Not really. I'm not sure you actually understand what a task really is so I think you're mixing terminology. A Task is a promise that some work will eventually get done. There is no such thing as pending nor can you use a task to return a value unless the code within that task returns the value. What you're effectively ask for, I think, is the ability to return Task<bool> and yet you don't want the actual underlying work to return a bool but rather some DB value and then have the client figure out whether it is null or not. That doesn't make sense to me but is doable, albeit with changing the names. To be honest that code would look exactly like what you already have (awaiting on an async method and then returning a boolean result. Your IsFileNameExists is doing what you are asking if you can do, I think.
If you don't want to use await then the code I posted with ContinueWith does the exact same thing. Where you await/ContinueWith in your code is completely irrelevant. It could be in the function you posted or some higher level code that calls your function. It doesn't matter. All Async methods do is return Task. What you do with the Task (whether it is done yet or not) is completely up to you.
Example:
public Task<InfoFolder> GetInfoFolderAsync ( string filename )
{
return Database.Table<InfoFolder>().Where(x => x.FileName == fileName).FirstOrDefaultAsync();
}
//Can do this in a helper function or in higher level code, doesn't matter
public async Task<bool> IsFileNameExists ( string filename )
{
var result = await GetInfoFolderAsync(filename);
return result != null;
}
//Alternative
public Task<bool> IsFileNameExists ( string filename )
{
var result = GetInfoFolderAsync(filename).GetAwaiter().GetResult();
return result != null;
}
//Or
public Task<bool> IsFileNameExists ( string filename )
{
return GetInfoFolderAsync(filename).ContinueWith(result => result != null);
}
Can you please show me the complete method as I showed above, in your case without the async and await, so that I can follow you clearly?
The forum will not let me post the code. See the attached text file.
Comment task.Wait() to see what happens.
Also, you should read...
Asynchronous programming with async and await
Task asynchronous programming model
@Michael Taylor
I don't think I would agree as you describe.
Let's look at your code:
The first two are correct. The second one I have already shown as an alternative.
The third one (and by extension the fourth one) is incorrect.
You declare the method to return Type 'Task<bool>' but return a type 'bool' and you get Compiler Error CS0029.
You're correct on the third one. It just returns bool. I'm doing this without INet right now because of storms. However the fourth one should be correct. ContinueWith returns Task<T>. Since the expression is boolean it returns Task<bool>.
Honestly I'm still confused as to why you're just not using async/await. If a function needs to do work that may not be done when it returns then you return Task<T>. What that function does inside is irrelevant. If it calls other async functions or is just sync it doesn't matter. The caller can get the results if and when they care about them, blocking in the process. Whether they do it using await, GetAwaiter().GetResult() or whatever doesn't matter. Changing return types requires waiting and evaluating the response. Whether that is also async or not is irrelevant.
I don't know that I can add any more to this conversation so I'm dropping off. Hopefully you'll get the answer you're looking for.
@Michael Taylor
I used a clumsy phrase "by extension" to mean 3 and 4 are used as one. Yes, the 4th one in isolation is correct.
If someone can tell me that what I try to do is impossible, I am quite happy to stick to what I already know. I just thought may be a Task can be returned for the example given. I was curious to learn if that is possible. We learn thru asking, hence.
If someone tells me it cannot be done due to such and such, that would be my QED moment. At this moment, there is no definite answer. I shall stick to what I know.
I just thought may be a Task can be returned for the example given.
The problem is your code examples are not designed well. Therefore, it is difficult to understand the intent or if you misunderstand Tasks and async/await. It seems like the design forces a pattern where every method must return a task regardless of what the method does.
Anyway, I shared an example of returning a task and controlling the flow using .Wait(). Cooldadtx shared a flow example using ContinueWith. Viorel-1 shared how to wrap synchronous code in a Task. We also explained async/await and provided links to the reference documentation.
I'm not sure what else we can do for you...
I think that the bool value corresponds to the result of '...FirstOrDefault() != null'. Maybe it was not used correctly after the call.
Hi @Viorel ,
I have tested thoroughly comparing with the alternative with an async method.
What you suggested will always be true because the pending Task to the left of != will always be nonnull, hence the boolean evaluation always true.
I thought I could return Task<bool> and await in the caller, but my only solution now is just await in the called method and return bool value.
I think that it is non-null when Where found the item. It cannot be non-null when Where did not find it.
Use QueryableExtensions.FirstOrDefaultAsync(). Then IsFileNameExists() can be an async method and yield control to the caller.
Viorel-1's sample creates a background thread that is awaitable. Can you share your test code? Keep in mind, for web applications you want to use an async method which is a better use of resources.
The following reference doc explains the mechanics of the async/await pattern.
Task asynchronous programming model
Sign in to comment