XDC 2018 Keynote Notes

Notes from Geoff Perlman’s keynote address at XDC 2018 being held in Denver Colorado.

XDC sold out a full two and half months ahead of the conference.  24% are first time attendees.  34% are from outside of the United States representing 12 different countries.

There are over 18,000 users in the forums.  That’s a 20% increase over the last XDC.  Over 43,000 conversations and 370,000 posts.

Geoff talked about the forum and the conversion to esoTalk from the old phpBB forum software.  The original developer is doing a new forum software called Flarum and the plan is to start using it in the future.

Xojo cloud continuing to grow.  Zero configuration.  Zero maintenance.  Industrial strength security.  Recently introduced new server specs (twice the server for the same price).  Now in 8 data centers.   Now has  in-IDE server monitoring.

Xojo Design Awards:

Best Developer Tool – BKeeney Shorts by BKeeney Software Inc.

Best Specialty App – Curve4 

Best Consumer App – Alinof ToDo LIst by Alain Clausen

Best Mobile App – Packr by Jérémie Leroy

Best Utility App – Server Ranger, by Gavin Smith – Liberty App

Best Cross Platform App – LehrerOffice, Jürg Otter – Roft Soft AG

Platform Landscape:

In 2016, mobile became the most used platform.  In 2017, desktop increased a bit and now the two are running in parallel.

Windows:  Now using Direct2D for drawing and printing.  With 2018 R1 is now flicker free in Windows.

Xojo Cloud:  Faster uploads.  Caches the frameworks and only uploads what’s changed.

Linux:  Gtk3 now lets us create HiDPI applications.

64-bit builds.  One of the benefits of 64-bit: They now have an optimizing compiler and apps that use a lot of mathematical operations this can make a huge difference.  One user, a professor at Cal Poly Pomona, has spent 10 years writing an app and when compiling for 64-bit he found a 7 times improvement in performance.  This is all because Xojo is now using LLVM, an open-source compiler.

The IDE is now 64-bit.  It now allows large projects to address more RAM.

A few misses since last XDC:  Interops, plugins made in Xojo.

Communication with end users:  Xojo plans 18 months in advance.  Going to stop talking ship dates.  No longer saying when a particular feature is going to ship.  Instead going to talk about what’s ‘important’.  ‘Priority’ means that are things that are in development.  Bottom line:  no more ship dates.  No change in regular releases.

What are the Priorities?

Interops:  like declares on steroids.  Android is first.  iOS next, and MacOS eventually.  Windows is tricky and it might not make sense for that platform.  Linux is even more of a wildcard with so many distributions.

Android:  working super hard on it.  They hit some milestones recently that Travis will talk about more.

Plugins made by the IDE:  Still ‘important’.

The IDE Interface:  Since last XDC been a lot of work done.  Geoff showed a demo.  Home screen is overall project overview.  The Navigator is no longer there.  Double clicking on an object takes you into the object.  Where the Navigator was is the Toolbar.  Each tab can use the Home Screen.  Geoff didn’t show the Code Editor or anything other than the Form Editor.

Web Framework:  Web 1.0 was designed in 2009 so that’s like last century.  Windows XP and 7 were the dominant Windows OS.  Mac OS X 10.5/10.6.  JQuery was immature.  Browsers not very feature rich.  And the goal at the time was to make web apps look like desktop apps.

Web 2.0:  ground up rewrite with significant modernazations and optimizations.  This will result in far greater speed between the client and server.  Overhauling 5 controls.  10 new controls.  Improved look and feel.  99% compatible with existing projects.  One of the new controls is a charting control.  Feels more web-ish and less like a desktop app.

Xojo API’s:  The original API’s designed in 1997.  Much of the current framework is the same.  Originally started with one platform.  Accumulated a lot of cruft over the years which resulted in behavioral inconsistencies.  Making changes would break existing projects.

This all resulted in the new Xojo framework to help keep Xojo modern and keep it moving forward.  Namespaces were used to avoid conflicts with the existing API.  Behavior was consistent.  Tradeoff was complexity and also created some inconsistencies.

Guidelines:

  • When to use which case
  • Intuitive identification over accuracy
  • Avoiding abbreviations and truncations
  • Enumerations should always be plural
  • Method names who’ll be verb-noun
  • Event that fire after the vent has occurred should be past tense
  • Conventions for classes that deal with list data

Found that the new API’s don’t conflict with the old ones.

Keep the current API’s for compatibility

Add new API’s for better consistency

Replaced API’s will be deprecated.

Migrate to the new API’s at your own pace

Can mix the old and new API’s

NO NAMESPACES!  The Xojo Framework namespace is gone!  Not 100% true but for the most part it is.  To clarify developers can still use and create their own namespaces but no more ‘wall of code’.

Easier transition for Xojo and for developers.

Called API 2.0

Easy to learn.  Easier for them.  Easier for developers.  All possible via API Naming Guidelines.

They’ll release this document later on so the community can use the guidelines.

Last but not least:  XDC 2019 will be in Miami, FL.  May 1st through May 3rd.  $149/night and the rate is available 3 days before and 3 days after the conference.

