Berlin Xojo Developer Conference

We are 30 days away from the biggest Xojo developers conference of 2017.  Monkeybread Software is hosting this two-day conference in Berlin, Germany May 4th and 5th.

There are currently 79 attendees from all over the world which is an impressive number.  Let’s make this event even bigger.  Sign up today at http://www.monkeybreadsoftware.de/xojo/events/berlin-2017-event.shtml.

I’ve made no secret of this over the years – I love these events!  It’s a great way to connect with other Xojo developers and talk Xojo and meet all those people you’ve ‘talked to’ on the Xojo forums for years.  I’ve also made first contact with a lot of clients at these events too.  In some cases it’s been the only face-to-face meeting I’ve ever had with them.

Hope to see you in Berlin next month.

Xojo: the Best Secret in the Programming Industry Part 1

Xojo turns twenty years old in 2016.  That’s an extraordinary feat not only for a business but even more as a development tool.  The simple fact is that 90% of all businesses in the United States fail within two years.  There’s a significant number of the remaining businesses that fail two years after that.  Xojo has beaten the odds from a business standpoint.

When it comes to software development tools and languages it seems that every time you turn around there is another programming language of the moment that is the hot, hot, HOT thing that everyone has to learn and then two years later it is relegated to old, has been, technology.  Each one promises to make software development easier and faster and in most cases they solve A problem but not necessarily all problems.  In reality, every development tool still requires a competent programmer to do some work – you get nothing for free.

Xojo has been renamed multiple times first as REALbasic and then as Real Studio but in each name iteration it’s been the same product:  a rapid application development platform and language that creates compiled desktop, console, and web applications native for Mac OS X, Windows, and Linux.  Not only in 32-bit but also for 64-bit.  For a vast majority of users it really is as simple as checking a box captioned “Windows” to create a fully functioning Windows application that works the same as the one you’ve create on the Mac or in Linux.

Xojo started out twenty years ago as CrossBasic before Real Software Inc purchased the rights.  It was modeled after the very successful Microsoft Visual Basic and those roots are still visible today.  Xojo initially ran only on Macintosh but within a few years it ran on Windows.  It now runs on Linux too.

Xojo has transitioned from 68k Macintosh desktop apps, to PowerPC apps, to Carbon apps, and finally to Cocoa apps.  Recently they transitioned from 32-bit applications to 64-bit applications for Mac OS X, Windows, and Linux and introduced Linux ARM as a new target.  This transition is still in progress (the IDE is still 32-bit and remote debugging isn’t available for 64-bit yet) and they’ve announce more transitions on the Windows side to start moving away from the venerable Win32 framework for some things.

Besides desktop apps Xojo also creates console and web apps.  Web apps are a different beast as they expect to keep a constant connection between the browser and application on the server.  This makes web apps work a lot like desktops apps and eliminates a host of typical web app issues.  These web apps can be deployed as either cgi applications or as standalone apps.  The cgi applications work with Apache or IIS servers.  Standalone builds require no server and act as their own server which makes them very easy to deploy to any Mac OS X, Windows, and Linux machine.  Much of the code used in a desktop app is reusable for web apps.

A few years ago Xojo introduced the ability to create iOS applications which introduced yet another target.  iOS transitioned quickly from 32-bit to 64-bit after one of Apples famous ‘deprecations’.  iOS built under Xojo works with the iOS Simulator that comes with Xcode to accomplish remote debugging.  Just a few weeks ago Xojo announced that in late 2017 Android will become another target.

Xojo is an integrated development editor, or IDE, that allows a developer from within one application, to write all the code, layout all the user interface, and include any resources necessary for it to work.  It has a series of built-in editors that mostly mean you’ll never have to leave the Xojo IDE.  Working on desktop, web, console, or iOS projects expose the available libraries and controls for those targets.

Xojo lets you compile final executables or do remote debugging to any of the supported platforms.  So while working on Mac OS X I can remote debug an application in Windows running on another machine on the same network or in a VM environment.  While remote debugging, any exceptions that occur in code are revealed in the IDE and users can view variable values and see the call stack.

These things are nothing spectacular by themselves because many development tools can do them.  What makes Xojo remarkable is that is does this regardless of what platform you develop on.  A Windows developer, Mac OS X developer, and a Linux developer get the same capabilities and can deploy to any of the other platforms.  The only exception is that to do iOS you must be using a Macintosh and have Xcode.

