Should you Mix and Match Old and New Framework?

When Xojo introduced the iOS framework when Xojo 2015 R1 came out we got introduced to the new Xojo framework.  It was only required for iOS and were told that it would eventually get added to the other targets.  Xojo 2015 R2 introduced much of the new Xojo framework into the desktop framework.  Many people are curious if it’s time to start using the new framework.  Is it safe to use?

Let’s get this clear up front.  There is no reason why you have to use the new Xojo framework.  Sure, it’s the future but the old framework will work for many years to come and there are huge gaps in the Xojo framework that haven’t been addressed yet.

My first bit of advice is to not dive headfirst into mixing and matching the old and new frameworks just yet.  It can be an exercise is frustration.  Take, for example, this bit of code:



dim d as new xojo.Core.Dictionary

d.value(kMachineName) = MachineName.ToText

if d.value(kMachineName) = “” then
   
   break
   
end

Looks like it should work on desktop, right?  It doesn’t because when you get to the comparison it generates an exception.  When you break it down it makes sense because the Auto value you get from DictionaryValue is a Text type and you’re comparing it to a String type.  The two are not equivalent.

The way around this, that seems to work, is to do this:



dim tBlank as Text

if d.value(kMachineName) = tBlank then
   
   break //handle error
   
end

Obviously if I was using Text everywhere this wouldn’t be a problem.  But this is a desktop app and the major gaps in the Xojo framework start to show up.  The database classes will only accept Strings so you have to do some conversion.  This isn’t a big deal, but it’s one more thing to worry about and deal with when exceptions come up.

99% of our consulting applications are database driven so not having the database classes in the new framework are a major hindrance to us to adopting the Xojo framework.  Frankly, if it weren’t for the client wanting us to use the new framework whenever we can we’d not be using it yet.

Some of the parts of the Xojo framework that are done aren’t fully fleshed out.  For the past couple of weeks I’ve been working with the xojo.net.httpsocket class.  Works great on Mac OS X and Linux (surprisingly enough) but when I get into Windows for testing it just does nothing – no exceptions, no errors – it just absorbs commands.  The first reports of issues happening in Windows were reported in back in August but that report was closed as not reproducible.

When it comes to the networking classes the new TCPSocket class still hasn’t been ported to non-iOS targets yet.  Neither has any of the UDP and ITC classes and, in general, there are still a lot of old global framework classes that haven’t been ported yet.

This makes sense because iOS and then 64 bit took a lot of time and resources to get to the state they’re in today.  I would argue iOS isn’t complete yet but that’s an argument for another day.  It looks like 2015 R4 will be mostly Retina support so we are many months away from some of these gaps getting filled.

I am curious to hear other Xojo developers experience with using the new framework.  For me it’s been frustrating from the lack of examples in the documentation, to it just working differently than the old framework, to the new classes not working as they should, to not having a complete framework to pull from and the messiness from commingling the old and new frameworks.  My advice would be hold off on trying to use the new framework in a desktop, console, or web app until there’s more of it.

What’s your experience with the new framework?

6 thoughts on “Should you Mix and Match Old and New Framework?

  1. I use almost exclusively the old framework. Now I have started a few small “test” apps or “throw away” apps that I tried to use the new framework as I want to be using the go forward platform. But the new framework (up to R3.0 – havent tried beyond that) has been painful. it is missing too much stuff. Granted each release (full or point) it gets better but it is a ways off.

  2. What’s interesting about the new framework and Xojo.Net.HTTPSocket in general is the evolution of how it came to be.

    In the old framework HTTPSocket is a sub-class of TCPSocket. You can demonstrate this by many of the same methods/properties being available. Also Xojo falling behind on HTTP 1.1, 2.0, etc. are examples where the HTTPSocket was home grown on top of the TCPSocket.

    Since iOS came out first they introduced Xojo.Net.HTTPSocket late in the beta cycle but it turns out it supports all the new HTTP goodness. However no Xojo.Net.TCPSocket exists? In my opinion it seems Xojo.Net.HTTPSocket is mapped to the equivalent HTTPSocket provided by the operating system and not Xojo home grown. Hence in the new documentation on Linux it requires “libsoup”.

    This is both good and bad. Xojo.Net.HTTPSocket will stay with the times by being provided by the OS (or an easy to install third party library from OS repositories) but it will not function exactly the same on all platforms. It also triples the surface area of potential problems because an HTTP related problem could be very target specific due to the library used. Major OS version changes might also negatively affect how HTTP Sockets are handled thus rendering different results.

    That being said better to have a reliable HTTPSocket then not at all so I’m not complaining with their strategy. I’d do the same thing myself but like all things of late – the surface area of problems keeps going up.

  3. I don’t know enough about the internal workings to say anything definite, but I do wonder if tackling 64bit and a new framework at the same time (for Desktop) was wise. Yes, the new framework for iOS I understand (big release item 2014), but I would rather have pushed on there, gotten it more feature complete. Gotten 64bit for Desktop (big release item 2015). Then moved Desktop to the new framework too and released it when it was mature (big release item 2016).

    Would have been good in the old release model, in the Rapid Release Model of “We’ve got something, let’s push it out” it results in a rather half-baked implementation that does Xojo and it’s users both no favours. I notice with concern the number of emergency point releases where serious bugs make it into the final release.

    • Not having the new framework available at all on Desktop would ruin a lot of Xojo’s appeal. I’ve been able to share a LOT of code between desktop and mobile which is a real time saver and makes the platform much more powerful.

      I don’t think going any longer without 64-bit was an option either. There are just a lot more targets these days. Even within Apple market alone there is now tvOS and watchOS to build apps for. Xojo is going to have to speed up now to keep the pace with the market.

  4. I’d recommend to do it the other way. Change a class completely to the new framework by adding a using clause, then use Global to access stuff from the old framework.

    Add the necessary amount of Operator_Convert methods and mark them with an attribute like “transition” so you can later – when the new framework will be complete – revisit and remove these converters.

    For built-in, non-sublassable classes have a module with extension methods like these (I have them all in a module called “transition”):

    Function TextValue(Extends dbf As DatabaseField) As Text
    Return dbf.StringValue.DefineEncoding(Encodings.UTF8).ToText
    End Function

    Function DateTimeValue(Extends dbf As DatabaseField) As Xojo.Core.Date
    If dbf.Value Is Nil Then
    Return Nil
    Else
    Return New Xojo.Core.Date(dbf.DateValue.TotalSeconds – 2082844800,
    Xojo.Core.TimeZone.Current)
    End
    End Function

    • @Eli: wouldn’t that make a good Git project? Seems a bit wastefull for everyone to do their own.

Comments are closed.