iOS requires “Text” instead of “ String” - etc
exactly - those fundamental data type differences have to be sorted out at some point before iOS can really have code that is truly interchangeable with the other targets
Xojo.IO.FolderItem isnt Folderitem
Xojo.Core.Dictionary isnt Dictionary
and so on
Stupid question: what is the difference between xojo.io.folderitem and folderitem?
Isn’t that why we use Xojo? We expect the nitty gritty to be abstracted.
According to the Xojo roadmap, we can expect API 2.0 for iOS somewhere around r2020r2.
https://docs.xojo.com/Roadmap
Potentially. I would certainly be very disappointed if we don’t see it this year…
I would be surprised to see it this early in 20202 and would expect more like 2021 sometime
Web and Android will take some time to get out the door still and settle down
I hope you’re wrong @npalardy. iOS is screaming out for better parity with desktop. It’s currently as good as impossible to maintain a cross platform (iOS and desktop) library if you want to support API 2.0 (which is what Xojo is pushing).
Parity across desktop web etc has been problematic since iOS was introduced (unfortunately) as the rapid expansion of the Xojo framework didnt happen.
Revamping iOS to use the standard types would have to happen to make it possible to have code that is more portable across all targets. Thats not a trivial task. Text is quite different from todays String. The same is true for many other types like dictionaries, auto vs variant etc
And those HAVE to be sorted out to make for portable code
Renaming methods can proceed once those types are made to be the same and have similar capabilities.
The changes to the underlying intrinsic types is quite a big job and its one reason I think API 2.0 wont land on iOS for some time
I see your point, but I hope you are wrong, Norman.
Android was placed below iOS API 2.0 now, so there is at least a chance for a usable Xojo iOS around end of the year.
I guess it really depends on what they are planning to deliver as “API 2.0”
That may just be updated names for methods, properties, and events and no chnages to data types. That would still make iOS its own little island and be of limited utility since code from iOS would use types that desktop & web do not. I dont think that would delier the kind of consistency that seemed to be assumed would come from API 2.0
A larger shift of types, as I mentioned, might be a lot bigger project.
The other thing to note is the roadmap has NO dates on it quite deliberately.
API 2.0 for iOS could still be a 2021 deliverable (which might mean android is further out than that)
When it comes to parity, I’d settle for the introduction of String and Variant to iOS. That would get me 90% of the way to where I currently need to be. I know they are both big asks though and are far bigger challenges than just writing extension methods and aliases. Working with text at a low level is really hard.
On a semi-related note, any idea why there is no RegEx class for iOS? It really seems like an oversight to me.
I agree that getting String and Variant there are decently big asks - esp since string supports a dual nature that Text does not
But in order to not JUST have renamed items they need to be there
As for Regex since it was already built into iOS porting the existing PCRE based code was unnecessary. But then the system one was simply NOT wrapped up in a way that regex would work similarly and permit you to write code that worked on desktop & iOS
API 2.0 more difficult?
Not really, but far more time consuming (check everything in the LR).
Conclusion:
what new stuff mus I learn ?
(Xojo or Swift or <?> ?)
Xojo if you want to make Mac, Windows, Linux, iPhone, iPad, Android apps.
Swift if you want to make iPhone, iPad, tvOS, watchOS apps*.
*iPhone, iPad apps will “just work” on ARM Macs, so you don’t need to worry about making an app for the Mac anymore.
Unless you want to do stuff that doesnt have an equivalent from iOS 
Not stupid ant all. Looks like they dont understand about bstractaction. What IS stupid is to create new things, like TEXT instead of making the changes under the hood for different targets.
1 Like
Sssshhhhh!!! Or they’ll take that away from us macOS developers, so the iOS devs don’t feel left out.
the point of those two was to be able to have 2 very similar, but not identical class, that did a lot of similar things and be able to use them side by side and NOT force you to hav to update your code
That was 1 goal of the Xojo namespaced stuff
You could use the code side by side and update incrementally
And Xojo could adopt much newer os level API’s without breaking your code in the process (like folderitem had done at lest 2x before)
As well Xojo could add new things that would not just take over some global name and clobber your work (like they did with the change to Label from StaticText)
As well types that were the source of endless user bugs could be split into more clearly delineated bits (text and memoryblock instead of one dual natured beast like String) That way TEXT was ALWAYS textual data and things operations that made sense on TEXT (like describing like character oriented operations) could be done to TEXT in a way they didnt clobber byte wise operations
It was an attempt to make it so long term YOUR code was more correct just by writing it
You have NO idea how many bug reports there are about "gee I read this data from a serial port and now when I put it in a text area it has these weird characters in it. So many Joe wrote a blog post about it because it came up over & over & over regardless of how many times we could say “did you define the encoding” - and then we could get their code and there is ConvertEncoding … no no no no no
Or variants … OMG !
That is started out really wordy was a side effect - The Using clauses were designed to make it so you didnt have to do that - the IDE just wasnt there yet with autocomplete etc
EDIT : unfortunately the complaints about this framework are, in part, what led to API 2 being created 
Hi folks! First time caller, long time listener here. I go way back to the REALbasic days and have mostly been a lurker although I posted an occasional email back in the NUG days.
Regarding API 2.0, yes, can this be any harder?!? Only recently have I started dabbling with the new frameworks, but heck trying to coerce Strings and Text has been a real pain! 
It’s definitely NOT like Swift where Apple’s first class bridging between NSString and String is mostly seamless.
I was recently using Xojo.IO.FolderItem.DisplayName and was trying to drop off the filename extension. Figured it would be as easy as NthField, but alas tons of problems including casting things as Strings or even Text wouldn’t work. In the end I acquiesced and simply ended up extending Text to a method that used Split.
Here’s hoping that at one time or another down the road things smooth out a bit with API 2.0.
Welcome Patrick !