JSON POST-GET in desktop app

I am struggling to figure out how to send POST and GET requests on a desktop application. I cannot figure out how to make that work in XOJO.

For those who may have responded on other topics I have recently posted this is the alternative solution to communicate to a PICO WH with a Pi5. This is the project that went from I2C to BLE. I really wanted to do BLE but this method will also work. While this is in General the need is to figure out how to implement this on a desktop albeit a Pi5.

To simplify at this time I have removed authentication but will move to OAuth1 when I get this working on XOJO. The PICO is the Web Server and I have it working using POST and GET routines written in PYTHON that parse appropriately and tested with RapidAPI. The application either sets/clears a bit on the PICO or responds to a GET for RV AC current value. Now I need to get this working on the Pi5 where the user interface is ready to go.

I have working examples of two way functioning using RapidAPI. I attach those pics

POST - some are single and some are multiple BODY KEYs with Value no URL Params

GET - has no BODY or URL Params

I have used RESTy as an example but no matter what I attempt to write for code/methods I cannot figure this out.

Any suggestions

GET tends to be a little easier than POST imho.

var u as new URLConnection
var response as String = u.SendSync("GET", "http://192.168.4.1/api/rv_current")
var J as new JSONItem
Try
J = New JSONItem(response)
catch e as RuntimeException

End Try

if J = Nil then Return //Our request has failed
if J.HasKey("RV CURRENT") = False then Return //HTTP Request succeeded but missing the return value
var RVCurrent as Double = J.Value("RV CURRENT").DoubleValue

This POST example is assuming that the control-front-off is expecting a JSON request body, which I’m not sure based on your screenshots if is the case. It may be expecting x-www-form-urlencoded instead, in which case this’ll need some tweaking.

var u as new URLConnection
var req as new JSONItem
req.Value("FRONT_OFF") = 1

u.SetRequestContent(req.ToString, "application/json")
var Response as String = u.SendSync("POST", "http://192.168.4.1/api/control-front-off")

var J as new JSONItem
Try
J = New JSONItem(response)
catch e as RuntimeException
End Try

if J = Nil then Return //Our request has failed

var Status, Message as string
if J.HasKey("status") then Status = J.Value("status").StringValue
if J.HasKey("message") then Message = J.Value("message").StringValue

Hi @Carl_Fitzsimmons the first mistake everyone makes, including me, is having the URLConnection drop out of scope before it receives the response and triggers the .ContentReceived event.

Is your URLConnection persisting in a non-perishable space, outside of the method you’re using to work with it?

this component should be part of a window (drop in)
or subclass it (a class with super to URLConnection) to have the events (without the need of using addhandler)

POST and GET is used by web request it have a http header and then the data
if you send a http header for your json body
the header must contain

Content-Type: application/json

json content you can create with JSONItem
and then you call .ToString to have your request body data.

a get request is usually a single line of url
http://domain:portnumber/apipath/method?a=1&b=2
https://domain:portnumber/apipath/method?a=1&b=2
arguments must be urlencoded

It took me a while to understand the POST method. First attempts of hard coding were almost embarrassing. But I finally had something to work with thanks to your examples. I have now added Parameters to enable use with multiple commands in POST and GET methods.

Very nice - thanks

This is a work around until I dive in and create solutions for Pi ARM 64 to enable BLE. At this time that effort is shaping up to be a Shell Fest. As mentioned this effort was also discussed in another topic concerning touchscreen then I2C then Blue Tooth now REST. This is less than ideal as I now need to tell the PICO what network to use when a network exists.

The current project I am in process of stems from identifying a need to solve an RV temperature control system. I choose Pi5 and PICO. The important piece here was a quality UI. I selected a touch screen and went to town.

I am intending on trying to make this a product for older RVs. RVers are not network savy. Also take into account there is no keyboard or mouse. While solvable this literally needs to be plug-n-play with a well developed UI not the standard drop down, Bevel Button etc in order to enable finger control. Additionally there may be several of these devices in an RV and I would be better to put them in there own communications network leaving web available for other connectivity needs such as remote from the outside world.

If I may rant a little:
The lack of BLE for ARM 64 Linux - Pi in particular became disappointing in that XOJO is not there. IMHO XOJO is missing out on the maker community (Rasp, PICO, Arduino, Beagle Bone etc.). Why? Because those micros typically are interfaced with solenoids, LEDs, I2C temp-humidity etc devices. All of those devices can interface using BLE and have many examples how to interface BLE to typically a droid or iPhone.

IMHO if XOJO had BLE capability then to me using a Pi to talk BLE to those other devices becomes a no brainer for development because awesome UIs can be readily created using a touchscreen and Pi. Here are a few pics of the screen layout on a 7" touchscreen.

Landing Screen

Main Screen

Front Temperature Control Screen

I am saying it again. IMHO if XOJO had BLE for ARM 64 Linux (Pi) then this would be a valuable RAD for makers and prototypers who will either move to some form of a product or use XOJO because of the UI capabilities. Good looking sells itself. All those micro development boards have BLE in there and it is a very large world wide community.

I did open a request for XOJO to support BLE. Have a look and comment.

Anyway - my two cents or is that now with inflation a nickel :slight_smile:

Yes sire. I am using Containers and DesktopPagePanel to enable a GUI. Once I get this narrowed to what is needed I think I may sub class and use in other areas

Probably the only thing that was persisting was not being able to get it to work. Although I have done what you mentioned before. Thanks for the comment

Are there no declares on Pi to control BLE? If you make it work, you could probably package it and sell it to other Xojo developers.

There is bluetoothctl.

That cli command set works fine manually as you page into and back out typing appropriate values but using shell command in XOJO I have not been able to figure out how to make this work. I have used different shell modes but could not get that to work.

Once-if that is resolved I have no idea how to package so it can be sold to other developers.

No. I mean’t calling into a BLE library, not from the command line. You should be able to do this from Xojo alone.

Interesting. I was not aware I could call into Pi BLE library. The CLI syntax used for BLE is bluetoothctl. I did a quick search and found Calling native Linux APIs — Xojo documentation

Another quick search and I found the following
To access the Raspberry Pi’s Bluetooth Low Energy (BLE) API, you’ll primarily use the command-line interface (CLI) and the bluetoothctl command, or leverage Python libraries like bluepy .

That led to this

  • Programming Libraries:

    • Python: Libraries like bluepy offer Python bindings for BlueZ, enabling developers to create BLE peripherals and centrals.
    • Node.js: bleno (for creating BLE peripherals) and noble (for creating BLE centrals) are popular Node.js libraries for interacting with BlueZ.

So far this is guessing which way to go and is all new territory.

Am I heading in the right direction? If so when I find th library how would I proceed to integrate into XOJO making the declares? Is that along the lines of the calling_native_linux_apis.html?