More info as it becomes available.

Xojo 2014 Release 2.1

Xojo 2014 Release 2.1 was released this week. This maintenance release is huge in several important ways.

This is the last version of Xojo that will build Mac Carbon apps. The upcoming changes to the framework for iOS and 64bit (and who knows what else) have made it impossible (or at least unfeasible) for the engineering team to keep supporting the Carbon framework. So long Carbon, we have to split up. It’s you, really, not me.

Since this will be the last version to support Carbon some nagging bugs were fixed in the Carbon framework. The hard crash that occurred when creating a new instance of the XMLDocument has been fixed. In addition a bunch of plugin issues for Carbon were fixed.

Cocoa apps that use RegEx will now pass submission to the Mac App Store.

For web app developers a big change was made to HandleSpecialURL that breaks everything that depended upon how the old, incorrect way, WebRequests were handled. I know this affects Web Custom Controls and it may also affect Studio Stable Web Essentials (unconfirmed). More info in a Xojo blog post at http://www.xojo.com/blog/en/2014/08/handlespecialurl-changes-in-2014r21.php

A few other web bugs were fixed. WebSession.Quit now properly clean and close the Session. A bug with WebContainer.EmbedWithin used in a open event (never a recommended way, if you ask me) that would cause WebLabels and WebLinks to offset was fixed.

There were several of database class changes too. SQLite now uses FTS4 with unicode61 tokenizer on Mac OS X. MySQLCommunityServer SQLExecute and Prepared statements no longer assume the statement is UTF8 encoded. The ODBCDatabase DatabaseRecord.Insert no longer inserts the wrong value.

As always, read the release notes for additional information and Feedback ID’s.

This dot release is critical for those developers still building for Carbon. iOS will (presumably) be out in Release 3 in at least beta form and the new framework is causing changes in a big way. I’m sure some of those changes will be subtle but some will be a smack to our collective faces.

To paraphrase Game of Thrones, “iOS is coming.” Sorry, couldn’t resist. 🙂

Xojo 2014 Release 2

Xojo 2014 Release 2 was released this week.  This release has around 200 bug fixes and enhancements, some new features, and some licensing changes.  A good portion of the changes and enhancements are in the Web framework which will make web developers very happy (I know I am!).

Licensing Changes

New Single Desktop licensing.  A new license is available for a single desktop platform (Mac OS X, Windows, Linux) at $99 each.  This is helpful if you are only dealing with a single platform and have no need for the other two.

Pro license is $100 cheaper.  A new Enterprise license is now available that gives you everything that the Pro license gives you plus 8 hours of custom video training.  The Enterprise license costs $1,999 for both new and renewal.

Changes

Users can now add plist items into the plist generated by the IDE at build time.  This takes the form of an XML file that is added to the project.  If this is something you’re interested in take a look at the Platform-Specific/OS X/PList/EnableRetina example.  If you were using an IDE script or PostBuild script on the Mac side to do this already I’m not sure that this is a better solution.  However, I think this will be hugely beneficial to Windows and Linux users that are building for Mac OS X.

The PostgreSQL database plugin now has an SSLAuthority FolderItem property that represents the root SSL certificate file.  This lets you connect to your database server using SSL.

Xojo Cloud users can now use the StageCode to create different builds for the server.  Final is the same as it was in the previous release but Beta, Alpha, and Development stages add a -Beta, -Alpha, and -Dev postfix, respectively, to the app name and upload them to the Xojo cloud server.  This should make it easier to test Xojo Cloud applications.  The only drawback I can think of is that smart users might figure out the URL postfix and use the newer version rather than the release.

Speaking of Xojo Cloud, release 2 seems to have finally fixed the hang on upload during large projects.  During the beta cycle I went from 1 out of 5 successfully uploading to a nearly 100% success rate.  Those that did fail didn’t require a restart of the IDE which was a royal pain in Release 1.

AddHandler and RemoveHandler now work with Web controls after they’ve been sent to the browser.  In previous editions you had to use AddHandler before it was sent.  For example, if you added a dynamic WebDialog you had to implement the AddHandler after it was created but before the Show method was called.  Now you can do that after the show.

The WebListBox received some love in this release.  A new SelectionStyle property now lets you set the WebStyle for row selections.  In addition to that, there is a new HeaderStyle and HeaderColumnStyle properties that let you select the header and column headers, respectively.

WebTextArea now has a ScrollPosition property that allows you to set the, wait for it, scroll position.

The WebToolbar has become more useful in that it allows you Append and Remove items.  This has been wanted for a while now.

In one of the bigger bugs that’s affect me for a while, they fixed the WebRequest.QueryString on cgi builds.  This now lets cgi builds to work the same as standalone builds.

WebContainers added via the EmbedWithin method now no longer have exponentially increasing delays.  This is very helpful to developers, like us, that use WebContainers a lot.  This change will let dynamic displays to be more responsive over time.

A bunch of Web framework items no longer leak memory.  Of note is the WebPage when closed and dynamic WebDialogs (i.e. created in code not placed on a page at design time).

