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?

Xojo.Core.Date

I ran across an issue with Xojo.Core.Date that I talked about on the forums https://forum.xojo.com/18549-xojo-core-date-question.

The issue is that the new Date class does not have SQLDateTime.  Well, technically it does with a generic ToText function.  However, there is no way to get just the SQLDate portion without having to write your own method.

The ToText method has a LOT of power to do and it is considerably more powerful than the old Date class.  The ability to work with Locale is very cool and should simplify some things.  However, I have some issues with the ‘replacement’ for SQLDateTime.

First, SQLDateTime is very explicit in what it does.  ToText (with no parameters) doesn’t tell me jack and the fact that I missed it in the documentation tells me the name absolutely 100% fails the ‘name explicitly tells you what it does’ test.

Second, there’s no option to just get the Date in SQL format.  Sure, you can create your own method to get that but that’s one more thing to create, test, and maintain.  There are times when you need just the SQLdate portion.  It doesn’t matter why we need it – we need it.

The new Date class is full of wonderful things.  However, removing functionality that many of us use every day should be avoided.  I think this is one of those times where the Xojo engineers got too clever in the new framework.  I’d much rather have the SQLDateTime and SQLDate methods back.  They are much more explicit than ToText.  If you agree, you can sign on to <feedback://showreport?report_id=37521>

Of course, like with the Numeric.FromText methods, I’m willing to be convinced that the Date.ToText method to get SQLDateTime is better.  What say you?

 

[Update]

Later I realized that we could accomplish everything by adding the SQL option to the DateFormat and Locale enumerations.  Then the code would be something like this:



dim d as Xojo.Core.Date = Xojo.Core.Date.Now

dim t as text = d.ToText(Locale.None, Date.FormatStyles.SQL, Date.FormatStyles.SQL)


That would solve all of the issues, no?  They get to keep ToText and we get the ability to format the date in whatever form we want.  Then there is no ToText without Parameters.

New Xojo Framework Thoughts

I don’t think application development is very hard. It is however complex and this, I think more than anything else, makes it appear hard because people equate complexity with being hard. Xojo does a pretty good job of making things less complex for us and I honestly truly appreciate that.

The new framework that we’re really seeing for the first time in iOS has some good things in it. Database errors throw an exception. I like that that because that’s what we (BKeeney Software) does with our own SQLSelect and SQLExecute extends methods (name SQLSelectRaiseOnError and SQLExecuteRaiseOnError). Not everything I agree with though.

In the existing framework we would do something like this to get the integer value of the aTextField.

dim i as integer

i = TextField1.text.val

We’ve been using this for close to 15 years. Works great. Now, in the new framework we have to use different converters and use code like this:

dim i as integer

i = Integer.FromText( TextField1.Text)

Seems pretty straightforward, no? Well, no, because in their infinite wisdom, if there is no text (i.e. a blank string) an “InvalidArgumentException” is thrown. WTF?!

Instead, you will have to do this instead.

Dim i As Integer

If Not TextField1.Text.Empty Then
   i = Integer.FromText(TextField1.Text)
End If

But even then, if there text there that can’t be converted to an integer it throws the exception. I sort of agree with that change.  But, I don’t see this change as being ‘better’ or even simpler. If anything it’s more complex and it’s getting away from the strengths of BASIC that made many us use it over other languages in the first place.

So really what you’ll need to do is something like this:

Dim i As Integer

try
   
   If Not TextField1.Text.Empty Then
      i = Integer.FromText(TextField1.Text)
   End If
   
catch e as InvalidArgumentException
   
   i = 0 //if that’s what you really want.
   
end


You really want to do that several thousand times in a big accounting application?  When I suggested that I’ll just create my own extends methods to match current functionality the response was “Not doing so is a great opportunity for silently doing something really wrong.” Well, I guess at that point it’s MY problem, no?  If something goes wrong, and I did my own method, it really *is* my problem.  Or are the Xojo Programming Police going to take away my license?

Xojo is trying to make a complex process idiot proof. I appreciate the effort, I really do, because Lord know I can be an idiot at time. All they did, in my opinion, was make this simple process more complex. I think they may hinder adoption of the new framework. My guess, though, is that they’ll force it down our throats for console, desktop, and web when the time comes.

What do you think, my friends? Is the new framework helping us or hurting us or is this just a “this is different so I hate it” reaction?