XDC Predictions

Next week is Xojo’s annual developer conference.  Wednesday morning will be the keynote address by Xojo and I’m sure we will get an advanced look at what’s coming up soon and what’s coming up in the future.  I will be at the conference and I’ll be doing some blog posts on the news.  So what do I think the news will be?

Very High Probabilities

Good progress on 64 bit apps.  I suspect we’ll see Mac OS X builds for sure simply because the jump from iOS64 bit and Mac (Cocoa) 64 bit isn’t large and I can’t imagine spending years on the Cocoa version without planning for 64 bit.

I’m not as sure about Linux and Windows.  I suspect that Linux may be close as well since it seems to be a very high need by the community.  I know that every time I deal with a web app on a server provided by the client I will have issues.  Windows might be a no brainer but I’m also not sure how that affects the Win32 API – this might be tougher than it sounds.  Regardless, by Wednesday morning we’ll know for sure.

Retina IDE.  In R2 we got a taste of image sets.  I believe this is a prelude to making the IDE Retina aware.  Perhaps we’ll also get some new framework calls that tell us if the display we’re on is a high density display or not.

Edit:  AutoLayout.  I believe we will see demo’s of AutoLayout running in Web and Desktop.  I think (hope?) we might see some simplified rules since it seems to be a point of confusion for many developers.  In it’s current form it’s really not all that friendly.

Probables

Additional new Framework goodies.  One thing that we can be assured of is that a lot of thought and effort has gone into the new Xojo framework.  What we’ve seen, so far, are classes that eliminate ambiguity in the language that in turn eliminate subtle bugs.

For example, the new Auto data type is a replacement for Variants.  Variants are useful but when used improperly can lead to very subtle, and very hard to find, bugs.  Mainly this is do to their implicit type conversion that may or may not be what the developer intended.  Auto has none of that nonsense which makes Auto slightly harder to use but much safer.

Another good example is the Text replacement for String.  An old string means different things in different parts of the old framework.  The developer using a string in a socket had to worry about encodings and, again, it often led to very subtle bugs.  The sockets in the new framework will not give you a string – they give you a MemoryBlock.  And then it’s up to the developer to convert it to a string and during the process you tell it the encoding you want.  Again, it’s a bit more work on our part, but it’s inherently safer.

Perhaps the change the I most want, yet fear, is new Database classes.  The database classes are old and they’ve not really been changed much in the past 15 years.  Oh sure, they’ve been updated for the times and changes in databases but they still have the same issues now that they did years ago.

For an object oriented language Xojo really doesn’t do much to help you when it comes to the database.  It doesn’t help you in table or field names nor does it really help you with data types.  Those things are all left to the developer to figure out.  Another gotcha that gets almost everyone is that new Xojo developers don’t check for database errors.  The PreparedStatement class is almost a must these days for security but it’s optional and kind of unwieldy.

If we take a look at the database classes in iOS we might be able to peer into the future of databases.  For one, database errors, like every other failure in the new framework, will throw an exception.  Not just an error but an exception.  This will cause much consternation because it will make transactions harder to deal with (but not impossible).  Another clue from the iOS framework is that SQLExecute and SQLSelect will have PreparedStatements built-in so this will be inherently safer.

I look for new database classes to be more helpful and friendly when writing code, or at the least, to show more awareness about the database.  Xojo showed off an ORM solution many years ago at the developers conference and we’ve not heard a word since.  Perhaps this is the year it will spring to life?

So why do I fear this change?  Well, exactly 100% of our consulting work is database related so any change may have a big impact on our workflow.  And because of the shortcomings in the database classes we created our own ORM (ActiveRecord) framework that we use in most projects.  I did convert ActiveRecord to iOS in the early days to learn more about the new framework but we’ve not done much with it since (mainly because consulting has been so busy).

Wish List Items

Windows .NET framework to reduce flicker.  The bane of our existence (at times) is flickering in Windows apps.  It sometimes seems just breathing on the app will cause controls to flicker.  Xojo has repeatedly told us that this is common in Win32 native controls and while that may be true, it’s also true that Xojo competitors and Microsoft seem to have solved this problem.  Perhaps the Windows framework will have its own Cocoa-type project that brings considerable improvement to Windows builds.

