Recently, several projects that use web services use sudzc to generate the obj-C processing code, which has been used very well and very convenient.
Previous projects were non-arc projects. A new project of Arc was established, and sudzc also had the code to generate the arc version, so it was previously used.
When debugging this project today, we found that the results returned by Web services are all nil, but the results returned by the request are not empty. (We can see through log printing)
When breakpoint debugging is set, a null value is returned after the following code is executed.
Cxmlnode * element = [[soap getnode: [Doc rootelement] withname: @ "body"] childatindex: 0];
Continue to follow up debugging. The XML node returns the following printed results: (cxmlnode * child)
<Cxmlelement 0x7591210 [0x7588bb0] Soap: Body <soap: Body> <dologinresponse xmlns = "http://tempuri.org/"> <dologinresult> {...} </dologinresult> </dologinresponse> </soap: Body>
Looking back at the previous Web Services Projects, the printed results are similar to the following:
<Cxmlelement 0x7594050 [0x81b95a0] body <body> <validateuserloginresponse> <validateuserloginresult> {"email": "sing@163.com", "errmsg": "", "mobilephone ": "13725373425", "username": "sing"} </validateuserloginresult> </validateuserloginresponse> </body>
The problem is that the keys of the two retrieved nodes are different. One is soap: Body and the other is body, but the following code is the same in both projects:
Cxmlnode * element = [[soap getnode: [Doc rootelement] withname: @ "body"] childatindex: 0];
The element obtained by the latest web services project is null.
Change the code of the obtained node to the following to solve the problem of returning null values.
Cxmlnode * element = [[soap getnode: [Doc rootelement] withname: @ "Soap: Body"] childatindex: 0];
The problem is solved, But the strange thing is that there is no problem if we don't use the arc version for processing. If we use the arc version, we need to modify the code to get the correct result, try further debugging to find the final cause, but after all, because of the large amount of code, there is not much time to understand, so you can only give up. Google found that some people had such a problem, and they could only manually modify the code but could not find the cause. It seems that this problem has to be solved by the author. I am not willing to solve it. This article also marks the problem and solves it later to see where the root cause of the problem is.
BTW: I want to use sudzc to re-generate the code today, but the result shows that the Code cannot be generated and PHP Execution fails. It is hoped that the author will discover and fix the issue as soon as possible.