Will API 2.0 for iOS give us full functionality of all things Xojo in iOS or will it be lipstick on the pig?
So in iOS you have no RegEx (community created version excluded), no UDP socket, incredibly limited and horrible TCP socket, etc. Is Xojo just putting a new API into all these current iOS objects with no real improvements or is there actually going to be changes that make the iOS platform more usable and easier to use?
I ask because right now, the current iOS framework, controls, debugger, exception handling, etc. is absolutely atrocious. I can’t believe it’s existed for as long as it has in the state that it is in. I’m sure hoping the API 2.0 is actually going to make real substantive changes and not thinks like:
DIM is nor Var
RecordSet is now RowSet
Join is now String.FromArray (oh that’s right - heaven forbid you try to use string in iOS).
We don’t know what the future will bring until we can test it.
Reading the https://documentation.xojo.com/resources/roadmap.html I think an even bigger change will be “Interops - iOS”
API 2.0 for iOS: A new set of APIs that are API 2.0-compliant making it easy to share code with your desktop, web and Android projects. It makes sense that people will be able to use String and other things, if not, then it would not be easy to share code with desktop, web and Android projects.
[quote=478379:@Alberto DePoo]We don’t know what the future will bring until we can test it.
Reading the https://documentation.xojo.com/resources/roadmap.html I think an even bigger change will be “Interops - iOS”
API 2.0 for iOS: A new set of APIs that are API 2.0-compliant making it easy to share code with your desktop, web and Android projects. It makes sense that people will be able to use String and other things, if not, then it would not be easy to share code with desktop, web and Android projects.[/quote]
I understand that. But all a new API does is make the calling of the function between different platforms compatible. So let’s take a TCPSocket. There’s a world of difference between the TCPSocket in Xojo Desktop/Web and the XojoFramework for iOS. Examples are that for some insane reason, Xojo decided to requite the end user to put everything in a memory block when reading or writing. That was just lazy coding because nearly everyone will want to translate that memory block to text (or better yet - string). Another example is that the iOS TCP socket doesn’t have a listen method (and it may not either depending on Apple’s position on that).
Another thing is there’s no UDP socket in iOS. iOS devices do use UDP, so it should be an available class. But if Xojo just creates new “compatible” API’s between the iOS Framework and Desktop and doesn’t fix the underlying hoard of problems with the iOS framework, it will be a disaster…
It had nothing to do with them being lazy. Xojo was trying to fix a very specific problem (that many developers struggled with for years and blamed Xojo for their lack of understanding) with the String datatype that didn’t fit in well with comms and came up with Text as the replacement. In classic API a string is a ‘bag of bytes’ while Text is a collection of characters (always with an encoding). A string may or may not have an encoding and that can really screw some things up with data coming from outside your application. So the iOS way is to have a MemoryBlock (bag of bytes) and when you convert it to Text you must tell it what the encoding is.
Text makes working with emoji’s very easy. Emoji’s with Strings is not as easy. To call anyone’s efforts ‘lazy’ is to disregard why they came up with it in the first place. It was obviously a pain point from a support standpoint and therefore they came up with a solution. Obviously that solution didn’t fit well with our expectations and they are going back to String. But I expect them to keep using MemoryBlocks since it still solves the support issue they were having.
I’m not an expert on this and @Norman Palardy can explain it better than I can.
[quote=478407:@Emile Schwarz]The question is:
Do I need to code an iOS application NOW ?
Can I wait sometimes until API2 will be released ?
Depending on the answer, you act.
Also, past have its importance in what will come.
When I was working at Apple, that was my answer; if you need a computer right now, buy one that is available; else wait until a new release.
Remember: the wait can be long, very long.[/quote]
Im coding now because I need to develop this app for a customer. Im finding out the myriad shortcomings of the iOS framework. Im wondering if someday Ill be able to work with a far better framework in IOS API 2 or if it is just the proverbial lipstick on a pig.
From what I’ve gathered from various conversations, InterOps will make a lot of iOS coding a lot easier. However, until we see it in action we have no idea what kind of hoops we’ll have to jump through.
Take Desktop API2 as an example of what you can await from API2 for iOS
Also: do not change of development while you are developing a new application: it will increase dramatically your development time without guaranties for success.
This is just a project in the Ether. Wait if you do not need it now.
But you need a solution NOW. Search elsewhere, make your mind and you will be ready for the next project.
If you wait and do not get answer at XOJO CONNEXT in three weeks, you will waste 21 days
Indeed, After trying to put a lot of efforts in Xojo iOS, I ended up giving up when I realized in two years time, almost nothing had happened. It seems lately Xojo has finally decided to put more love into it. Yet without the patient efforts from users like Jason King, Jean-Paul Devulder, Ulrich Bogun, and Jeremie Leroy, the platform is downright toyish. Most of what makes the Xojo Desktop and Web platform so powerful is simply not available.
I do hope that interops become available at the same time or soon after Xojo iOS with API 2.00.
About API 2.00, I do hope Xojo starts implementing it with all methods and properties as close as possible to Desktop, so true code portability happens naturally, and not after a whole of of surgery and declares. If Xojo iOS where to remain so dismally limited, API 2.00 would indeed be lipstick on a pig…
IF, and this is a big IF, all API brings to Xojo for iOS is new event and method names then I would consider it having fallen way short of where it needs to be.
iOS uses Text instead of String - and that difference should be corrected if/when they do API 2 otherwise API 2 for iOS is going to just change names of events & methods and still leave code incompatible between desktop and iOS since you wont use the same types.
That doesnt strike me as that useful
API would need to move to compatible data types and method / event names to really make a big difference to iOS
Never mind making classes like memoryblock, tcp socketc etc etc etc much more similar
I am confused as to what the big deal is concerning “TEXT” and “STRING”. From what I see there is a difference only because Xojo decided to make it different. They could have (and in my option should have) made it 100% Transparent to the developer. The under-pinnings of the two datatypes are different … that I get… but how the developer interacts with either should not have changed… expanded or enhanced … sure, ok… but all the existing functions of a “String” apply equally to “TEXT” (barring the namespace/syntax changes). For iOS I write alot in Swift, and it has a “STRING” datatype (it doesn’t call it “TEXT”), and I use it almost identically to the way I use a “STRING” datatype in Xojo… So why complicate things, (I mean, didn’t Geoff say he wanted to make it easier for Newbies (sorry that was sarcasm)
Text was, as Bob indicated, meant to be “textual data” - ALWAYS - and never have the dual behaviour that string has where it is sometimes a bag of bytes and sometimes textual data
String is often used as either / both
So you end up with TCPSocket.Read in the classic API with a signature like
Read(Count as Integer[,Enc as TextEncoding]) As String
but you dont get textual data - you get a pile of bytes of unknown encoding etc (basically a memoryblock but …)
Not really since “text” is NEVER a run of bytes where String may be
So Midb, LeftB etc, which are meant for manipulating a string as a bag of bytes dont really work well on “text”
Text basically operates on “user perceived characters” - not bytes
Trying to remove this dichotomy was vocally panned yet there are numerous bug reports about exactly this problem (and many forum threads that this turns out to be the problem) - String may NOT contain textual data or it has textual data with an unknown encoding. There are blog posts about this problem. And it persists because people think “String” means “textual data” but that is NOT true in the classic framework.
@Norman Palardy : that may the be case. But then I need all the functions for text also for memoryblocks. My emails are textual data. However, until I have sliced and diced the data it may contain garbage. But I need a left and not a leftb. There are no split or join. How am I supposed to work with my emails in the memoryblock world?
there’s no point trying to relitigate the whole text vs string issue
This was about API 2 - which uses string, not text.
If all API 2 for iOS does it rename methods and not bring the datatypes into alignment then it wont make code any easier to share with iOS
Like Norm says, without bringing String and Variant to iOS and adding in some of the core classes from the desktop framework (RegEx Im looking at you) iOS will remain unusable for me.
You know that iOS has auto (works similar to variant but requires explicit casting) and iOSKit contains a full Regex implementation of what is provided by Apple abstracted to work like Desktop Regex does, right?
The module is called JKRegex so you can have a using JKRegex at the top of any function needing it, and when Xojo adds their own support you can then find and delete those using statements so it will just work assuming the iOS API is the same as Desktop.
Xojo.Core.Date ? DateTime (iOS lacks the timezone, effectively making it impossible to write accurate astronomy apps)
Some trig functions are supported in iOS (sin, cos, tan) but not others (asin, acos, atan and atan2)… OOH nooo… have to prefix these with Xojo.maths… why ?!?
[quote=478540:@Norman Palardy]data types will be a problem since iOS and desktop do not use the same types
text ? string
Xojo.Core.Memoryblock ? memoryblock
and so on
renames of events & methods would only be scratching the surface
that was my point earlier[/quote]
Indeed, unless iOS implementation allows plain and simple copy/paste of code and have run as on Desktop, API 2 will still be lipstick on pig.
Furthermore, equivalent methods and properties should be exposed the same way in desktop and iOS. This includes plain properties such as width, height, left, and top. The fallacious argument that auto, layout must be used is a hoax: XCode by default uses width, height, left and top. The systematic use of convoluted constraints is a cruel result of “we know best” attitude.
Unless Xojo realizes that they are not only late to the party, with dozens of competition products, but imposing idiotic auto layout as default is a repellent for users, not to mention a definite thorn in any pretends for true cross platform. Auto layout should be optional, not default. Just like in XCode.