If I could change one thing about Xojo what would it be? My answer is, without a doubt, the Rapid Release Model. Here’s why.
The idea of the Rapid Release Model isn’t a bad one. In the not too distant past many applications had major yearly updates. Many still do. In fact, Xojo (when it was called Real Studio) did this with varying degrees of quality.
Some of the complaints about the yearly, monolithic, release of Xojo (back when it was Real Studio) was that it wasn’t a very stable release and it took several dot releases to get it right. This was the impetus that led me into the Beta Program so I could test out new features before it was released. I was tired of new features not being usable due to an obvious lack of real world testing.
In theory, the Rapid Release Model introduces smaller changes and a few new features each release. Releases are roughly every quarter but in recent years this timeframe has not been as consistent. I believe this change happened, in large part, to address some of the complaints of the Rapid Release Model. One of the complaints being that the constant drive to get new features in every release gives the software a perpetual beta feeling. I would argue that the recent changes to the Windows drawing system certainly justifies that feeling to many current Xojo developers.
From a developer standpoint, I can only imagine the pressure on Xojo’s small development team to constantly add new features every 90 days. It means that developers are always pushed to get things done rather then get them right the first time. Again, I would point to the plethora of changes to the Windows drawing system that have spanned many releases as proof.
I believe that marketing is entirely behind this new-features-every-release mantra so they can get buzz about something in every release. I get it: for a small company they need to create as much buzz as possible. Buzz creates some sales and renewals. But I think the Rapid Release Model is actually hurting them with many developers who value stability over new features.
More evidence that the Rapid Release Model is hurting Xojo is their recent change of telling customers their development plans. No longer will they tell us the target date of when a feature is released and instead they’re simply saying if it’s a ‘priority’ or ‘important’. Prior to this, Xojo CEO Geoff Perlman said that Interops and Android would ship by the end of 2017 and not only did they not deliver, but it seems highly unlikely they’ll get it out by the end of 2018 in anything other than an alpha release (purely a guess on my part and I’d love to be wrong).
Being poor at estimating isn’t just a Xojo problem. Chrono-Optimism is a human condition and I believe the old adage that 80% of the work takes 20% of the time and the final 20% takes 80% of the time. Estimating is an arcane art form and at times software development is pure magic that takes time. Forcing releases into this 90 day window makes the problem worse by having incomplete solutions and incomplete testing.
When all is said and done, I believe Xojo would be better off ditching the Rapid Release Model and going back to monolithic releases with regular dot releases that does nothing but fix bugs. Perhaps this means that there are only two major releases a year. Sometimes only one.
The Rapid Release Model is not without some merit. We currently know that every release will fix a large number of bugs and we know roughly when that release is going to come out. Not all bugs are created equal but for many developers we can’t wait six months to a year to get a release that fixes some bugs. So any replacement to the Rapid Release Model must take into account that Xojo developers need a regular, perhaps monthly, bug fix releases for critical and important bugs.
I think changing to a hybrid model between the monolithic release and Rapid Release Model fits the small Xojo team better. First, it lets the new features gestate in internal testing longer before we ever see them without being rushed out the door. Second, the regular release of bug fix builds is simply that – bug fixes – and lets the developers continue to work on the next big thing without the pressure of having to add new things in each release.
To say that the Rapid Release Model is a failure is hyperbole. To say that the model makes the product beta quality is also a stretch. The truth is somewhere in the middle and I think this is an important discussion for the future of Xojo and their customer base. What do you think?
The most important thing for developers is to have a reliable IDE. The Xojo IDE has been stable for a couple of years and while I don’t find it as useful as the old REAL Studio IDE it doesn’t hinder me as much as it used to either.
Another vital aspect of a solid development tool is the stability of the compiled application. This is where Xojo isn’t doing as well. MacOS has been stable since the transition to 64-bit Cocoa was complete. The transition for Linux and Windows has been less successful and this has to change. If they don’t get better, many of us will be forced to look elsewhere for a new development tool.
This post is part rant and part wish list. I want – no need – Xojo to be better than it currently is. Part of my frustration is the plethora of older projects that are stuck on an older version of Xojo because of issues with newer versions.
Linux is a particularly difficult platform to work on: The number of distributions and slight variations ensures that there will always be some challenges to stability. These differences make it difficult for Xojo to create builds for all distributions that work evenly. The new GTK 3 drawing system has been less than ideal for us.
We have several cross-platform commercial applications that have macOS, Windows, and Linux targets. When Xojo made the transition to GTK 3 it really messed up how these applications work in Linux. Add in some 3rd party control compatibility issues and we’re stuck at Xojo 2017 R1.1 (before the GTK 3 switch occurred).
More recently, and more importantly, we’ve had a number of projects that were last built using Xojo 2016 R3 and the client recently wanted 64-bit builds for macOS. This wasn’t a hard transition with only a few 64-bit specific changes required. The Windows builds (still at 32-bit) in Xojo 2018 R1.1 proved to be impossible simply because the Windows drawing system has steadily changed in (what seems like) every release since 2016 R4.
I’m not sure what the drawing system change was in 2016 R4 but drawing doesn’t work the same way as in 2016 R3. Then there was the change to Direct2D from GDI and that had significant bugs for several releases. The recent 2018 R1 release introduced even more significant changes to the Windows drawing system to reduce flickering. The caveat is that drawing is much slower depending on settings and how you’ve layered your controls.
From my experience and from what I’ve gathered from the Xojo forums is that the new ‘flicker-free’ system is causing a lot of heartache among developers building for Windows. Sure, flicker is gone but drawing is so slow as to be unusable in some cases. Even developers that could live with the flicker are unhappy with the speed hit.
My client eventually told me to give up because he didn’t want to foot the cost of converting to a new drawing system that wasn’t causing him issues to begin with. So, this means I’m creating macOS builds with Xojo 2018 R1.1 and Windows builds with 2016 R3 (with the code base from that era). That is nuts and unacceptable.
I get that Xojo will always be playing catchup with changes to the target operating systems. When Apple or Microsoft or a specific Linux distribution changes things it has to react to the change. Hardly ever does Xojo have advance notice of the change (remember when Apple deprecated QuickTime and stopped accepting Mac App Store submissions with QuickTime just a few months later? Or when Apple decided that iOS apps were going to be 64-bit only?) I think that what we have in Xojo is nothing short of miraculous.
But, in regards to the drawing systems for Linux and Windows they’ve made a conscience decision to change a critical and important system. This makes it tough to upgrade from one Xojo version to another without a great deal of work. Clients don’t want to hear the term ‘lot of work’ because it means it will cost them. So we’re stuck with older, and inferior, versions of Xojo.
I guess this is the price of advancement. Any NEW projects will have the new Linux and Windows drawing system in place and we’ll think nothing of it a year from now. But heaven help anyone trying to upgrade from an older version of Xojo to a newer one because it will cause a lot of work.
It’s probably not possible, but it would be great to have the option to use the older drawing system and have it marked as deprecated, or perhaps we even have to force the switch to use an older Graphics object. In the not so distant past we had the switch in Windows to allow GDI or to use the slightly different GDI+. I would really like that option in Windows (instead of the flicker free version) and for the older drawing for Linux.
I love Xojo. What it does is nothing short of magic. Develop on the platform of your choice and write for the other platforms. That’s some high level wizard stuff there. I just wish the transitions of major subsystems were planned out better beforehand, more stable when introduced, and not in need of major work to upgrade to use, or at least have a way to use the older system version for a period while still getting to use the new version of Xojo.
I can also argue that the constant cycle of adding new features and changing things every release is detrimental to the product. Every now and then I want a release that is comprised ONLY of bug fixes. Marketing be damned – I just want stable and reliable releases so I don’t have to juggle Xojo versions and plugins.
There are a lot of bugs that should be fixed that have been around for years. I understand that not all bugs are created equal but some are very serious when you encounter them and are impossible to work around. Again, having only a couple of releases every year that do nothing but clear the backlog would be awesome.
Instead, we already know we’re going to get Web 2.0, API 2.0, Interops, and Android in the near-ish future. Those are all major NEW features. Can we just get a few stable releases before those things are added so we don’t have to chase Xojo versions depending on bugs?
The old way of doing releases was to do one major release a year and then issue a number of ‘dot’ releases. It usually meant that the first release of new features wasn’t a great one because of bugs but usually pretty good after the first or second update. With the constant race for new features every release we get to chase versions based on what bugs we can and can’t live with.
Please, Xojo, be better before I have to go in search of a new tool.
Xojo announced the availability of Xojo 2018 Release 1.1. This ‘dot’ release fixes a couple of glaring bugs that were introduced in 2018 Release 1. Some of the more important fixes:
- A NilObjectException caused by an undo in the IDE has been fixed.
- A regression in the debugger kept some 32-bit breakpoints from working reliably. The debugger now stops at breakpoints correctly in 64-bit and ARM targets now too.
- In Windows, if you have a global variable it can now be viewed in the variables pane.
- The Printer graphics.clip method now works as expected. If you printed a Shorts document in Windows you would have run across this bug.
- A host of Windows framework bugs were fixed. TabPanels now draw properly with proper backgrounds. TabPanels that contain sliders and scrollbars that caused the tabs to scroll off the TabPanel is now fixed. The Canvas control now properly refreshes after Scroll is called.
- iOS projects now compile when it has a launch screen with an image that has no actual pictures in the image.
If you are experiencing any of the issues listed in the release notes you should update to R1.1 immediately. It’s a shame that it took Xojo nearly a month to get this release out the door. I realize that XDC causes a huge disruption to their development schedule but the wait for this dot release was too long.
For those of you doing a lot of Windows development, are you still experiencing drawing/speed issues? Or, have you determined the secrets behind making things better/faster?
BKeeney Software Inc. is proud to announce that ARGen, our ActiveRecord Generator utility for Xojo developers, has a new major update. Version 3.0 includes a host of new features including the ability to generate ActiveRecord classes for Xojo iOS projects, the ability to use GUID primary keys, the option to include a database update module, include an audit trail module, and include a UI localization module. There are also new ways to arrange your user interface layouts that can save you even more time when initially creating a project. In addition to these major new features, ARGen fixes a number of bugs and provides more enhancements.
ARGen has versions for macOS and Windows. It costs $99.95 but can be used in limited mode at no cost. Existing version 2.x users will be provided an upgrade opportunity with a 50% discount or they contact us at support at bkeeney dot com to get an upgrade coupon.
Pricing, examples, and more details can be found at the project homepage at https://www.bkeeney.com/allproducts/argen/
3.0 Release Notes:
* iOS ActiveRecord!
* Reorder fields in the order they should be displayed. This would work both on List and Edit forms.
* Name labels for generated UI elements
* Switch between horizontal and vertical alignment for UI fields and labels
* Projects can now have individual Namespaces
* GUID support (except for ODBC connections)
* Can now include a Database Update module
* Can now include an Audit Trail module
* Can now include a Localization module
* Warnings for aggregates that conflict with Xojo (note below)
* New database connection window
* New app icon
* Oracle databases are no longer supported
* Add / Edit dialog now shows in web version (#3556)
* Icon now displays properly in alerts (#3474)
* PostgreSQL Views now working
* Control init on add and edit windows
* Preferences now correctly handles prefix and suffix settings
* Selecting suffix no longer causes a compile error
* Confirmation dialogs are now set up properly (#3643)
* MenuBarVisible is no longer false on any template windows (#3475)
* Rescan Schema works again
* Database specific PreparedStatements
* Instances of MsgBox replaced with MessageBox (#3474)
* Enhanced Save() on add and edit windows
* Listbox.Open() now has a ColumnWidths placeholder for convinience
* Desktop projects now created with HiDPI on
* Desktop projects now default to 64 bit for Mac
* Opening a SQLite project automatically attempts to connect (#3596)
* Auto-Generate UI step is now easier to understand
When using aggregate like Count(), Max(), Min() some DBs will return the aggregate as the field name.
Added code to warn on open project that there is invalid for xojo field names, and fail generate.
At the XDC Keynote a few weeks ago Geoff Perlman said they’d no longer give target dates for new features. Instead they’re going to say what’s a ‘priority’ and what’s ‘important’. Software projects are often big and complex and it’s very hard to estimate the amount of work involved with a new feature. “Happiness is all about having expectations met,” said Geoff and I think it’s fair to say that Xojo has typically been overly optimistic on when a feature is going to ship (much less when it’s going to be usable). So instead they’re going to stop predicting when a feature will be released.
If you hear them say it’s ‘Important’, it’s something they’re seriously looking into. It will be in the product in the not too distant future. A ‘priority’ means it’s either in active development or will be shortly. The Rapid Release Model is still in play which means we will still get releases three or four times a year.
In one sense I’m disappointed that they’re not going to give us any timeframe for new features. I really want to know when Web 2.0 is going to ready for testing as we have a number of projects in development or about ready to start development that it would be really nice to know if it’s a 90 day, 120 day, or longer window. Android is a nice to have feature, but since I’m not doing much mobile development it’s not that important to us, but I can see how for some it is a huge need.
In another sense I understand why they’re not going to give us target dates any more. They’ve missed every projected release date that I can think of and I’m going back a lot of years. It was about a year ago this week, in Berlin, that Geoff said that Android would be out by the end of 2017 when the reality is that we’ll be lucky if we see it by the end of 2018 (that’s just a guess on my part and having having been around a long time). I would love to be wrong on that guess but it’s a new target that involves a ton of compiler, framework, and IDE work not to mention the need for Interops (a dependency) to work well.
Estimating a project is not a science. You’re asking software developers to take a wild guess at how long a big feature is going to take. When you make that initial guess you don’t know that replacing this small piece of code will affect this much larger piece of code over here. Or cause this other piece to not work right thus forcing you to redo that other piece too.
In some respects creating a new project is considerably easier than replacing code. In new projects you’re touching everything anyway but subconsciously you’re holding most, if not all, of the work in your mind and you shape it as you go. Big, existing projects, or OPC (Other Peoples Code) projects, are considerably harder since not only do you have to read the code but also figure out the intent of the code and second guess what the original developer was attempting – not always an easy task. I’ve never seen the code for the IDE but I’d imagine dozens of people have worked on it over the years with varying degrees of competency and coding styles. So whatever work you do you have to read, interpret, change, and test to make sure it doesn’t break something somewhere else. Tack on multiple environments and targets and it’s a herculean task.
I’ve spent the last four years working with my son’s FRC robotics team (team 1982) as the programming mentor. They have six weeks to design and build a robot to a very demanding set of specifications before they crate it for competition. These 120 pound robots are relatively complex and I’ve seen it time and time again where the kids have ‘Chrono-Optimism’ in what they believe they can get done in after-school meetings (some with mentors present and some without) and on Saturdays. Granted, they spend a LOT of time working on the robot, but they’re just kids and most of them have never done anything like this before. They don’t know what they don’t know and most years they’re scrambling just to get a working robot.
This year, the group of seniors really thought about what they wanted to do. They knew it would be challenging, but they decided to change their build process and use a more modular hardware design which meant new gear boxes, wheels, framing, etc. They also decided to build two robots which, for a team that’s never done that before, was …ambitious. Then they decided that they wanted to go two regional tournaments. Again, ambitious for a team that’s never done that. From previous years they also learned something else: they were attempting to design too much on the robot. If there were three major tasks that a robot had to accomplish they couldn’t do all three with the resources and experience they had. They couldn’t change the amount of time to build the robot so they changed the one thing they could – the scope of work – and made the robot simple and sturdy.
The Universe works in mysterious ways and has ways of throwing a monkey wrench into the best of plans. The last day of build season this year happened to be a day off so the plan was to have a twelve hour work day to finish the robot and test. Instead, Kansas City had a snow storm which cancelled all school activities. The robot was not mechanically complete and not functional programming-wise. The kids were devastated. But there is a silver lining to their story.
The robot was crated away and couldn’t be worked on for weeks, but the second robot allowed them to work on the programming and driver training. The modular design allowed them to plan the work they needed to do at the tournament before it started. The simplicity of the robot meant that the work could actually get done in a short amount of time before taking to the field.
To conclude this story (because I’m bragging now), the team won their first tournament which qualified them for World Championships. They were the eight seed alliance captain in their second tournament. At the world championships, they finished 42nd of 67 teams, but were picked as part of the 6th seed alliance. They won in the quarter finals and ended up getting to the semi-finals where they were defeated by the alliance that went on to be third in the overall tournament (out of 400 teams). All because they examined their past behavior and decided to change it. They knew they were bad at estimating and changed their expectations.
I will give credit to Xojo for realizing that, like most of us, they are Chrono-Optimistic in their estimates, and decided to change how they communicate to their customers. As Geoff said, part of their job is setting expectations and they’ve been really bad at it. It’s clear that they said ‘estimate’ and we heard it as a ‘promise’ which is partially on us. So now we have what’s a ‘Priority’ and what’s ‘Important’. I don’t know if this will help them, or us, in the long run but it will be different and I’m willing to play along for now.
What do you think about this change? Negative, positive, or neutral about it?
Last week at the Xojo Developers Conference in Denver, BKeeney Shorts was awarded the Best Developer Tool as part of the Xojo Design Awards ceremony. Being recognized as a great reporting tool for Xojo makes all the hard work worth it. Often times it’s a labor of love for developer products and it’s nice to be recognized for designing something that many Xojo developers require in their products.
BKeeney Shorts is a set of classes and controls that allow developers to create complex dynamic reports. Xojo desktop application developers can embed the Reporter Designer in their applications using a simple drop-in container. Reports can be displayed in Xojo desktop and web apps using a drop-in viewer container. Reports can be exported to HTML, CSV, or PDF (using the DynaPDF plugin from Monkeybread Software). If you’d like to know more about Shorts please visit https://www.bkeeney.com/allproducts/bkeeney-shorts/
To celebrate this achievement we’re giving everyone a 20% discount for Shorts! Use http://sites.fastspring.com/bkeeney/product/shorts20&coupon=XDC2018 to redeem this coupon. Hurry, this offer expires on May 31st.
Greg O’Lone at XDC gave a talk on the progress for Xojo Web 2.0.
Web 2.0 represents two years of work. Coding started a year ago.
Goals of Web 2.0
- HTTP/1.1 compliant server
- Improve responsiveness
- Modernize framework
- New and updated controls
- DOM processing is now done in the browser
- Controls are now used with Bootstrap and FuelUX
Adding new technologies:
Server connection monitor in the framework. If the connection drops for a moment the browser can tell the user that comms is lost momentarily or gone forever.
Visual Session Controls: Want to make controls available to all sessions. Example: Chat control and notifications that all sessions can access at the same time.
Browser History Triggers: because users hit the back button the framework will store some session data and will allow the developer to restore states if user comes back.
Styles: Global bootstrap theme.
Drop-in theme replacement.
Selective control level customization.
Layout Modes: Three modes are available:
- Fixed like it is today
- Auto layout (similar to what is in iOS apps)
- Fluid: the controls flow based on the size of the container
View-Based which means that all three types can be used in nested controls.
- Updated/Unified appearance
- Keyboard accessibility
- Theme-complaint third-party controls
- Audio player
- Date Picker
Existing controls getting some new features too.
File Uploader split into two parts:
- User Interface
- File Management & Uploader
- Optional Pagination
- Dynamic datasources
- Sortable columns
- Built-in search of listbox data
- Custom Column Types
- JCanvas underneath
- Layers, Events, Drag & Drop
- Bootstrap Navbar
- Text formatting and validation on the CLIENT side
- Theme compliant
- Can be disabled
Data on demand Listbox. Loading from the server depends on the latency of the connection.
Browser consistency: Looks the same between all browsers. Everything just kind of works. No more differences between browsers/platforms.
Moving from old style to new Framework is a one-way operation. All controls will use the new control API’s. Layouts will be fixed by default.
All WebSDK controls will need to be updated.
JQuery, Bootstrap, and FuelUX on every browser.
No more User Agent parser any more. Modernizr is being used to query for capabilities.
Encouraging the use of TypeScript Definition Files.
Clearly a lot of thought and effort has gone into Xojo Web 2.0. Many of the deficiencies that were built in to the product from the very beginning are being addressed in Web 2.0. Of course we don’t know when Web 2.0 will be released, but the demo’s looked fairly well developed. I know I’m looking forward to it.
Travis Hill from Xojo talked about the progress on Android, Interops, and the Xojo Framework and API 2.0.
Interops is being used to build the Android framework.
- Need something from the OS
- Use instead of declares
- Ready to use with Xojo types. No need to worry about type conversion.
- Android will be the first platform primarily built with Interops.
- Not a separate project in another language. Built with Xojo.
- Anything Xojo is doing, we’ll be able to do as well.
Mapping the Android SDK into Interops. In 2016 they had completed less than 25% of the Android SDK. In 2017, it was about 65% and in 2018 they have considerably more than 75% but certainly not complete.
Using Interops is totally optional – like declares. Good way to think of them is that they’re pre-existing declares.
Android is being developed using Strings and Variants and using the global framework.
Major Project Milestones:
- 32-bit and 64-bit ARM – done
- Linker – done
- Position Independent Executables (PIE) is still a work in progress.
- Can execute from any address
- Required for Android
- Supported on other platforms
- Will be moving this feature to other platforms
- Native code
- Virtual code
- Android built with virtual code in mind
- Building a two-way bridge between Native and Virtual
- Mirror classes with native and virtual will be transparent to developers
- IDE Integration: Typically one of the last steps
- Layout editors
- platform particulars
- baseline project
- Build Settings
- Mac/Windows 64-bit
- Linux has issues so it remains to be seen if Linux will be able to do it.
- Android Studio provides the emulator and debug tools
- Apps use Android 8.1 (Oreo) SDK
- Targets Android 4.4+. Trying to hit the 80% mark
Travis showed a demo with three controls: TextField, Button, and HTMLViewer. Doesn’t seem like much, but is a huge amount of progress.
New Xojo Framework
The Xojo framework is dead. Ends the split personality. No more Xojo namespaces and no more ‘wall of code’. Unified Language Reference (brought applause from the crowd).
API 2.0 is NOT a new framework – it’s adding to the existing one that’s been around since the beginning. Can be added to over time with little disruption. No requirements for everything to be present. De-empasize/Deprecate old ones over time.
New names allow for behavior updates.
Exceptions on Errors
Always 0-based offset
Namespaced types (Text and Auto) will be deprecated.
Classic types will get some enhancements from the Xojo framework.
String going forward. Text will be de-emphasized and then deprecated.
Coming to String: ToString/FromString.
Optional Locale support.
Better default encodings from outside sources (web, databases).
Variant going forward. Auto to be deprecated.
Implementation may change.
Date going forward.
Timezone handling and math.
Android will ship with String/Variant types. Ship with API 2.0.
iOS adding string and variant and API 2.0 naming.
Desktop adding API 2.0. Deprecating Xojo framework.
Web adding hybrid approach. Will use existing web framework but API 2.0 as well.
Overall Goals of API 2.0
- No namespaces (though we can still use namespaces)
- All platforms consistent
- Learn one, learn all
- Clear naming
- Clear documentation
I will give Xojo some credit for admitting that the Xojo framework did not accomplish what they had hoped for. It’s clear that Text and Auto were not well received by the community despite the things they solved. In talking with one of the engineers at lunch they will be bringing some of the good ideas from Text into String and Auto in Variant.
The downside to this change is that those developers that have spent considerable time and effort learning and implementing the Xojo framework have to convert it to API 2.0. The plus side is that the new approach is less intrusive and more likely to be adopted by the community.
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
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.
- 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.