Yeah, you can really tell with all the Xojo staff posts and apologies and plan to course correct on TOF… 
2 Likes
It felt weird when they thank me on my last complain (issue report) instead of the usual gaslighting. 
3 Likes
You made a really good point and thanks to that the next release (the IDE) should be faster.
1 Like
Hope springs eternal
1 Like
This apparently does NOT extend to Android apps on x86_64 emulators
I’ve got such a set up and quite literally ONE LINE of code to create a sqlitedatabase has now been running for 10 minutes (in 2023r3.1 I’ve NEVER seen it complete and its been left for hours)
Can you share the complete code?
One app alone wont be useful
You need all 3 plus the database
And I’m not sure I can / should share something like that here
Or with Xojo as they’ll want a simpler example
I’ve been trying to tear it down and have come across several issues which I have filed bug reports for today
About 8 or 9 so far all based on this weird happening
3 apps to run ONE LINE of code and to create a sqlitedatabase?
Its not JUST one line
I’ve tried slimming it down to a small app that replicates this behaviour without success
But I can run the app in r3.1 and it logs what I expect
Basically I have a system.debuglog at method enter & exit
And in R4 those message do not appear - as if those methods are no longer being called
IF I could slim this down to a smaller app I’d submit that
So far no luck
Well I’m starting to figure out whats wrong here
- API 1 style code may be accepted, translated to Kotlin, & wont compile correctly frequently causing Android compile errors
- some of this code wont cause a compile error but just DOESNT function and may, or may not, raise an exception that is shown in the debugger right at the sire that raises the exception
- app.unhandled exception may catch the error
basically Android behaves VERY differently from every other target
but the main purpose of Xojo is write once, run many… So that ALL platforms behave the same
1 Like
Xojo’s homepage is a bit scammy, implying that it’s cross-platform. Interesting how they qualify that it’s the same IDE / language. That’s not really cross-platform.
FileMaker runs on Mac, Windows, Web, and iOS all with the same ‘code’. That’s much more cross-platform than Xojo.
This is why I now build web apps that can run just about anywhere. With Xojo, I’d have to do so much more work. ( Yes, I know Xojo has web too, but Xojo Web 2 mean having to rebuild my app and I was worried about Xojo Web 3 requiring a rewrite someday in the future… )
2 Likes
the posting dropped by [sarcasm] tag
1 Like
yeah not
in android you have to worry about what Kotlin requirements leak out
For instance I have a class that when created you use it to do logging of when you created the object, any intermediate log writes & then when it goes out of scope it logs its destruction since thats usually the exit point of the method
You’d use it like
dim logger as New Debug.Logger = CurrentMethodName
And this works fine since it has an operator_convert from a string
So this initializes the instance
This doesnt work in Android at all so I have to swap that for a constructor
Not a huge hit
But what I ran into last night I object destructors DO NOT seem to EVER get called
And so this safe little object that would log the exit regardless of how it went out of scope no longer functions as expected
Thats just the tip of the “Xojo for Android is not the same as Xojo anywhere else” iceberg I found yesterday
NOT fun
EDIT : turned autodestroyed “samosa” into “same as”
Xojo Inc‘s ‘we abstract you from platform specifics’ marketing going down in flames.
1 Like
Mmmmm. Samosas. 
2 Likes
yeah that is kind of an amazing auto destroy replacement for “sameas” without a space
now I have to go eat lunch !
samosa’s sound good
2 Likes
Has your client considered Flutter or even SwiftUI (with the Kotlin transpiler)?
Flutter & Dart are on the maybe list since we could get an iOS & Android app from one source
1 Like
B4X?