If you like WeaponZhi’s article, you can keep track of what’s going on on our public account WeaponZhi
preface
As a mobile development engineer, the work related to interface in the normal development stage is to connect with the partner of the server side. There must be some inconvenient places in the process of connecting.
So, today I would like to introduce the package capture software “Charles”. Using Charles, the interface related to data interface and debugging work will become efficient, simple and pleasant.
I will specifically introduce the use of the three functions of “access interface data”, “interface data replacement” and “request redirection” in specific development.
This article mainly introduces the use of Charles in the development stage, highlighting the practicability. As for the introduction and configuration of Charles, it is not the focus of this article. Students who have not configured Charles can refer to this blog post, which is very detailed: Experience in using Charles
View interface data
When we are developing, we often debug the interface and need to look at the data returned by the interface. Most of the time, we used the Log system configured by ourselves to search for information. Although this method can meet our needs, it is actually quite troublesome and requires a lot of preparation and operation. Now that we have Charles, everything will become simple and rough, and it will be clear at a glance.
Once configured, all browser requests will be displayed in Charles. If your phone and emulator are also configured with proxies, all requests from the emulator and phone will also be listed. Host flashes the yellow flag, indicating that a new request has just passed under this host.
On the left side of the figure is a summary of all the packets Charles caught, classified by the host of the request, and on the right side is the specific information of the request, including the request header, returned data and all information related to the request. If the data is in JSON format, it will be automatically formatted. If it is a picture stream, It will also display images directly and so on, so everything you want to do with this interface, you can see at a glance.
Sometimes, though, we get a little too many requests, and what we need to look for are special host requests. For example, in this case, we want to see the request under the host “www.jianshu.com”, so we can go to Proxy->Recording Settings to set the filter. However, I will directly right-click the required host and select Force to filter, as shown in the picture below:
As you can see, all Other Hosts will be categorized into the Other Hosts.
In this way, we usually look up the interface information will become simple and crude.
Interface data replacement
We often run into situations during development. For example, if you have started to write the code for the request, but the interface on the server side has not been written yet, your logic may have been written but there is no way to test it. You have to wait or add fake data to the code to simulate the request, which takes time and energy.
Or even though you interfaces and server now, but you want to do some boundary value testing, want to modify the request parameters or return value, this is not an easy thing, often need to service the coordination, if we can easily change the data returned by some means for yourself, not a beauty can help us improve the fault tolerance of the code?
Charles can do that easily.
Let’s now write a simple request code using Retrofit:
// For example!
private void request(a){
Api.getDefault(HostType.MESSAGE)//HOST:http://fy.iciba.com/
.getCall()
.subscribe(new BaseObserver<MessageBean>()){
@Override
protected void onSuccess(MessageBean entry) throws Exception{
entry.show();// The request was successfully displayed
}
@Override
protected void onFailure(Throwable e, boolean isNetWorkError) throws Exception{}}); }Copy the codeGetCall here () method is a simple get request, the request of the complete address is: http://fy.iciba.com/ajax.php?a=fy&f=auto&t=auto&w=hello%20world
@GET("ajax.php? a=fy&f=auto&t=auto&w=hello%20world")
Observable<MessageBean> getCall(a);Copy the codeMessageBean looks like this. We define a show() method to print out the fields:
public class MessageBean {
public int status;
public content content;
public static class content {
public String from;
public String to;
public String out;
public String vendor;
public int errNo;
}
/** Defines the method that outputs the returned data */
public void show(a) {
LogUtils.i("status:" + status + "\n" +
"from:"+ content.from + "\n" +
"to:"+ content.to + "\n"+
"out:"+ content.out + "\n" +
"vendor:"+ content.vendor + "\n" +
"errNO:"+ content.errNo); }}Copy the codeWhen we go into the app, the data we see in Charles looks like this:
Logging in the application looks like this:
If we want to change the value of the FROM field, how do we do that? Very simple. Just go to Tools->Rewrite and select Enable Rewrite, then add a Rewrite Rule and fill it in with the data you want to replace:
Click OK, let’s request again and look at the returned data:
Notice that the returned data has actually been replaced, and from now on we can easily simulate data ourselves! Don’t bother the server partner any more!
Request redirection
Let’s imagine a realistic scenario:
The server side has defined the format of the data. For example, the specific field of the MessageBean above has been given to us first, and then a test address and an official address have been given to us. However, the official address has not been arranged, so we can only use the test address to write logic and test.
Now that we have redirection, we can write the logic with the address of the request still using the formal address, but by using Charles redirection, we actually run the request as a test address request, and when we go back to the server to set up the formal environment, We do not need to change the request address in the code, which reduces the possibility of error.
To give you an example of the address we just requested, we also have a log that prints out its actual requested address and returns it:
We now redirect this request to the address www.baidu.com. If the redirect succeeds, it should return the HTML page code data of baidu home page. Let’s see in practice:
We change the requested address to the address we set:
@GET("ajax.php")
Observable<MessageBean> getCall(a);Copy the codeNow let’s rerun and look at the request log:
We found that the same address, the return result is not the same, return is baidu home PAGE HTML code.
Actually use most at ordinary times is to redirect a Local file, use just the option under the “Map” Local operations, as well as the above operation, is added in the Add a Local JSON file, so that when you are in the request directly can return to the Local file data, the advantage is that you want to change the data, You just need to modify the local file save, request again, the data has changed, it is too convenient.
Other features
Charles also has many useful features that need to be explored, such as breakpoints and resend requests. Here again a more useful function, that is to simulate the slow network function. For our usual development, this function is very practical, many times, some bugs are in such a special case to reproduce.
To enable the Throttling function, use Proxy->Start Throttling Settings. In addition, you can use Proxy->Throttling Settings for detailed network Settings.
conclusion
I believe that you can’t wait to use Charles, this artifact can be said to be a necessary development. Of course, as programmers, we should understand the software product output is not easy, I hope you can support the legitimate, respect the results of others’ labor, from the formal channels to buy oh.
My public account looks forward to your attention
