I went from Xojo to FlutterFlow, which is low-code, and it took me a few days to embrace it but now, six months later, I couldn’t be any happier.
You have one “code” base and it compiles to iOS, Android, Web and I believe even macOS, but I have got no experience with that. I also do it as a hobby, at most three hours a day, and I can do the same app with FlutterFlow in less than half the time than I did with Xojo. But then it’s Android and iOS, not just iOS.
I shall not forget to mention that I integrate lots of services that FlutterFlow offers, like AdMob, Supabase, OneSignal, RevenueCat. But with the volume I have they are all free of charge and I save a lot of time because I don’t have to code them.
Simlply use JPACKAGE which is integrated in Java Distribution starting from Java 14. That you can download from the B4x website or directly from oracle here what will make no problem. I was using it also with Java 17 and JavaFX 17. But that will make a bit more headache. I used the one from Azul (JDKFX) and Liberia (JDKFX) for different platforms.
Simply build with it on the target platforms the DMG (MAC) or executables (Windows / Linux) and resource packages. It is like with all other Java Software packages.
By the way B4x is Basic and will result in a running JavaFX application. There is no real need of Java programming skills. That alll does B4x for you. Also you can build Android, IOS and Web Applications with it and you have a graphical GUI Designer.
So true. But you will end up paying more as you go along with Xojo as you will discover that you will have to purchase separate libraries/plugins to achieve many a things which in other tools are provided out of the box.
About to dig into b4x and give it a whirl. I have 2 simple companion apps I want. They should both be somewhat simple and straight forward, so we will see how it goes.
PureBasic - Linux ( including RPi ), Mac & Windows costs EUR 79 for a lifetime license.
SpiderBasic - Android, iOS ( via Cordova ) & Web costs EUR 49 for a single user license which includes 1 year of updates.
They both share the same syntax - PB is transpiled to C and then compiled with gcc, SB is transpiled to JS.
PB can create CGI and FastCGI executables so for web apps you can use SB for the front end and PB for the back end and there’s none of the sending client events to the server nonsense you get with Xojo. You can use JSON for sending data back and forth between back and front ends.
Support for SQLite, MariaDB, Postgres and ODBC is included in PB at no extra cost.
For desktop though one thing I would suggest is using these ( free ) third-party UI widgets which I think are better than the included set.
For SpiderBasic there are also third-party widgets ( again free ) that enhance or replace the default set.
For Android, iOS you can also import additional Cordova modules into SB to add more functionality:
Hm, some of these bugs are many years old. One I recall was from 2015.
Overall the bugs are more edge-case bugs than are typical in Xojo. In Xojo I reported a very drop-dead simple bug … a DB function that did not work AT ALL and the (very common) circumstances in which it did not work (Postgres, non-default schema). Clearly broken, easily fixed … but not addressed after a year. Only redeeming quality is there was a workaround, very much the DB equivalent of a Declare. OTOH the 2015 bug mentioned above was a string comparison issue involving Cryllic. The stuff PB lets accumulate truly does impact only the occasional user. And at some point they do bite the bullet and work through them.
This! I think many of us have submitted a bug, some show stopping and some not, that languishes for years. Sure, some are edge cases but often they are not. Clearly bug fixes are not their top priority. Or rather, certain types of bugs (e.g. database and reporting to name a few) don’t get their attention.
Which begs the question: what is their top priority?
To be fair, MSFT has a version of this … if a bug isn’t reported by (some nebulously defined) sufficient quantity of users, it’s deemed to not impact enough people to bother with. It’s a bit like at Xojo when not enough people upvote a report, but AFAIK without the actual voting mechanism, last I looked anyway.
They DO have bugs that don’t get resolved, or that are infuriatingly marked “by design”. But even they will fix something that doesn’t work as documented, or in the extreme, will deprecate and eventually remove a feature they can’t be arsed to maintain (or change the documentation!).
The other difference between MSFT and Xojo is that with MSFT products nothing ever gets to the level that significant numbers of developers feel disrespected and uncared for. User enthusiasm remains high at least for the currently core / hot use cases (web and mobile; desktop developers will probably never feel like first-class citizens; the world has moved on). Everyone ends up ticked off about a couple of small niggling problems but it never rises to the level of leaving in disgust for greener pastures. People try out other platforms and if they find the right project they might jump ship, at least for a time, but that’s normal market churn. There are no concerns about insufficient resources devoted to moving things forward. There is no letting the compiler development drift for years. Performance always improves. The GC has improved beyond my wildest dreams and has even largely gotten away from a “stop the world” approach. New advanced abstractions, syntax sugar and so forth are slathered on, almost to a fault; advanced devs can use them, noobs can safely ignore them and pick up some of them here and there at leisure.
Even when Microsoft breaks an API (.NET Framework vs Core, ASP.NET MVC 5 vs Core, seemingly a new RPC framework every 5 years whether we need it or not) they support the old one for at least a decade and often longer rather than just saying they’ll “support” it but really just letting it wither on the vine).
The bottom line at MSFT is I haven’t even HAD to report a bug in years. I’ve bumped into small problems with easy workarounds, or encountered bugs that are confirmed by others, with workarounds. Nothing has been a show-stopper since whenever it was that you could turn on stepping through the open-source framework code and I traced a serious problem with DataTables to some code they had commented out for testing and forgot to un-comment. And that was fixed as soon as I reported it.
There’s an analog to the bug I reported that is not being tended to, vs a minor feature request which they have jumped on (although it keeps slipping to the next release, currently targeted for 2023r4). The title is “Feature Request: warn user on project first save / Save As if saving non-binary project to a non-empty folder (#71145)” I had suggested an optional additional functionality that would by default, without confirmation, refuse to save to a “special OS folder” (like Documents) at all, even if empty.
This feature would be important for new users who don’t yet fully understand the project structure and keeps them out of trouble. It bit me because either Xojo or MacOS defaulted to the Documents folder and I had two projects sort of merged together IIRC. It was a dumb mistake but the IDE could have prevented it; users shouldn’t have to be hyper-aware all the time.
To my mind the malfunctioning DB function I reported is by far the more important of the two and I would have thought much more likely to be fixed quickly since it’s existing documented functionality that’s not working as advertised (or correctly, or at all, for that matter), whereas saving to a folder with other stuff in it isn’t really a bug, but more of an extra guardrail / user convenience that’s not critical functionality. That the inverse happened suggests they really are optimizing for the noob and triaging away fixing most bugs in advanced features, DB interfaces, reporting, etc.
If they are neglecting reporting, it seems odd to me that they in recent releases added a lot of PDF functionality in … maybe once the PDF features are checked off their list, those, too, will start to twist in the wind when it comes to fixes??
But if there’s a plan or a triage policy, it seems increasingly clear, as Torsten_B suggested, it favors “new customers” and making Xojo look more on top of maintenance and R&D than they actually are.
The ONE thing I wish they’d do is tackle those things customers CANNOT do for themselves because they are in the compiler or framework
Like Array.Sort DOESNT call operator_compare when you sort an array of custom classes. It should but doesnt. Only Xojo can fix that
If you define a class and have operator_convert defined so the class can auto convert itself to something else (like a string). If you try to do
dim c as new myCustomClassWithOperatorConvertToString
dim s as string
if c <> s then // c will NOT convert itself to a "common type" of string
end if
if s <> c then // c will NOT convert itself to a "common type" of string
end if
operator_convert WONT be called but it would make sense to
THOSE kinds of things we really cannot do for ourselves - they are in the framework or compiler (or both) and Xojo is the only ones with access to that code to fix it
I guess… but isn’t that what Operator_Compare is for? I can see the logic in converting, but if you have both a convert and compare with string, that could get a little messy.
There’s no reason I can think of for convert to NOT be useful here as well since to compare most types Xojo figures out the “common type” and converts as needed to compare those common types
ie/ comparing a double & integer it converts the integers to a double and compares
or an int32 and int64 is sign extends the int32 to make it an int64 and compares
Thats what I was expecting would happen
But it doesnt
Operator_convert TO should be considered as one of those possible conversions for use in such a situation
It was a long time ago when I bumped into this and I did eventually use operator_compare
