Im really frustrated with the whole string and text among other api inconsistencies among target platforms. My frustration is with code reusability across the different targets.
I was hoping to get some opinions on code reusability in particular with IOS projects.
I could move all my code to use TEXT, but then with API 2.0 “string” is the winner, for example URLConnection.
I find myself having to re-write a lot of my modules for iOS, I even made a polyfill class named “str” which I use instead of TEXT and STRING.
right know I have a new project and this one decision is killing me, should I worry about API 2.0 changes?
We know very little about API 2.0. We found out at XDC that String won over Text (because they’re totally not the same, but Text does have it’s uses, I hope they find a way to keep both but used appropriately).
The rest of API 2.0 is still unknown to us. Some parts are probably even still unknown to Xojo.
When things get marked as deprecated with replacement, that is the time to start updating your code. At this point, with the exception of bending over backwards to use the iOS product; stick to the classic framework. We were told at XDC that API 2.0 would mostly resemble the classic framework but with more naming consistency.
Right now, only iOS requires the use the Text (unless you’re using the Xojo framework). Until we know more about API 2.0 it’s really hard to say what the end result is.
Regardless, like most changes in Xojo it will be a while before they truly remove things. It will be deprecated for quite a while before it’s removed.
[quote=419550:@Bob Keeney]Until we know more about API 2.0 it’s really hard to say what the end result is.
Regardless, like most changes in Xojo it will be a while before they truly remove things. It will be deprecated for quite a while before it’s removed.[/quote]
A discussion about what the problem is that Xojo is trying to solve, would be favourite.
Text solved a few issues. String can mean ASCII text, text characters with an encoding, or just a bag of bits. Text always means a number of characters with a known encoding. Over the years there was a lot of confusion as to what a String could be and encodings have been a PITA as long as I can remember.
If you look at the Xojo framework the and the sockets it always uses a MemoryBlock which is much better suited for data. Then you explicitly convert to and from the MemoryBlock. Whereas in the global framework the sockets simply use strings. So String isn’t necessarily text which is implied elsewhere in the framework. So the idea was to eliminate any confusion with Text.
The same sort of arguments apply to Auto in regards to Variant. Auto solved some rather important but subtle and obscure issues that have cropped up over the years. Variants can be implicitly converted to anything at any time whereas Auto’s once they get something put into them are that type forever. Auto is very lightweight but requires some work to figured out what the data type is.
It’s very technical stuff. I’m not the one to ask about the why. Xojo staff would be a better choice.
There are a lot of things I like from the new framework and i have a lot of code in the old framework, but mixing the frameworks has a lot of catch-22s.
I do speculate that this kind of choices are more mundane that what it may seem. For me managing UTF and encodings was never an issue. So i can only imagine that the internals of the current frameworks were an obstacle to implement IOS and thats what the new Framework comes to answer, IOS support.
I see XOJO core niche as a cross-platform that is as easy as it gets. IOS broke that.
IOS is a one-to-one mapping in XOJO. I was expecting abstractions and generalizations of functionality that would mirror to given degree on desktop, IOS and Android. And you could do that without hindering the ability of developers to reach to what the OS has to offer when need it.
I know XOJO is the only kid thats really compiling, but borrowing a bit from Xamarin, PhoneGap by implementing more abstractions is not that bad. i mean everything in XOJO does not have to be a one-to-one representation of the host platform.
I imagine that just a subset of generic widgets and UI elements would make a whole lot of people extremely happy.
Imagine if you could have views and panels that you could use in IOS, Android and your desktop app. Every time I see the “IOSButton” i just ask why!!! Even a lot of the abstractions can be done at the IDE level.