I could just change the Super of App to Mobile Application, but couldn’t do that with the events. They had to be recreated.
An iOSView would not allow changing the Super to MobileScreen, the view had to be replaced with a new screen. Again, the events had to be recreated.
An iOSTable would not allow changing the Super to iOSMobileTable (interesting this is not just MobileTable), so it had to be recreated. Again the events had to be recreated.
Methods are also deprecated all over the place, so you have to hunt them down with Analyze Project and make sure it’s not more than a name change.
Luckily, I’m doing this in a new project I recently started, so I don’t have that much to change. But I can’t imagine doing this in older projects where I have dozens of views.
I’m also staring at going to String after being in Text for all my projects.
You don’t need to change it all. The old iOS classes are still there and will be for the foreseeable future. You can mix and match new and old. I have it done in my app and I have no issues.
Art, this wasn’t my experience of converting a large iOS project to use API 2.0: I was able to change the super of App, iOSView, iOSTable, iOSButton, etc. I did this during beta testing so there’s a chance that something has changed since then, but it worked well for me a few weeks ago.
What I did find frustrating was the lack of a way of converting an old event handler to its modern equivalent. I totally get why that shouldn’t be done automatically by the IDE, but it would have saved some repetitive clicking if I was for example able to right-click on the “Open” event that was brought across from an iOSButton and be able to change it to “Opening”, “Action” → “Pressed”, etc. But changing the super worked well.
An iOSTable would not allow changing the Super to iOSMobileTable (interesting this is not just MobileTable)
I’m guessing that wherever we still see iOS in the name of a class, there are sufficient differences from the Android equivalent that Xojo have decided they need to be handled slightly differently. Maybe there’ll be a MobileTable class with some common properties and methods, with iOSMobileTable and AndroidMobileTable subclasses that handle the platform-specific stuff
I’m also staring at going to String after being in Text for all my projects.
I found this part relatively straightforward because at least the Text methods share the same indexes as the API 2.0 String methods.
For me the biggest issue by going from iOS to Mobile is that we can’t use @Jeremie_L iOSDesignExtensions and @Jason_King iOSKit any longer. Without that, a decent looking iOS app with Xojo is impossible.
FWIW, I was able to convert the iOSDesignExtensions that I use to work with MobileX classes without any problems. I only use a few colour setting methods.
