How to implement three tier architecture in windows phone while calling web services

Recently i worked on integration of sharepoint windows phone. I used web services provided by sharepoint for the communication.

Form there i came to know that windows phone supports only Async calls to the webservices, which start executing remaining line of code and once I get response It will start executing it. But in this case suppose my logic is depends upon response of web service then its not useful for me to call async call of web service. I need to write all logic in openreadcompleted or these kind of events etc.

This does not work in all scenorious so i created a class name CustomTask for communication and the code goes below:

MainClass
{
        foreach (Task t in tasks)
        {

                CustomTask objCustomTask = new CustomTask();
                objCustomTask.IsTaskCompleted += new EventHandler<CustomEventArgs>(objCustomTask_IsTaskCompleted);
                objCustomTask.sort开发者_如何学GoTasks(t.ID, t);

        }
}

public class CustomTask
{
    public event System.EventHandler<CustomEventArgs> IsTaskCompleted;
    CustomEventArgs objCustomEventArgs = new CustomEventArgs();
    WorkflowService.WorkflowSoapClient ws = new WorkflowService.WorkflowSoapClient();

    public void sortTasks(String id, Task t)
    {
        objCustomEventArgs.objTask = t;
        ws.CookieContainer = Login.cookieJar;
        ws.GetWorkflowDataForItemAsync("TaskName");
        ws.GetWorkflowDataForItemCompleted += new EventHandler<WorkflowService.GetWorkflowDataForItemCompletedEventArgs>(ws_GetWorkflowDataForItemCompleted);
    }

    void ws_GetWorkflowDataForItemCompleted(object sender, WorkflowService.GetWorkflowDataForItemCompletedEventArgs e)
    {


        objCustomEventArgs.IsPendingTask = false;
        XElement objxelement = e.Result;
        IEnumerable<XElement> objXElementColl = objxelement.Descendants(XName.Get("ActiveWorkflowsData", Constant.strWorkflowList));
        foreach (XElement objXElementWorkflowTemplate in objXElementColl)
        {
            XElement objXElementWorkflows = objXElementWorkflowTemplate.Element(XName.Get("Workflows", Constant.strWorkflowList));
            if (objXElementWorkflows != null && objXElementWorkflows.HasElements == false)
            {
                objCustomEventArgs.IsPendingTask = true;
            }
        }
        IsTaskCompleted(sender, objCustomEventArgs);

    }

    public List<Task> GetPendingTask()
    {
        return null;
    }

}

My Work is done bu i have some Questions in my mind:

1. The method i used will this effect Perfomance of the application?

2. does Asynchronous calls means that we can not implement 3 tier architecture?

3. Why Synchronous calls are not supported.

1. There's nothing obvious that jumps out of your code as being a likely performance issue. The only way to know for sure is to run it and measure if necessary.

2. Using asynchronous calls has nothing to do with the number of architectural tiers you are using. It relates to the way the applciation waits for a response.
   Your statement "that windows phone supports only ASync calls to the webservices, which makes the thread to wait for the response" is wrong. Making asynchronous calls means that the thread does not wait for a response. Using the Async (and await) keyword(s) (if you are using the Async CTP) the code still runs asynchrounoously but executes (as far as you are concerned) in a manner comparable with how it would if it was synchronous.

3. Synchronous methods were not made available as they don't make sense in a mobile context for 2 big reasons:

Perceived performance:
Having the application unusable (due to a blocking thread) while it waits for a response from a request can create a terrible user experience on a mobile device as the way a user typically engages with an app running on a device in their hand (compared with a PC) means that any pause appears to take comparitively longer. As the app is not waiting for the response it's able to show a waiting indicator, allow the user to do something else (with what could be a very limited number of processes) or allow the user to cancel the request much more easily.

Occassional (and often poor quality) connectivity:
The connectivity of a mobile device, by its very nature, is different to that of a PC. In mobile you have to assume that any connection might not be made or, based on the conenction method being used, may take a long time to return. If the user is on a 2G network connection and the request is for a large amount of data it could take a long time to complete. You don't want to keep the user waiting all this time. If an applicaiton is written to cope with asynchronous requests it's also easier to have that code cope with no response ever coming back.

To avoid the above issues with synchronous code requires writing it as if it was asynchronous. It's better just to cut out the middle man.

By forcing all communication to be asynchronous the developer (and designer) are forced to consider these two important aspects of good mobile application development and design. In turn this helps avoid the creation of very poorly performing, unresponsive apps.