The New Xojo Framework

Xojo, Inc. has talked a lot at XDC (Xojo Developers Conference) about their new upcoming framework.  The reasons for a new framework are many and valid.  Among them are consistency, a need to serve desktop, web, and soon to be iOS applications, and to remove archaic methods.

This sounds kind of scary because most of us have been using the existing framework for many years.  But in reality I don’t think this is a bad thing.  How many times have you been bitten by framework calls that are one-based rather than zero-based to name just a few.  The new framework promises to make everything consistent across the entire Xojo universe.  All arrays/lists will be zero-based and methods are more explicit in their naming.

Furthermore, UI controls will become portable between desktop, web, and iOS.  In the current framework a desktop button is not portable to web button and visa versa.  While this isn’t too horrible, it makes life a bit more difficult as you have to create new instances and then copy the code from the events from one to the other.  The new framework means that a button is a button is a button regardless of platform.  There will be SOME differences as there are some platform specific controls (iOS has views, splits, tab bar, etc) that have no equivalent on the other platforms.

The Xojo framework has several main modules:  Core, UI, iOS, String, Color, Number, Math, Media and a few others.  They’ve also added a number of common interface elements that I suspect will become a very big part of the framework.  The Core framework has common items like Dictionary, Point, Rect that will be used by other parts of the framework.  In today’s framework you would create a Dictionary object like:

dim d as new Dictionary

In Xojo it would become:

dim d as new xojo.core.dictionary

Not a huge difference but enough that I’m sure will tick some people off.  But what this gives you are new methods that are unique to the Xojo framework that are very useful like ValueOfKey and RemoveByKey.  Not that those do anything different than Value and Remove in the existing framework but they are more explicit in their use.

Strings are another change in that strings now are zero-based to become consistent across the entire Xojo universe.  But otherwise most functions are part of the Xojo.String module.  All the usual suspects are there but new functions that are more explicit are also available.

The new framework is a requirement for iOS.  When it ships it will NOT be able to use the old framework.  Shortly after the iOS release it will be released for Web and then shortly after that for desktop.

The good news is that the old framework and the new framework can be used simultaneously (exception iOS) for years to come so it probably won’t mean much to anyone for a while.  When I asked Xojo, Inc. when they’ll drop the legacy framework they really had no answer.  I suspect like many deprecated things from Real Studio it will take a while.  So there’s no need for panic.

The new framework should make life easier for all of us in the long run.  It’s not going to be a quick transition and we won’t be forced to use it.  I’m okay with it because I’m sure there will be a bunch of other things to worry about more.  Welcome to the future.

9 thoughts on “The New Xojo Framework

  1. Are they doing anything like the VB.NET Imports command? That way you can have something like…

    imports xojo.core.dictionary
    dim d as new dictionary

    This keeps typing fast if one has to make a lot of declarations, or a lot of calls to shared methods and modules. Then again for .NET it’s file wide, a file typically containing an entire form or class. I guess this would be most useful if we could declare, through the GUI or otherwise, that a particular form/class/module was going to use portions of the framework.

  2. So can we hope that namespaces will work a bit better under the new framework?

  3. Absolutely the worst idea they ever had. It’s one of the big benefits of Realbasic not to have this old-fashioned overhead like imports and those long blablalba.somethingelse.dostuffhere things.

    Why does Real really need this? What ever could be a benefit for this?

  4. Personally, I’m looking forward to namespaces. The greatest merit is, in my opinion, the expansion of the framework via plugins and whatever else. Often, as I’m typing, the auto-fill is full of unrelated methods, properties, etc.. It’d be nice to be able to do MBS.ChartDirector.DrawPicture(), for example.

    I grant that it’s a trade-off, but I feel like Xojo is ready to move to the next level of expandable language. I don’t believe namespaces are going to somehow single-handedly over-complicate the language. It may even help organize the documentation categorically.

    Just my thoughts. 🙂

  5. The benefit is that it is a way to update the product without breaking existing code, organize functionality and not have to worry so much about naming things…

    That said I agree that it complicates the product and makes it less user friendly than it has been.

    For myself, while it may seem paradoxical, having the long names like the ones one could get from nested namespaces would make code less easily readable to me. One needs to concentrate harder and process more to see the meaning .

    Having long lines of code because of such long names makes it much harder for me to take in the meaning at a glance. I know my eyes tend to glaze over at big blocks of text.

    I think it also make the product a bit less accessible to those new to coding.

    While it may grow on me, right now I am not enamored with the new IDE as I think it is also less user friendly in some important ways than the current one.

    I am also not crazy about the Xojo Pro announcement with a Pro only forum and limiting beta access primarily to those with pro subscriptions… I think that will change the community fundamentally in ways that i won’t find attractive.

    Well time will tell how all this affects my 12 year frustrating at times love affair with REALBasic.

  6. It is an interesting change. In talking with my staff we think that having some sort of import to easily resolve the namespace would be nice. Or, I’d love to have the option to turn off the old global namespace. The verboseness is going to piss a lot of people off.

    Perhaps using a special keyword to alias the namespace would be nice. So something like Using Xojo.Media as xm might make life a little easier.

  7. This situation is made worse because in traditional languages imports work for an entire file. You can stuff as many classes and such you want in a file. If I have to write an import for each method or use some goofy IDE property (attributes anyone) for imports I’m just going to get annoyed.

    Also I don’t buy that it solves any kind of problem with a button is a button across all platforms. No reason you couldn’t do that with Pushbutton and use conditional compilation. They are doing this purely for their own organizational benefit which is fine I guess… You can tell because they aren’t “sure” “when” they will deprecate the global namespace. I imagine a good portion of the new “framework” is just calling the global objects for now. It’s a mess. It’s not like they rewrote the entire framework, just making stubs for things they intend to rewrite eventually on a per-platform basis.

    Then what happens when a iOS button can handle things differently? Are we going to have AddHandlers littered for everything:

    #IF TargetiOS THEN
    AddHandler MyCoolButton.Swipe, AddressOf _MyCoolButton_Swipe
    #ENDIF

    It gets really ugly really fast. I know the IDE you can select which event handlers to handle but is that platform aware? Or do you just end up with a bunch of subclasses. Isn’t that what we have now? iOSButton is derived from Button and so forth.

Comments are closed.