To clarify, are you saying that paypal api support should be built into the language or an official library?
It should be available somewhere which, right now, I dont think there is ANY publicly available code for this
I could well be wrong on this but I dont think I am
Certainly nothing supported by Xojo
Most API documentation offers samples in at least cURL. Sometimes providers will offer additional languages, but Xojo isnât on anybody elseâs radar so there arenât examples for it.
Usually when cURL examples are provided you can implement the API with a Xojo URLConnection. I havenât come across something that canât yet.
I donât think itâs unreasonable for the people who spend the time learning how these things work to ask for compensation so they can put food on their table.
I have spoken with Christian at great lengths about this, and it boils down to a single factor. The Xojo community has been shrinking for well over a decade, API 2.0 made a significant chunk leave all at once, but Xojoâs been on a downward trend for a lot longer than many of us were aware.
Those who canât just up and leave are struggling to make ends meet while they put a âLife after Xojoâ into action.
For some of them it is more important not to have any semikolon in their programming language
From an individual level, itâs easy, but from a provider level (like Xojo) supporting such things becomes much harder.
Once you set yourself as a source for a library like this, you have to be willing to take support requests for it. Even if you provide it with no support, you will still get support emails. Then you have to be willing to keep it updated when PayPal changes their API. Then you have to handle everyone else wanting a specific connection. These things take time.
And as a company, you have to be careful that you donât get PayPal (or whoever) upset with your documentation it a sea of potential legal issues. And those will usually be a nice letter saying, âhey, you canât say this please change it,â which is not a big deal at an individual level, but a larger deal as a company with however many employees are left.
And it sounds stupid, but it can involve different departments, and even lawyers. Questions like, âdo we need a separate privacy policy for this?â take time away from other tasks. It wouldnât be surprising if something like this already surfaced at Xojo and got hung up on some obscure policy that canât be adjusted for the most asinine reasons.
As an individual, you arenât emailing yourself asking yourself for documentation, download links, technical questions that were answered in the documentation, etc. etc. etc.
This is from experience. From being tasked to create a regex library for âcommon matchesâ on PDFs (and if you ever worked with PDFs youâll know why I cried when I received that email), among other things.
Having worked for Xojo for over a decade I fully understand this
Note I didnt say it had to or should come from the company
I dint think its available, for a price or for free, from anyone in the entire Xojo ecosystem
There ARE people like Tim who can and will create it for clients - but those tend to then be for private use only and not available to others
So we are facing more failed xojo business decisions then?
Imagine what would happen if Xojo kept track on Macs, Windows and Linux operating systems, i386, amd64 and arm, fixing all bugs and loopholes before expanding to iOS or Android or web?
Given their track record on fixing (and creating new) bug they wouldnât have attempted web, iOS, or Android.
The perpetual focus was on new features because, apparently, bug fixes arent a selling point
Maybe thats true
But still how you manage features vs bug fixes could be changed and do a tick tock schedule where its features, then bug fixes, features, etc
But, a lot of people have suggested this to Geoff over the years and since they still refuse to do that Iâd say its pretty obvious heâs not inclined to change that
New Features increases new customer sales
Lack of Bug Fixes decreases customer retention
and the 2nd seems to be occuring faster than the first
Even thenâŚthere is no bigger market chance. That exactly is the problem with Xojo. There is a leaky ecosystem around. They have no chance to get on the same level with others like JAVA OR c#. This train left the station before years. There is no chance for any business.
The options for doing what Xojo claims to do, but doesnât actually deliver, of âwrite once run anywhereâ are getting better and better
Java has come a LONG way from what people might remember
As has that entire ecosystem
CodenameOne, and some others youâve mentioned, definitely make using Java nicer than ever before
And C# MAUI applications, or Avalonia ones, really can create the same app on multiple targets from the same source (Iâve been working in MAUI for 2 specific targets)
Xojoâs opportunity window, for more than hobbyists, seems to be closing faster than ever before
And really, Xojo has none of the advanced stuff that pro developers could want. Generics, gRPC support, Protobuf support, libraries for generative AI come immediately to mind because these are things that weâre actively working on and Xojo offers no help/support for any of them.
âŚis closed.
There was never a window for Xojo as they had never the chance other than desktop. They have done a bad job lookng on mobile and they destroyed their own web. And it is no problem to write a JavaFX App and use it for Web. There is all you need with JPro including routing and so on.
I think they (Xjo) lost the connection before many years. Hence the CEO decides everything without a connection to the reality it will not change
Well they do still seem to attract a few
But they dont seem to stick around very long
Working in C# on a POC app last night and thought âGee Preferences seems like something that might be built inâ
So I typed
string ipAddress = Preferences.
and lo & behold not only did it suggest Get with a key & default value it also CAN apparently use the right one so instead of having GetString, GetInt, GetDouble, etc all overloads are named âGetâ and can return different types. And the editor suggested âthe right oneâ based on the fact my variable was a string
So nice to find simple stuff like that and the more I work in it the more I like it
EVERYTHING I need is there and stuff I havenât even realized I will want
The only thing slowing me down is ME trying to learn everything I can about how to do things ârightâ and better than what I initially hack together
iOS⌠When they decided to spread more and waste time with a poorly planed âNewâ framework that no one wanted while the overall quality and bug fixing decreased.
A giant screw up, but instead of LEARNING from that, some genious decided to do it over and over again⌠Biger and harder to avoid
TBH the new framework was actually a result of several factors - mostly from users bug reports & requests
String - OMG string ! A clean split between Text, actual TEXTUAL data, and BYTES which string munged together in a way that was a persistent mess. Toss in the fact that String got lots of things wrong with certain encoding and TEXT didnt ⌠but âŚ
Users wanting the compiler to strip better and make smaller apps which the new framework in iOS would enable but the classic framework never will since its ONE giant blob
And many other fixed data types, some of which HAVE made an appearance in current versions
DateTime & a more modern Folder item
The worst issue was that after releasing iOS work kind of stopped one expanding it since we had many other items that were more urgent to tackle so it never expanded to cover enough
but thats history âŚ
final words on xojoâŚ