In the old framework, I used the FolderItem.Launch method to run the just downloaded update installer for my app immediately before quitting the app. Launch is not available in the new framework so I am creating an old framework folderitem and launching it. Is this the best way to accomplish this? I was hoping to slowly move my app to the new framework, but this is a step sideways rather than forward.
There was recent discussion that Xojo was going to roll-back the “new framework”…
So if it were me… I’d just stay with what works.
Note : for iOS there is no “launch” and most likely never will be,
Forget the new framework for files, and for many things. Apart from Xojo.Net.HTTPSocket which supports HTTP 1.1 instead of 1.0 for classic, or the Text type if you have to deal with composited accents, it is simply no good, unfinished and cumbersome.
The new framework appeared with Xojo iOS, which has nothing else. A major mistake if you ask me, since it broke all kind of cross platform compatibility. I don’t know who was smoking what, but the result is not pretty…
Don’t worry about it, Xojo has officially given up on the new framework. See https://blog.xojo.com/2018/04/25/xdc-2018-keynote-recap-draft/ under “Xojo API 2.0” for what little details we have.
Thank you Thom.
I am so glad they seem to have to finally seen the light. My work with XojoiOSWrapper to bring classic syntax to new framework’s iOS had showed me how ridiculous insisting on a new syntax and naming was. For the most part, the new framework basically offered only dot syntax where classic had offered for years parenthesis and dot together. It looked very much like a loss, and not an improvement.
I just hope eventually, mobile platforms will not be so ridiculously incompatible with decades of previous desktop development. The huge advantage of having code compatible since the early 2000 with current Desktop Xojo was simply blasted away by the (probably hasty) choice of a new framework systematically incompatible in naming and syntax. It is amazing for people so conscious of not breaking existing code, to have gone so wild and break literally everything on iOS.
The new framework is just another soon to be extinct evolutionary branch. The framework equivalent of the Neanderthal, the Denisovan or the “java Man”. I am sure they were all nice and intelligent, but the better adapted species prevailed and continued to evolve (although some specimens on street corners put that assertion to test…). 2.0 promises to be the framework sapiens.
If you specifically mean the Xojo framework for iOS project, that is probably true. But if in general you mean it is not possible for one iOS application to launch another one, that is not true. Apps can register what amounts to a URL protocol name (the part before the :// in a URL). You then open that URL from another app (or the iOS browser) and it launches the program for you.
And then what gets passed beyond the protocol name in the URL can be detected by the app and be used similar to command line arguments in a console or desktop app.
I just wanted to be sure for the sake of archive searches it was clear it is not iOS which will not let you launch another app. It is the Xojo framework which does not have a Launch method in the iOS framework.
Indeed, launching another app with it’s ID is just as possible in iOS as it is in macOS. It is probably just a declare away. Well, almost, it needs a callback that may not be that easy within Xojo.
https://stackoverflow.com/questions/11976624/launching-an-ios-app-by-app-id
On macOS, Christian has an MBS plugin that does that.
[quote=386783:@Michel Bujardet]Thank you Thom.
I am so glad they seem to have to finally seen the light. My work with XojoiOSWrapper to bring classic syntax to new framework’s iOS had showed me how ridiculous insisting on a new syntax and naming was. For the most part, the new framework basically offered only dot syntax where classic had offered for years parenthesis and dot together. It looked very much like a loss, and not an improvement.
I just hope eventually, mobile platforms will not be so ridiculously incompatible with decades of previous desktop development. The huge advantage of having code compatible since the early 2000 with current Desktop Xojo was simply blasted away by the (probably hasty) choice of a new framework systematically incompatible in naming and syntax. It is amazing for people so conscious of not breaking existing code, to have gone so wild and break literally everything on iOS.[/quote]
From what I’ve heard from XDC attendees, Android will use the classic framework and iOS will get access to the classic framework eventually. That means for now, if you need iOS, you still need the “new” framework.
My guess is this “API 2.0” is really just slowly evolving the current/classic framework. This is really a naming nightmare.
I have no inside information, but I expect to see changes such as:
- Deprecate InStr and String.InStr in favor of String.IndexOf just like Text has.
- Deprecate the global functions like Left, Right, and Mid in favor of the extension methods already on String.
- Deprecate HTTPSecureSocket and transition HTTPSocket to use the same backend that Xojo.Net.HTTPSocket uses.
- Deprecate synchronous HTTPSocket requests.
- Deprecate FolderItem.Item in favor of a numeric overload of FolderItem.Child.
- Bring over Xojo.Core.DateInterval (renamed, of course) as an optional alternative to date adjustments.
- Bring over Xojo.Core.TimeZone because this should have existed ages ago.
- Improve JSONItem’s performance to match Xojo.Data.
- Possibly some form of Mutable and Immutable MemoryBlock like the “new” framework has, as there is significant performance improvements in using an immutable MemoryBlock if you don’t need to edit it.
Probably a bunch of others. Or I could be way off base. These changes would break some things for some people, but would be much easier to deal with rather than breaking everything for everybody.
This should not happen… (for the most part)… for at least two reasons I can think of off hand.
- Will make it (slighty) more difficult for “newbies” to transtion (not to mention all of us who did it the “old” way)
- Will require “all of us who did it the “old” way” to re-engineer legacy code for no good reason
InStr, Mid, Left, Right should remain, both as functions and string extensions, ADDING “indexOf”. The older functions could be modified to internally call “indexOf” if it make the compiler more effective.
Basically, if it is in Xojo now, leave it (at least from a Syntax point of view). Add/Overload as desired… Because you know darn well otherwise, some of us will be writing libraries (like Michel mentioned above), and that doesn’t work well in most environments.
While on this subject. Add a “COUNT” extension to Arrays (ie. UBound-1)
Indeed, the super quality of Xojo is its stability, and code perennity. The VB code I had back in 2000 is no longer usable by current versions of VS. I can still open a project from 2001 with the very latest version of Xojo.
This is truly a huge competitive advantage. Most other languages are so fluctuant, they are a nightmare to maintain.
Like I said, they are just things I expect to happen, it doesn’t mean I’m right.
As for IndexOf/InStr, the purpose is not simply naming, IndexOf would return 0-based values instead of the 1-based values of InStr. Since I doubt we’d see an IndexOf global method, moving everything to extension methods would be the consistent thing to do, which is why I expect they’d go that route. They’d probably convert Mid to SubString so that can become 0-based as well.