Summary of the actual development of gadget 1 (using a gadget to call WebService)

Preface

I haven't been here to talk about it for a long time. Some time ago I made a project that uses Vista gadget. It's rare to use a technology that I have never touched before to do things. Naturally, I have a lot of GAINS and experiences to share with you ~

This article describes some of the problems we encountered in completing this gadget project. We hope to discuss with you the development and application of the Gadget project.

Preparation

Some time ago, csdn held the gadget Development Competition, and clarified that Ms was promoting its new things. At that time, I had no idea, and I had no time to study it. However, I was deeply impressed by some of the later winning works in the gadget competition.

This summer, when I was playing a school competition, I met an application and felt that it was suitable for the gadget. After several evaluations, I decided to use the gadget service. It was also an advertisement for Vista by Ms. ^_^

Let's take a rough look at the application we are going to do. The service is planned to use. NET platform implementation, there is a encapsulated Data Access architecture, the client is planning to use gadget, in addition to general information browsing, we hope the client can also complete the customer's login and logout operations. After a user logs on, the client needs to frequently perform two-way data interaction with the server, and some local data storage operations are also required. The entire mode can be analogous to QQ ~ However, our client is Gadget.

Start

Doing things in school is definitely different from enterprise development ~ After clarifying the requirements of the client, we began to look for the development materials of the gadget, including the gadget development documentation in msdn, and some things such as the gadget Development White Paper. There are a lot of online materials, and cnblogs is also a good place ~

After not a long time of study, we have figured out the gadget mode, which is actually a special "webpage", and the logic is controlled by Js. The difference is that some special classes such as system. Gadget can be used in this webpage.

At the same time, the development progress of the server is also very fast, and some business logic and interface logic required by the system are quickly implemented.

Everything looks quite smooth. At this time, the development schedule is very good. It should take a few days to complete the development. However, the problem still persists ~~

First problem-data exchange

At the beginning, the problem mainly lies in the data exchange between the gadget and the server.

How to access the server?

According to the analysis of some of the gadget code we found, there are two main ways to interact between the gadget and the server:

1. Use Ajax, that is, use httprequest to send a request to the server in the background to obtain server data.

2. Implement your own ActiveX control, call it in Javascript, and interact with the server in ActiveX.

The Gadget programs that come with Windows Vista use their own ActiveX controls. The access code is similar to this.

Try
{
VaR o = new activexobject ("wlsrvc. wlservices ");
Stocks. MSN. Service = O. getservice ("stock ");
If (stocks. MSN. Status. Availability. Active)
{
Stocks. MSN. INIT ();
}
Else
{
Stocks. MSN. Status. Ping. Update (false, (stocks. MSN. Status. Availability. Error! = NULL ));
}
}

 

Originally, we thought that the control provided the method of accessing the network through the gadget. Later, we found that the ActiveX control called wlsrvc. dll encapsulates all the access logic. For example, in the code above: only one "stock" string is input using the getservice method, and wlsrvc returns a service object.

These built-in gadget tools that need to access the network all use this ActiveX. The difference is that the input initialization string is different. The original wlsrvc. dll is just a simple factory dedicated to the Windows Vista built-in gadget...

This makes us very depressed. MS is too domineering. Wlsrvc does not have any documentation, and its own gadget connects to something that originally had no source code.

Most of the online gadgets use the first method to interact with the server. Ajax technology tends to mature and is widely used ~

The code is similar to this:

