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.
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!
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.
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?