Correct usage of Watcher ?

Hello,
While enjoying learning App Builder and making my tests with web apps, I had a question about the Watcher's usage.

I created a sample project waiting for the result of a SimpleGet before to send a Post request using a HttpClient (that request is inside a Function). But the problem I am facing is this one : I have put an Alert box to see when the Watcher is detecting a value change. That Alert box is shown directly when the page is loaded even if the Watcher is not started and not associated with any variable in Design mode (association made by code after a button press).

So, I wonder if I have well understood how it works (the sample app provided works really great).

Many thanks

Hello Samuel,

Don't worry: you are not crazy. That's the default behaviour for the "Watcher": their Change event is executed when the app is load, but, do not means the associated variable has changed. What we can do it's the same that the Watcher sample does in the Change event: check if the "[WatcherName.OldValue]" and "[WatcherName.NewValue]". Something like this:

I try to clarify a little this question by doing two things: add into the Watcher help the reference to these old and new variables. They are referenced before, but only in the Change event help. On the other hand, I fix a mistake and also add these variables to the variable's selector.

Said this, I am not sure if you can achieve what you wanted using a Watcher. Maybe yes, but, probably we can take another approach. In few words, the SimpleGet and SimplePost actions exists to made HTTP request mainly to app files and without worry about asynchronous issues.

For example, the SimpleGet variable can be useful to load certain content to be show in an HTML content control, for example. But if what we need is to assert than an HTTP request is made and end successfully or with an error, then the HttpClient control is for us.

You can use various HttpClient controls or just one, because you can made an HTTP GET request with such control and then establish another HTTP method and execute another HTTP POST request, for example.

Then try with the Watcher if you like Samuel and tell us if they works, or think in the use of one or more HttpClient controls.

Hello David,

I do thank you for your nice and helpful information. It clears really the things. So, I'll keep in my mind to use the HttpClient for chained operation.

Many thanks again, David

Edit : of course, I'll post the result of the chained HttpClients as you suggested

Hello Samuel,

Maybe it's more easy to you to use a couple of HttpClient controls. One for the first request and another one for the second request. But yes; the HttpClient control can assert if the HTTP request have success or not, and then allow us to react to a success or error situation. Other actions like SimpleGet or SimplePost are useful (because no need to be ready for any event) but cannot be used if we need to assert an HTTP request result.

Hello David,

Linking more than one HttpClients was the solution. I had hard times with setting CORS on other servers and receiving the variable sent in GET format (I am not using PHP but will have to think about).
This makes me think about this (but I am not sure if it is normal or not) : Should the HttpSetData work with a GET method too or is it reserved to POST only ? In fact, I was able to receive a variable using GET when I created the URL myself https://domain.com/?var=value&var1=value etc.

Many thanks :)

Hello Samuel,

This shock me a little, because I expect HTTP GET requests also accepts the values added to the HttpClient, however, this is apparently reserved for HTTP POST requests (and probably others like PUT, DELETE, etc.). In fact they have some sense, and certainly taking a look at the Firefox debugger panel we can see that the request is made without incorporating any possible data.

I want to take a look at this in more deep. However, you know we can simply preparing the right URL. On the other hand, maybe a couple of actions can be useful here in order to decode/encode such kinds of URLs, on the first time, and maybe some action(s) in order to provide us an easy way to prepare URL with some keys/values.

Just let me sometime in order to think about Samuel.

Hello David,

Thanks a lot for your reply. I do agree with the idea of creating the URL manually for the GET requests. I was not sure about the HttpSetData function, reason why I did ask you. Perhaps it is more simple to keep HttpSetData for the POST requests as you confirmed :)
Wishing you a good evening and thanks again David

Hello,

At a first time we can expect the HTTP data are also available for GET requests, however, if we think a more in deep probably we reject such idea. If the server take the data of a HTTP GET request from the URL... then it's the URL which contains the HTTP GET data... or not.

Then, if we want to make an HTTP GET request which include some data we can just prepare our URL in the way you already know Samuel:

Doing something like the above is perfectly valid and in fact we no need to do nothing more. If we wanted to send to our server some other kind of data, for example, some app input control values, probaly it's a better idea to use an HTTP POST request instead of an HTTP GET request.

However, if we want to do an HTTP GET request in this last case, we can enter in problems if the input control values contains certain characters. For this I add the new EncodeUri action and DecodeUri action into the Strings action's category. This actions allow us to encode an input value in order to be safelly used in our request URL, for example:

Probably you no need these actions right now Samuel, but, for sure they are needed if we plain to made some HTTP GET request like the above one. Of course I insist that to send data to our app server it's probably better to made an HTTP POST request than an HTTP GET request, and, in this case we can also get beneficts of the HttpSetData action.