A change was made to the Web framework to prevent ‘clickjacking’.  Clickjacking is an attack that tricks the web user into clicking something that is different from what they perceive.  This can potentially reveal malicious or confidential information or even allow taking control of the computer.  As far as I know, this attack has never occurred in a Xojo web app but it’s nice to see that they’re proactive on these things.

StyledText RTF parsing speed is improved.  This is a good thing since it was pretty much a dog before.

A number of console app memory leaks were fixed.

Some database changes:  SQLite is updated to use version 3.8.5.  The MSSQLServerPreparedStatemnt.SQLExecute no longer crashes.  MySQLCommunityServer no longer causes failed assertions when SQLSelect/Execute are invoked while other threads are running.  The Recordset.Update/Delete now works in SQLite databases when he primary key has special tokens (like single quotes) or BLOBS.  The error returned by SQLite databases using a bad encryption key is now the proper error.

Windows and Linux MsgBox and MessageDialog modality is now consistent.  This means that MsgBox is always app-modal but it depends with MessageDialog.  If called with ShowModal it is app-modal but if used with ShowModalWithin it is window-modal.

The IDE has a bunch of changes and improvements.  The long standing issue of changes in the Inspector not being retained unless you tab out of the TextField seem to be fixed.    Changes to non-text properties also commits the changes.  The Inspector has been compressed a bit to reduce scrolling.

In general, the IDE seems a bit snappier – at least on Mac OS X.  Sometimes it’s very hard to tell about fit and finish on the other platforms simply because I don’t develop on those platforms.

Conclusion

Xojo 2014 Release 2 is very much about the Web.  The memory leaks getting squashed, the WebListBox additions, and security improvements are all welcome.  Xojo Cloud is now functioning better and is now, in my opinion, worthy of being used on a day to day basis.  We’ve moved all of our training apps to Xojo Cloud during this beta cycle and are happy with the performance.

If you are not a Web developer than this release still has some changes and fixes that might be important to you. Unfortunately, in a review like this I can only comment on changes that seem important to me.  Check the release notes out!

 

What did I miss in the review that you thought was important?

Finding a Specific Control

Real Studio is pretty easy to learn.  Navigation is pretty easy and switching between the layout and code editors is pretty straightforward for the most part.  There are times, however, where the simplicity of Real Studio fights you.

Take for example, this report that comes with the examples folder.  It has a number of layered controls (meaning the controls have a parent) and in this case, their are quite a few ReportLabel and ReportField controls on a ReportRectangle.  In the layout editor this isn’t a big deal because the layout is simple.  Click on any one of the controls and you can get its properties.

 

 

  However, once you get into the code editor, all you see is a list of controls, sorted by name.  There is absolutely no hierarchy that you can deduce from the list.  It’s a major headache for complex layouts, in my opinion.

In my ideal world I’d love the ability to right-click on the item in the code editor and select ‘reveal’ (or similar) and have the layout editor displayed with the control selected.  It would solve some headaches such as the occasional hiccup where Real Studio puts the child control outside of the visible region of the parent.  When that happens, you can no longer see it.  So  how does one ‘select’ the control to either move it, delete it, or otherwise edit it?

You can easily do the opposite case.  In the layout editor, right click on a control and use the “Edit Code” submenu to quickly get to an event in the code editor.  However, for some reason, I rarely use this command.

The contextual menu (i.e. right-click) in the layout editor provides some nifty commands that you might not be aware of.  The one we’re interested in, in this case, is the Select menu.

 

 

 

 

 

What the Select menu does, is give you a listing of all the controls, in their hierarchical, and alphabetical order.  So in this example from one of my current projects shows a relatively simple hierarchy with a GroupBox control (SSFrame6) hosting two canvas controls (cvsHusband, cvsWife) hosting DateControls, Labels, RadioButtons and Pushbuttons.

In some instances, this might be the only way that I could select one of the controls.  It’s easy enough to screw it up.  Make the canvas big enough to fit all the controls in it and then reposition it and resize it so that none of the other controls are visible.

Once this happens you’ll never ‘see’ the control in the layout editor but the code behind the controls might be firing anyway (for example if you have code in their open events) which might cause some issues.

While I’m here I’ll make a plea for some common sense naming conventions.  If you take a look at the RS example, GasReport.rbp above, you’ll notice that all the controls are using their default names.  At a glance you can’t tell what Field1 vs Field10 does.  This is one of those things that drives me crazy!

I see too many OPC (Other Peoples Code) projects every month to condone this behavior.  If I were to get this project to fix, the first thing I’d do is name the major controls (I might skip labels – but only if they’re not referenced in code) so when I see them in the code editor I can, from a glance, see what their intent is.

I know this is nit-picky, but I see it time and time again.  If you’ve subscribed to my Real Studio Video Training Series, you’ll note that I rarely leave the controls with their default name.  The few times I do I tend to apologize for breaking my own ‘rule’.  My thought behind this rule is that I’m not only coding for now, but for five years from now when I open the project again.  I don’t want to have to switch between the code and layout editors to figure out what a pushbutton does.  If it’s named properly I can tell its function.

Anyway, enough of the soapbox.  I hope you learned something.

Any tricks that you’ve discovered in the IDE?