A Usable Reporting Tool.  Here is a fact:  Xojo does not use their own reporting tool.  It is not used in the IDE or Feedback or Lingua (the major public applications).  It’s more of a marketing bullet point than a usable tool.  If you ask around most Xojo developers don’t use it because it falls down as soon as you want to do something real with it.  If Xojo really wants to attract business users, make this tool rock solid and usable.  Yes, I have my own reporting tool (BKeeney Shorts), but it was created out of necessity.  BKS Shorts isn’t a banded reporting tool (like Xojo reporting is) so it will still have a niche to fill.

Speaking of ways to get more business users, I’d love for Xojo to create simple and basic (i.e. good enough) controls so that new developers don’t immediately have to look for 3rd party components for what many believe to be necessary controls.  This includes a basic date and time picker, numbers only fields, and masked text fields (that actually work) to name a few.  A decent grid control (not a listbox replacement) that we can put container controls in.  The list isn’t that large but the omissions are prominent.  I know the argument:  cross platform controls are hard and getting it right is even harder.  You bet it is!  That’s the type of solution that the makers of a cross-platform development tool should be doing!

A new web framework that makes web development closer to desktop.  In the desktop world we can do a lot of really cool things with Constructors.  In Xojo web apps those are usually disastrous and do nothing but generate Javascript errors.  Make it so Open events are safer to use instead of relying upon the Shown event.  I understand that some of this might be impossible but the differences between desktop and web are frustrating.

Long Shot Items (i.e. don’t count on it)

Here we are several years after the Xojo release.  I still really dislike the Navigator in Xojo.  I still have some projects in Real Studio and it’s hard going back and forth because enough things are different that it takes me a good hour to get comfortable in each version.  I’m hoping (probably against all hope) that they’ll announce some level of change in the IDE.  Ideally I’d love a hybrid between the Real Studio IDE and the Xojo IDE.

Conclusions

I love the Xojo Developers Conference.  It’s where I go to learn about what’s coming up in the product I spend so much time in.  It’s also where I get to bend the ears of some Xojo engineers (but usually over a drink or two) and it’s where I renew my friendships with Xojo developers that I’ve known for years.  If you’re going to the conference, please don’t hesitate to stop me and introduce yourself.

What do you think will be announced?  What are your wish list items?

6 thoughts on “XDC Predictions

  1. Good article!
    On my recent tour last days to southern Germany I met a dozen developers. Quite a few told me they stay with Real Studio 2012 because they can’t get work done with Xojo IDE. Too confusing and things are hard to find. They way for a working history navigation (maybe a history menu), bookmarks, configurable toolbar (small icons), find result in extra window and much more things they are used to.
    And I know at least 3 to use RS for development and Xojo for building.

    • I think this week I fired up Real Studio 2012 R2.1 and at least a version from every year of Xojo to find when an issue started. Our biggest issue is what version of Xojo goes with each product and what version of plugins go with it.

    • Absolutely. The old RS IDE scaled well. The Xojo IDE is an inconsistent nightmare with anything other than a moderately-sized project.

  2. We still use RealStudio 2011r3, because the IDE of Xojo is confusing and unproductive with huge projects. Maybe next week will be presented an improved IDE.

    • I would not count on it. Xojo has too many things on the plate right now that make any major IDE changes not likely to happen. *Maybe* by the end of 2015 they can think of them. I’ll be happy to be wrong on this one. 🙂

  3. I would say be careful what you wish for regarding .NET framework. Since the big question would be “What” .NET framework do you wish for ?

    Windows Forms is by far most commonly used, but its not supported much. The UI framework is just thin layer on top of Win32. (Xojo even could check their source code to get the flicker a bit under control), though Windows forms will flicker too if badly used, just not as easily.

    WPF, was what Microsoft was trying to push everyone to, but it did catch all that much on and the applications tend to be heavy and clunky and even out of place at times. It is not based on Win32 and UI will not flicker, and I guess it would be nice for high DPI, separation of UI into XML files sort of made it slow to catch on.

    Metro UI framework – We’ll only makes metro Applications, where users who actually want to use Metro applications are in short supply. Is double buffered and good with High DPI.

    What I am getting at is that its not clear cut what asking for .NET framework means

    If I was starting big project on Windows with Visual Studio, then its not clear cut which .NET UI framework I would go for, its sometimes as if even MS does to know which path they want people to go right now.

Comments are closed.