XDC 2019 API 2.0 session discussion

  1. ‹ Older
  2. last week

    Norman P

    May 12 Pre-Release Testers, Xojo Pro Freeport, Bahamas

    api 2.0 is for "code" - whether you use it or not will be optional for a long while
    it has to do with whether you use "Folderitem.Item(i as integer)" vs "FolderItem.Child(zerobasedIndex as integer)"
    That sort of stuff
    The IDE wont autoconvert that at all

    web 2.0 is for whole web projects - I doubt you'll have an option to stay with the old web framework when it finally ships
    I expect the IDE will offer to "convert" your existing project to the new format and from then on old IDE's will not be able to open it
    If you decline the conversion then the project wont open

  3. Rich H

    May 12 Pre-Release Testers, Xojo Pro

    Thank you Norm for your input.

  4. Greg O

    May 12 Xojo Inc

    @Rich H so now i have a question. what happens if i have a web project that i want to use in the latest version of xojo but do not agree to convert it. will it still load and run? what happens in this scenario?

    If you don’t convert, the project won’t open.

  5. Rich H

    May 12 Pre-Release Testers, Xojo Pro

    Thank you Greg for confirming.

  6. Greg O

    May 12 Xojo Inc
    Edited last week

    FWIW and for those of you who weren’t at the show, we’ve designed the new web framework so that more of the framework itself is open and extensible... so it can grow over time. Both by controls and extensions designed by us, but also by 3rd parties. Unfortunately that basically meant starting over from scratch because extensibility was an after-thought the first time around.

    One thing that has been on our minds from the beginning was that we wanted your experience of creating SDK controls to be as close to ours as possible. For instance, WebFileUploader has been split into two parts, the UI and the upload engine, and our basic UI control hooks in just the same way WebSDK controls will.

    I also showed an example of a custom column renderer for the new WebListBox at XDC this year. For example, adding one that renders data as links involves only about 15 lines of JavaScript code.

    As I said though, all of this extensibility comes at a hefty price. Web 2.0 projects simply cannot be backward compatible. Just the same, I am excited to be working on this new and innovative approach and can’t wait to see what kinds of things our customers will create!

  7. Wayne G

    May 12 Pre-Release Testers, Xojo Pro New Zealand axisdirect.nz

    @Greg OLone, it would be great if your session was also available on Youtube, but maybe Web 2.0 is not as soon as API 2.0. Although both are obviously large projects API 2.0 can be delivered in tranches, Web 2.0 & Android target seem to be all or nothing.

  8. 7 days ago

    Joost R

    May 12 Pre-Release Testers, Xojo Pro The Netherlands
    Edited 7 days ago

    @Wayne G @Greg OLone, it would be great if your session was also available on Youtube,

    Which would be great and making this information available to us who were not able to attend XDC creates a lot of goodwill, positive involvement and the willingness to test and incorporate the improvements and new features in our existing projects.
    Forget selling video's, this is the way to go.

  9. 6 days ago

    Kevin G

    May 13 Pre-Release Testers, Xojo Pro Gatesheed, England

    @Greg OLone One thing that has been on our minds from the beginning was that we wanted your experience of creating SDK controls to be as close to ours as possible.

    Out of curiosity, why isn’t the process for 3rd party’s creating web controls not exactly the same as Xojo Inc’s? Do Xojo Inc’s web controls not use the same SDK?

  10. Greg O

    May 14 Xojo Inc

    @Kevin G Out of curiosity, why isn’t the process for 3rd party’s creating web controls not exactly the same as Xojo Inc’s? Do Xojo Inc’s web controls not use the same SDK?

    You mean now with the current web framework? Because the original design (before I started here) didn’t even consider an SDK. When we decided we needed one in Fall 2011, we had to retrofit the framework to allow it.

    This time it’s a different story. We had an opportunity to make web control creation significantly less painful and the nearly the same for Xojo and our users at the same time, and we took it. Some of the IDE improvements even proved so useful that they’ll be available sooner than the web framework.

    FWIW, the WebSDK isn’t only about creating controls from scratch this time though. It’s also about creating control extensions. As I said above, the uploader engine is available to anyone who wants to create an uploader skin without having to recreate the mechanics. The new listbox supports custom column types, an example of which I showed in my XDC presentation this year. Text field formatters and validators are also extendable. As development continues, we are constantly looking for ways to make it so 3rd parties can extend parts of the framework this time... while making it unlikely that you’ll break your (and others) projects at the same time.

  11. Kevin G

    May 14 Pre-Release Testers, Xojo Pro Gatesheed, England

    @Greg OLone You mean now with the current web framework? Because the original design (before I started here) didn’t even consider an SDK. When we decided we needed one in Fall 2011, we had to retrofit the framework to allow it.

    This time it’s a different story. We had an opportunity to make web control creation significantly less painful and the nearly the same for Xojo and our users at the same time, and we took it. Some of the IDE improvements even proved so useful that they’ll be available sooner than the web framework.

    FWIW, the WebSDK isn’t only about creating controls from scratch this time though. It’s also about creating control extensions. As I said above, the uploader engine is available to anyone who wants to create an uploader skin without having to recreate the mechanics. The new listbox supports custom column types, an example of which I showed in my XDC presentation this year. Text field formatters and validators are also extendable. As development continues, we are constantly looking for ways to make it so 3rd parties can extend parts of the framework this time... while making it unlikely that you’ll break your (and others) projects at the same time.

    Sorry, I meant Web 2.0. It seems strange that Xojo would implement their Web 2.0 controls using a different method to 3rd parties. Wouldn't it have been better to have one Web 2.0 SDK that was used both internally and externally.

  12. Greg O

    May 14 Xojo Inc

    @Kevin G Sorry, I meant Web 2.0. It seems strange that Xojo would implement their Web 2.0 controls using a different method to 3rd parties. Wouldn't it have been better to have one Web 2.0 SDK that was used both internally and externally.

    For some things that’s quite possible... for others, not so much. Remember, not only are our controls user facing like yours, they are also the hierarchical dependencies and underpinnings of those controls.

    FWIW, most of the controls we’ve created this time are just like the SDK, it’s just that they’ve been created before the first draft of SDK itself is done.

  13. Tim S

    May 14 Canterbury, UK

    I hope Xojo isn't going to go too overboard with this exceptions-replacing-error-codes business. Should I be expecting a "string-not-found" exception rather than getting -1, if the needle isn't found in the haystack:

    offset = haystack.IndexOf (needle)

    To me, an exception should occur where there's a definite coding error. So I hope I don't see an exception if the remote end closes a socket unexpectedly. I'd rather get error code 102.

    Otherwise I can see try/catch around every statement, which won't help readability.

  14. Norman P

    May 14 Pre-Release Testers, Xojo Pro Freeport, Bahamas

    @Tim S Otherwise I can see try/catch around every statement, which won't help readability.

    Java had this issue as well as it uses exceptions for so much.
    So people just got into the habit of catching everything - regardless - which is just as bad as never checking error codes.
    BUT, the one thing you cannot do with exceptions is just ignore them like you can an error code.

    A language can only encourage good safe coding - it cant enforce it
    But it an make it harder to ignore errors

    As for

    offset = haystack.IndexOf (needle)

    IF your code used to be something like

    offset = haystack.IndexOf (needle)
    if offset >= 0 then
      // do a whole bunch of code with offset since we know this exists
    end if

    now it might look like

    try
    offset = haystack.IndexOf (needle)
    
      // do a whole bunch of code with offset since we know this exists
    catch oobx as OutOfBoundsException
    end try

    In many cases you probably can just rearrange code and skip deeply nested if's

  15. Bob K

    May 14 Pre-Release Testers, Xojo Pro Kansas City

    No, in your example returning -1 is expected (and normal) so therefore not an error and not an exception.

    We don't know exactly how they'll change everything but a socket disconnect is an event, not an error as it's normal. Frankly, I don't think it should have ever been an error but it is what it is. So we'll have to see in API 2.0.

    At the end of the day API 2.0 will be an adjustment to our coding styles. Many (most?) of us have NOT been checking for Error Codes when it comes to FolderItems, Text Input/Output Streams, and Databases (despite me writing about it every year for 10 years) anyway, so they're taking this opportunity to change the framework so that we *must* pay attention to error errors or the app will quit.

    There will be grumbling for a (long?) while and those of us with a large code base will complain the loudest no doubt.

  16. Tim S

    May 14 Canterbury, UK

    In the 80s I wrote a medium sized multithreaded appin C which ran under VMS on a MicroVax. It used to run 9 months at a time with no page faults over and above the 6k or so that happened at startup. It "only" ran 10 months at a time because once a year, the 250kV line that powered the site was shut down for maintenance and the 64kV backup used instead. Then another site-wide power outage 2 months later when they switched back.

    So I know about checking error codes.

  17. Bob K

    May 14 Pre-Release Testers, Xojo Pro Kansas City

    @Tim S So I know about checking error codes.

    The collective 'we' do not. I see about 2 dozen OPC (Other People's Code) projects every year. Most have no error handling at all and most don't even handle app.unhandledexceptions.

  18. Norman P

    May 14 Pre-Release Testers, Xojo Pro Freeport, Bahamas

    If its harder to miss checking for an error the likelihood everyone will check for them goes way up

    The only downside to exceptions is that you can only check that you have handled things at runtime - there's no compile time way to ask the compiler for "did I handle the exceptions that could be thrown ?" unlike java where methods have to declare what exceptions they throw so the compiler can warn you about them not being handled right then.

    Which forces you to very thorough code testing

  19. Karen A

    May 14 Pre-Release Testers

    @Norman P now it might look like

    try
    offset = haystack.IndexOf (needle)
    
      // do a whole bunch of code with offset since we know this exists
    catch oobx as OutOfBoundsException
    end try

    I certainly hope not!
    A search result of not found should not be an exception it is an expected possible result of a search... There are cases where you don't know if something is there and you care checking if it is to decide what to do...

    Using exceptions for that would slow down code needlessly (and under the hood speed should ALWAYS be a consideration if they want Xojo to be competitive) ...

    If API 2.0 throws exceptions for things that are really not exceptional like that, or causes overall causes your code to execute slower, API 2.0 will be received less well that the Xojo namespace framework!

    Basically I am saying not to go overboard... Sometime being too ideologically pure gets in the way of productivity...too much of a good thing is not aways good... the right balance is needed.

    - karen

  20. Norman P

    May 14 Pre-Release Testers, Xojo Pro Freeport, Bahamas

    @Karen A I certainly hope not!
    A search result of not found should not be an exception it is an expected possible result of a search... There are cases where you don't know if something is there and you care checking if it is to decide what to do...

    reread my comment - I said IT MIGHT LOOK LIKE
    Not it must look like
    It was meant to be simple illustration of what code could look like
    I have no idea if they will make IndexOf or whatever replacement throw an exception or not

    I prefer a lot fewer deeply nested if's where the "normal" code flow is just a series of statements one after the other and the error handling elsewhere rather than the error handling surrounding all the code I really want to focus on

    @Karen A Using exceptions for that would slow down code needlessly (and under the hood speed should ALWAYS be a consideration if they want Xojo to be competitive) ...

    you should say "it might slow down code" - not it WOULD
    I expect that it wont slow it down but I dont expect you to know the details of why that is my expectation - thats way under the hood removed from most everyones view anyway
    Joe would need to be around to do a long laborious explanation of zero cost exception handling
    The only time it _might_ be slower is when the exception happens - which should be unusual ; not routinely expected

    @Karen A If API 2.0 throws exceptions for things that are really not exceptional like that, or causes overall causes your code to execute slower, API 2.0 will be received less well that the Xojo namespace framework!

    only if you make a bad assumption about how exceptions work and the speed of handling them etc but ......

    @Karen A Basically I am saying not to go overboard... Sometime being too ideologically pure gets in the way of productivity...too much of a good thing is not aways good... the right balance is needed.

    The complaints about the new framework effectively killed it despite all the things that it made much cleaner and made possible (like being able to do a better job of stripping out unused code in your compiled projects, better text handling with multibyte characters, and even the user of newer API's for Folderitems)
    So now we have API 2.0 which will, every time Xojo adds a new class, function, keyword etc possibly clobber your project because they've taken over something you used as a name in your code (which the new framework would not have)
    Just like when statictext turned into Label and then everyone had to replace that in their code
    I'm sure this can can happen to API 2.0 as well given enough time & effort & dedication

  21. Sascha S

    May 14 Pre-Release Testers, Xojo Pro Germany
    Edited 6 days ago

    @Karen A If API 2.0 throws exceptions for things that are really not exceptional like that, or causes overall causes your code to execute slower, API 2.0 will be received less well that the Xojo namespace framework!

    Not necessarily. Imagine it like this:

    Today: An event occurs. Check if there's a 0/ok/good/.. result and if there's none, check what kind of result it is and handle it.
    API 2.0: An event occurs. Check if there's a 0/ok/good/.. result and if there's none, check what kind of result it is and handle it.
    Until the moment it is checked for if something is ok, nothing changes. And therefore the performance should be the same.

    As Norman said:

    @Norman P The only time it _might_ be slower is when the exception happens - which should be unusual ; not routinely expected

    In short; Xojo will not check if this or that error occurred, but if everything went fine. And if it did not went fine, it will check what happened and throw the exception at you. ;)

or Sign Up to reply!