Like any tool it has its detractors but it’s managed to transition, quite quickly at times, due to sudden announcements from Apple (who thought they’d move away from PPC?  Or iOS apps would be 64 bit that quickly?) and from the inevitable changes from Microsoft, and the sometimes daily changes in Linux distributions.  Some users complain about the number of bugs introduced in new releases or that bugs sometimes go years without being fixed.  It’s my opinion, though, that every developer complains about those things in their development tool of choice.  Xojo averages a release every 90 days (with the occasional dot release) and always add some new features and fixes many bugs.

The Xojo community is incredibly welcoming to new people.  There is not a lot of condescension given to new users that ask simple questions on the Xojo forums.  Unlike some other venues there is not a lot of vitriol going on.  The Xojo engineers frequent the forums and answer questions.

Since Xojo has lasted twenty years they’ve already beaten the odds.  There is every indication that they’ll be around many more years.  They are no Apple, Google, or Microsoft, but yet they keep churning out new versions that attempt to keep up with the ever changing development landscape with what many would consider a very lean development staff.  Most of the development staff are former users so there is a high level of familiarity with the needs of the user base.

So why don’t more developers know about Xojo?  With the features and history described above it seems like everyone show know what Xojo can do for them.  That doesn’t seem to be the case so why not?  In part 2 we’ll examine some of those reasons.

2016 Xojo Design Award Winners

img_4508Xojo announced the winners of the 2016 Xojo Design Awards today in Houston, Texas during their annual Xojo Developers Conference (XDC). These are applications and tools made with Xojo that were considered the best in their respective categories.
Best Overall:  EverWeb http://www.everwebapp.com

Best Business App: Light Blue https://www.lightbluesoftware.com

Best Consumer App: Alinof Timer Pro https://www.alinofsoftware.ch/apps/products-timerpro/index.html

Best Cross-Platform App: PubCoder https://www.pubcoder.com

Best iOS App:  Studiometry Touch http://oranged.net/studiometrytouch/

Best Developer Tool:  Everweb http://www.everwebapp.com

These are great examples of what some awesome developers are doing with Xojo. Congratulations!

XDC News:  Android Support

iurThe 2016 Xojo Developer Conference kicked off in Houston, Texas today.  Geoff Perlmann, CEO of Xojo, Inc. took the stage this morning to deliver his keynote speech.  The biggest news of the day is that Android support is coming for Xojo.

Many Xojo developers (myself included) find that iOS support is great but without Android support it’s not complete.  Geoff announced that in the fourth quarter of 2017 Xojo will have the ability to compile Android mobile applications.

This is a big deal and a daunting challenge for this team.  It appears that they’ve done their homework to figure out what they want to do.  Details are scarce at this point but they already know they will compile down to native code and not Java.  They will also use native controls like Xojo does for iOS.

The target version of Android that they are aiming for is JellyBean (version 4.1) or better.  Roughly 97% of all Android users will be covered.  Sadly, version 4.1 was released in 2012 .  I would have thought that 4.4 (KitKat) or better would be a better choice.  Let’s hope that gets changed before release.

Geoff did not mention if Xojo is planning on adding additional staff.  The reason I bring this up is that I find a twelve month timeframe to implement a completely new platform.  A more realistic expectation is that it will be released in beta form and it will be 2018 before it’s ready for more usage.

More details as learn about them.

XDC News:  2017 Roadmap

img_4508In todays keynote address, Geoff Perlmann, CEO of Xojo announced the major features coming to Xojo in the 1st, 2nd, and 3rd quarters of 2017.

First quarter:

64-Bit builds will be out of beta.  This means that XojoScript will be 64-bit capable as well.  This also means that 64 bit builds for Windows will include application icons and version info.

Remote Debugging will be available for the Raspberry Pi.  This should make using and developing on the Raspberry Pi that much better.

Remote debugging will also be available for 64 bit!  This should make the transition to 64-bit much faster at this point.  I know that we are holding off moving to 64-bit builds because of the lack of remote debugging.

String and Join functions that are pretty slow in 64 bit builds will now be considerably faster.  Again, really good news for some developers that have experienced this.

Second and Third Quarters:

New projects will be 64-bit by default.  32-bit builds are NOT going away.  What is going away is 32-bit versions of the IDE and while nearly all Mac OS X and Linux OS’s are already 64-bit this might cause some pain for Windows users that will have to update to 64-bit.

The new Xojo framework will come to Console, Web, Desktop and Mobile.  (Technically speaking mobile is already using the new framework.)

New plugin format:  Currently plugins in Xojo are written in C/C++ and are only supported for console, desktop and web application.  Developers will be now be able to create plugins in Xojo that will include resources, windows, etc. that are not possible in the current format.  The advantage of this is that it will allow anyone with a Xojo Pro license to create plugins and could (potentially) dramatically increase the availability of 3rd party controls.