Function creathttprequest ()
{
Listloading ();
Httprequest = new activexobject ("Microsoft. XMLHTTP ");
Httprequest. onreadystatechange = listprocessresponse;
Httprequest. Open ("get", "http://xxx.com/sss.ashx#,true );
Httprequest. setRequestHeader ("If-modified-since", "0 ");
Try
{
Httprequest. Send ();
} Catch (E)
{}
}

Then you can use the httprequest callback function to obtain data.

Basically, a parameter is passed in and a request is returned. I believe that AJAX development is familiar with this method.

By the way, in gadget, httprequest has sufficient permissions for direct cross-origin access, and does not encounter the "Access Denied" error when performing cross-origin operations like Ajax on a webpage.

God, how do I write the code?

The problem is: we need to perform more complex interactions with the server. For example, when submitting various client data, the data structure returned by the server is also complicated. Although we have defined entity classes such as userinfo on both the client and server for data transmission, however, using httprequest to implement data interaction obviously makes the code very complicated... In addition, the client of gadget does not have powerful server functions as webform does, and even does not have a debugger. We have been using notepad ++ to write code.

Think of one sentence: Ajax makes users an emperor, and developers become slaves.

We have estimated the complexity. Even if a third-party library such as prototype is used to simplify the coding of the gadget client, writing the ashx page is quite troublesome. Maybe we can write different ashx pages for each interaction, but this is definitely not a good idea. It is hard to imagine what a server looks like as a "website" with dozens of ashx pages. Even if all the calls are unified to an ashx page, the code on this page must be highly coupled (a page must process more than a dozen different requests), especially on clients, there are more than 10 different return values to be processed in a callback function, and the complexity of the Code is almost unimaginable. The only way we can think of is to use the design pattern to make the code concise and nice-looking, but Javascript is inherently less convenient to "get objects ". More objects can only make JavaScript code messy.

Use WebService to solve the problem

I 've been talking about it for a long time, that is, I want to explain that our demand for gadget exceeds the general definition of gadget-we want to do the Gadget program like winform or webform, the general definition of gadget seems to be a simple information display tool and does not involve complicated logic.

So we hope to use WebService to solve this problem. The general idea is that the server abstracts the interface as WebService, and the client only needs to call some functions it provides. Because WebService is based on the HTTP protocol, protocol Crip can be called in theory.

It is already so simple to encapsulate an asmx using C # on the server end. We almost only need to reabstract the interface and add [webmethod].

Failed to call WebService With WebService. HTC in gadget

The following question is how to use JavaScript to call WebService. We found a classic WebService. HTC without much effort. This is a perfect JS component that calls WebService in ms. (For a routine, see: http://blog.csdn.net/yangyifan0/archive/2005/12/08/546923.aspx)

At this time, the progress is quickly increased, and the method of using this component is very simple. Our WebService does not return the normally used dataset but directly returns the C # entity class. When we use the SOAP protocol for access, the entity class will be serialized into XML, javascript can directly parse these XML as JavaScript classes. Although the efficiency is not so high, it makes the program very concise.

For detailed usage, refer to the Help File of WebService. HTC.

It seems that the project is almost finished, but this time it is very depressing to happen again. The WebService. HTC file does not work in gadget anyway !~

I don't know what the specific cause is, and I feel it is related to security, because this component itself can implement cross-domain WebService calling on the webpage. It seems that some weird mechanism is used instead of httprequest, I have not studied this carefully. It is useless in the gadget.

Succeeded in using soap Client

I don't know if soap client is suspected of being used for soft advertisements. However, after some searches, we have determined that the only way we can go is to send soap to the server through httprequest and interact with each other. After some searches, we found the soap client (open-source, you can study it, in fact, its own principle is very simple ). Http://www.guru4.net/articoli/javascript-soap-client)

The detailed process is omitted. For some debugging, we have successfully implemented WebService calling in the gadget. After another encapsulation, javascript can even use the getxxxinfo method provided by the server as easily as using a local method.

The final instance code is as follows:

Server:

[Webmethod (description = "Get XXXX details")]
Public xxxxinfo getxxxxinfo (xxxxqueryinfo info, string context)
{
...
}

 

Xxxxinfo and xxxxqueryinfo are two entity classes, which define some fields such as username for access.

Client:

Function getxxxxinfo (sendidentities, text, clientguid)
{Var PL = new soapclientparameters ();
Pl. Add ("identities", sendidentities );
Pl. Add ("message", text );
Pl. Add ("clientguid", clientguid );
Soapclient. Invoke (URL, "getxxxxinfo", PL, true, function (r)
{
// This is the callback function
})
}

 

Just construct several parameters, write a callback function, and then pass it to the server. It's easy.

Summary of WebService calling in gadget

In gadget, in addition to writing ActiveX controls, it seems that only httprequest can be used for page requests. For simple requests (for example, only one word string needs to be input to request the translation of one word), an ashx page can be implemented to process the request like a normal Ajax.

If you encounter complicated requests, you can consider using WebService. Because WebService transmits program data through the SOAP protocol under HTTP, It is very suitable for the interaction between JavaScript and various servers. However, the conversion from soap to JavaScript on the client requires a lot of code. If you implement it on your own, it may be a considerable amount of work. However, the library of soap client implements this work.

This solution is just some of the results we have obtained after several days of exploration. As to whether there are other useful methods, I think there are still some. I hope you will advise me.

Take a break

So far, I have explained the problem of data exchange between the client and the server during the development of gadget and its solutions. No detailed code is provided. If you cannot understand the code, please point it out (I am also a lazy, haha ).

I want to talk about other problems encountered in development and my experiences, including the "I see pink" problem and file operations that plague us on the gadget, interface positioning, time operations, and other issues.

P.s talked a lot about the occurrence of the problem. Other problems were originally prepared to be written in one breath and found to be too long. I hope I will stick to the following content ......