These plugins are compiled into an intermediate format that is not human readable.  Presumably this format is something that can’t be reversed by the average developer.

This new plugin format will become the preferred format but the old style format will be supported for the foreseeable future.  It will be supported for Mac OS X, Windows, Linux, Linux ARM, and for iOS.  This last item is a high want by many Xojo developers.

Fourth Quarter:

Interops is a new feature to take the place of Declares in Xojo.  Declares are great but there’s no autocomplete and there’s absolutely no data type checking.  Interops should make this much easier.

More news coming up!

XDC News: Xojo 2016 Release 4

img_4508In today’s keynote address, Geoff Perlmann, CEO of Xojo announced the major features of Xojo 2016 Release 4.  Release 4 is scheduled to go beta in November and go public in December.

The existing Windows framework drawing is currently done via GDI or GDI+.  Xojo recently dropped Windows XP support and this allowing them to update how Windows apps work.  In the upcoming release Xojo will switch to Direct2D and DirectWrite.

These two technologies will allow better picture scaling and better alpha channel support.  And while GDI+ does have some hardware acceleration these new libraries have full support for hardware acceleration.  In testing, Xojo says that intensive drawing routines should be roughly 280% faster than R3.  End users should only have to recompile their apps to take advantage of this new feature.

Geoff did not talk about flickering but I will attempt to find out more this week.

Among the other changes:

Windows HiDPI will now officially be out of beta.  In addition the Windows Xojo IDE will be released as HiDPI capable.

Xojo Cloud users should see exceptionally better upload speeds.  Starting in R4 the libraries used in the upload are cached so they are not uploaded every single deployment.  This should speed up deployment and testing quite a bit.

More news to follow.

The Power of Meeting Face to Face

In Kansas City this past weekend I attended MidAmerican 2, or WorldCon.  WorldCon is a Science Fiction and Fantasy fans dream come true.  Thousands of people from around the world attended hundreds of sessions covering television shows, movies, author readings and signings, many sessions on how to write, and much more.   It is a long convention at five days that culminates with the Hugo Awards ceremony (think the Academy Awards for science fiction and fantasy).

I am an aspiring science fiction writer (nothing published yet but I’m working on it!).  This convention was an excellent way to immerse myself with professional and amateur writers and learn.  There is something powerful about hearing people that have already “made it”.  Many of them still fight “Imposter Syndrome” and many have issues with the business of writing.  Writing is a solitary business and many are introverts and selling themselves is often nerve wracking.

Do these issues sound familiar?  They should.  In many ways, Xojo developers are much like writers in that they work in a vacuum with little feedback from others.  I know I personally struggle with Imposter Syndrome despite having done this gig for fifteen years and being ‘successful’ (whatever that means).  And much like writing, the only way to get better at Xojo programming is to do Xojo programming.

It seems a bit anachronistic to fly somewhere to meet with people.  After all, the internet makes this easier, right?  There is something powerful about being face-to-face with another person and being able to provide instant feedback.  We also tend to be much more polite in person than online and that’s a huge plus in my opinion.  I’ve met some wonderful people, in person, that online seem rude at best and sometimes simply belligerent.  The internet might make people more accessible but it seems to removal societal filters too, sadly.

In a month and a half Xojo is holding its annual Xojo Developers Conference (XDC) in Houston, Texas.  At XDC, Xojo developers from around the world will join together for three days of sessions covering practically every development topic you can think of.  And if you have a question that’s not covered you’ll be able to find someone to help you.  Besides the many amateurs and professionals attending you’ll have ample opportunities to talk to the Xojo engineers.

It’s not uncommon for businesses looking for a developer to attend XDC.  It gives them the unique opportunity to talk to many Xojo developers in a short amount of time.  We (BKeeney Software) typically speak to one or two prospective clients at XDC each year.  If you’re a consultant this conference should be on your ‘must attend’ list as it can pay for itself many times over if you land just one project.

Today is the last day to save $100 off the conference registration.  Sign up to learn and be inspired and to make some new friends.  See you in Houston!  http://www.xojo.com/store/#conference

 

We Are Part of the Problem

For some users, Xojo 2016 R1 hasn’t been a great release.  Some Windows users are experiencing frequent crashes.  For others (myself included), working in the WebPage Layout Editor is an exercise in frustration because it’s unusably slow.  We blame Xojo, but we, the beta testers, are culpable for these problems as well.

Before you start angrily sending in comments hold your horses.  R1 had a really long beta cycle.  Clearly, Xojo had issues with figuring out HiDPI for Windows and their work isn’t finished yet (hence the beta tag for HiDPI in Windows).  It happens and some times you have to ship an imperfect product.  We always have the option of NOT using the latest version of the product.

Some will say that Xojo shouldn’t have released R1 in the state that the Windows version was in.  That’s only partially true.  Xojo uses their own product all day long to create their product.  They, more than many of us, see the warts in their product and I know they try really hard to eliminate as many of those as possible.  But they use it differently than we do so I wouldn’t expect them to find every bug.  That’s where we come in.

The beta program exists so we can bang on the product using our own real-world projects.  It’s up to us to find and report the fringe cases and use the product in different ways that what the IDE expects.  I know that in this beta cycle I was swamped with consulting work so I only fired the betas up occasionally.  So whatever problems there is on me and on everyone else in the beta program that didn’t test.

I will grant you that the only incentive we have for participating in the beta program is a less buggy product.  For some that’s enough but when you’re busy trying to get your own products out the door there’s not much incentive to work even more and find bugs for someone else.  In my opinion, this has always been the problem with the beta program.

Some of use are also guilty of not starting testing until the Final Candidate releases.  This is actually the worst time to start testing because it means only show-stopper bugs will get fixed.  We really need to start testing with the early beta’s.  That’s when Xojo needs us the most to bang on their product.  Is it fun?  No.  Is it necessary? You bet because waiting until Final Candidate is worthless to them.  To us too, because those bugs might not get fixed for 3 months.

Did Xojo help us out in this cycle?  No.  There were times they were putting out a new beta every day.  Sometimes with only a couple of changes from the previous version.  I would download a beta with the intention of working with it and before I could get to it a new beta would be announced in the next couple of days.

I don’t know about the rest of the people in the beta program, but the high frequency of beta releases meant I looked at them less.  I don’t know why but it was.  I saw the announcements rolling in and I shrugged in apathy.  Perhaps I felt the frequent releases didn’t properly value my time.  I only have so much time to devote to beta testing and the frequency was off-putting.  I like to use a version for 3 or 4 days (or until I find a major bug a report it).  With so many releases I just didn’t test.

I propose that with the next cycle Xojo limit their public builds to once a week (maybe a Thursday or Friday release).  This respects my time a bit more since my only incentive is to make it a better product.  Frequent public releases says that they’ve not vetting their product enough before giving it to us.

I also think there needs to be something in place that identifies what type of beta tester we are.  Are you mostly a Windows user?  Then Windows specific changes get highlighted for you because you’ll be most likely to see them.  Same with Mac OS X, iOS, and Linux users.  Desktop, console, and web app users might also be a designation.  I realize this doesn’t fit in with the current generic “hey, we have a new beta” announcement.  But it’s clear from R1 that the generic approach didn’t work.

We have too many major bugs in this last release to call the beta program a success.  It’s not doing what we need it to do.  So how do we structure is to so that our time is respected and we actually report bugs before Final Candidate stage?

What about you?  What suggestions do you have to help us and Xojo out at the same time?

Xojo 2016 Release 1

Xojo 2016 Release 1 was released today.  This much anticipated version is all about Retina and HiDPI display support.  In addition to that, there are, as always, the usual mix of new features and bug fixes.  Let’s get to it!

The IDE is Retina Aware

The IDE itself is now Retina capable and all of the icons and images used in the IDE have been replaced with high resolution images.  On my 27 inch 5k iMac it’s quite a noticeable difference to my aging eyes: everything is very sharp.  As with many apps once you start using the high resolution version it’s hard to go back to a lower resolution.

Before you jump into this version you might want to do some testing.  On relatively new iMac the Web Layout Editor is very slow.  So slow as to be almost unusable.  This only happens on existing projects since new projects seem to work just fine.  Perhaps it’s a combination of project size and/or web page complexity or number of Web Containers.  I really don’t know but I’ve submitted a Feedback report showing the symptom and an application sample from Activity Monitor.

Your Apps Can Be Retina Aware

In the last Xojo version we were introduced to ImageSets and that feature is now more useful in 2016 Release 1.  The ImageSet allows you to add a normal sized image (1x), a 2x image, and also a 3x image.  Mac OS X only uses the 1x and 2x images but some Windows 10 resolutions will use the 3x image.

HiDPI support for Windows is officially beta and I believe that’s mostly because the various versions of Windows that Xojo supports all do HiDPI slightly different.   Currently Xojo does not support Window 10’s per-display scale factor and will use the scale factor of the screen it was launched on.  TextArea’s only display in large size, the HTMLViewer and MediaPlayer is not scaled, BevelButtons don’t display, and Image Set Icons do not appear correctly in toolbars.  Obviously this is less than ideal for Windows applications and you probably don’t want to release a Windows app with this set.

With Retina/HiDPI support is a new Application shared property called SupportHiDPI.  When set to true, Xojo will build your application with Retina and HiDPI awareness.  When set to false it will build apps that worked the same was as previous builds.  Sadly, this property cannot be changed at runtime because it would make enabling it for Mac OS X a no brainer but leaving Windows as is.

As you can imagine, Retina/HiDPI changes a number of important things.  The Picture class has a new constructor that can take one or more bitmaps in addition to its size.  All bitmaps must have the same aspect ratio or an invalid argument exception is generated.  One question that I’ve not explored for myself is how exact this ratio must match.  What is the precision on this check?

The graphics object now has a ScaleX and ScaleY property.  For pictures the scaleX/Y are always set to 1, but a graphics object passed in from the paint event might have a ScaleX/Y set to 2 on a Retina display.  Graphics.Pixel is now deprecated (NOT REMOVED).

Windows have a couple of changes too.  There is a new event ScaleFactorChanged on Mac OS X that is an indicator that all graphics for that Window should be invalidated.  A read only ScaleFactor tells you what the scale factor is for this window.  The Canvas object has a similar ScaleFactorChanged event on Mac OS X as well.

Local Language Reference

Retina is not the only new thing in R1.  The Local Language Reference has been revamped again and if you are a Dash user you’ll notice that it shares much of the same look and feel.  Searching for an item in the Language Reference, in my opinion, is considerably easier in this new version and I find I like it better than the online version.  Besides being able to search for any event, property, class, enum, etc the local language reference allows you to go back through your search history rather quickly.

Web Framework Changes

The web framework received a number of important changes.  Perhaps the biggest and most important to web users are that WebStyles have changes their implementation.  The change notes say “User defined WebStyles now have more specificity than framework applied styles.” which I have been lead to believe means that WebStyles now work properly in all cases as there were fringe cases where styles were either ignored or improperly applied.  During the beta cycle Xojo asked us to test web apps to make sure nothing broke.  In my testing I didn’t see any issues.

The connection type of a web app can now be set with a command line option.  The WebListBox received some love too.

Miscellaneous Fixes

  • Build times have been improved.
  • Xojo.net.httpsocket now works in Mac OS X console and web applications.
  • A memory leak in NSWindow was fixed in the Cocoa framework.
  • The FileTypes editor has received a number of bug fixes and changes.
  • 40 changes to the documentation and examples.

Conclusions

With all of this work on Retina/HiDPI applications for Release 1 I am disappointed at the lack of project examples for HiDPI and Retina.  Sure, the SupportHiDPI is an easy thing to do, but for many of our applications that create images on the fly we are only left with some fairly vague instructions.  A Xojo Blog posted today http://blog.xojo.com/a-journey-of-a-thousand-pixels might be your best bet in understanding some of these changes in more detail but even I scratched my head with some of the implementation details.  Actual example code that show the practical implications of Retina/HiDPI and creating images would have been very welcome.

I’m relatively happy with 2016 Release 1 though not without some reservations.  Since the number of Windows controls in HiDPI that don’t scale properly is fairly large it’s not ideal that you can’t turn off HiDPI for Windows but keep Retina on for Mac OS X.  Sure, you can always do two builds but it’s not an automated option.  Performance issues with the Web Page Editor is also troubling and perhaps this means there’s a dot release in our near future.

There are quite a few things on the horizon that Xojo needs to tackle.  Full debugging in 64 bit and a 64 bit IDE is perhaps the biggest one and the HiDPI stuff is surely a distraction from that important requirement.  This beta cycle was really long and it makes you wonder how much their schedule has shifted just to get HiDPI (mostly) working with some obvious work still to do.

What are your thoughts on Release 1?

Xojo Code Folding

I was talking with another Xojo developer and we both commented on how neither of us use Code Folding in the Code Editor.  I’ve been using Xojo for fifteen years and this developer is at least ten years.

For-Next

For-Next regular

If you’re not familiar with code folding it’s the ability to collapse an entire branch of an If – Then statement, Select – Case, For – Next, While – Wend, and probably a few others.  The code doesn’t go away, it’s just temporarily hidden.  It’s a convenient way to hide a good chunk of code so you can easily see what else is going on around it.

For Next Collapsed

For Next Collapsed

The other developer and I discussed this issue for a while and we really couldn’t come up with a good reason why.  The best reason we could come up with is that it *looks* like the code has been deleted.  Like I said, it wasn’t a good reason but at least it was a reason.

Do you use Code Folding? If not, why?

Have a Merry Christmas and Happy New Year folks!  Stay safe, enjoy time your family, and happy coding!