Xojo Should Scream ‘Business’

With the recent news that the Freemium model failed to bring in the much hoped for additional revenue it’s worth taking a look at the short comings of the product and what can be done to attract not only more customers but, even more importantly, profitable customers.

Let’s be clear, this is not a hit piece against Xojo.  We have four full-time Xojo consultants that spend a vast majority of our time developing Xojo desktop and web applications for clients all over the world.  For all of its faults Xojo is a great tool that serves our customers well.  Can it be better?  Absolutely!  So please take this article as what we feel would help us make it an easier sell to prospective clients and what makes our lives easier.  I think these items might also attract those new, and profitable, customers.

The Xojo IDE itself has been the topic of more than a few of my blog posts.  Frankly, I hate the Navigator and how it switches Editors on you.  It steals the focus in odd ways and the back/forward history even after two years is still wonky.  The Navigator shows too much information when I don’t want it and not enough when I do.  Double clicking into objects makes sense but double clicking nearly anything else does not.

Many people complain about workflow issues and I can’t disagree.  I know I’m less efficient with Xojo than I was with Real Studio (the old version).  With Xojo I spend way more time mousing than I feel I should.  And many of the really nice features of Real Studio are gone from Xojo – especially in the Layout Editor.

At the 2015 Xojo Developer Conference they acknowledged that the IDE is not as good as it could be.  That’s an understatement for those of us spending all day long in the product but it’s a start.  The sad thing is that the IDE is so tightly coupled with the language that they can only fix en mass rather than incrementally.  This means we might have to wait a bit for these changes.  We can only hope that whatever the new design is it’s a signifiant improvement.

I would also argue that Xojo’s insistence of having a UI to create method definitions, properties, events, and so on, are a detriment to adoption.  I know of no other language that forces a developer to jump through the same hoops for declaring methods, properties, constants, etc.  The Code Editor only allows a single method to be displayed at a time so at best it’s clunky and I see no advantage to this design.  At that point many feel it’s more like a toy than a true development environment.  Does it help newbies?  I’m not convinced since plenty of newbies pick up other languages.

The people that can afford to spend a good chunk of money on upgrades and 3rd party tools are businesses.  Xojo should scream business at every step of the process but yet it doesn’t.  The Xojo website talks fast and easy but not ‘business’ and business is where the real money is.

The Xojo IDE has a built-in reporting tool.  It’s weak and I know only a handful of developers that regularly use it.  Most people abandon it and hit the 3rd party market (we sell a set of reporting classes for this very reason).  The fact that Xojo itself doesn’t use their own reporting tool for any report (that I’m aware of) is a shame.

Many businesses need to create PDF documents.  The main solution is a 3rd party plugin to simply create a PDF document.  An even more expensive solution (same developer) exists to view them.  Neither solution works with the built-in reporting tool.

Most businesses require some basic user input controls such as Word Processing, Date, Time, and Calendar.  Xojo has none of those so any business owner will immediately have to hit the 3rd party market.

One item that has come up for years is the lack of a good grid control.  I’m not talking about a listbox replacement but a true grid control that can show native controls in any cell.  Now I understand that making it truly cross-platform is hard but you’d think a company that makes a cross platform development tool would be up to the task.

These are just for Desktop apps.  Web apps have similar issues with an even bigger lack of standard controls out of the box.  The Xojo WebListbox in particular is very weak.  The WebSDK helps alleviate some of these issues but the 3rd party market hasn’t exploded with solutions.  But again I would argue that Xojo should be providing basic no-frills controls without a customer having to hit the 3rd party market.

I’ve had several discussions in the past couple of weeks with developers migrating away from FoxPro and FileMaker.  Xojo would be an excellent choice for them if not for some of the above reasons.  Data binding seems to be an issue for some and Xojo deprecated it a number of years ago.  I have no idea if it’s coming back.  I can argue that I’ve never used a binding system that’s been great but for many business applications it’s a way to quickly get up and running.  I personally think binding gives many developers a false sense of security but I also see how it can be used to quickly develop a complex UI.

Xojo database applications are also pretty dumb.  There is nothing that Xojo does to help you when it comes to table and field names.  At some point you have type in an SQL statement and you won’t know if you have an error until runtime.  By that point it’s way too late and it’s frankly one of the reasons why we developed ActiveRecord to eliminate many of the silly and stupid mistakes that are common to programming database applications in Xojo.

The Database Editor that’s built-in to Xojo isn’t very useful.  Yes, it can help create SQLite databases and attached to all of the supported database servers, but it’s features are very weak.  To the best of my knowledge you still cannot create an integer primary key field that’s auto incrementing.  No wonder why new people to Xojo are confused.  In some ways I feel it would be better if Xojo removed the database editor entirely.

Why would any business owner choose Xojo over any other development platform with the issues I’ve just described?  The fact is some choose don’t.  After 64 bit applications and fixing the IDE workflow issues I strongly suggest a heavy focus on attracting business users.  They are the ones that can afford the more expensive licenses and right now Xojo isn’t necessarily a tool that attracts them.

It sounds like I’m really pissed off at Xojo.  No.  I simply make my living with the product.  If even just a few of these issues are addressed it makes my life, as a consultant, easier.  Make Xojo a great tool for businesses and the non-professional developers will follow.

What makes Xojo a great development choice?  It’s a RAD environment that is easy to learn.  The language is easy for beginners to pick up and yet powerful enough for advanced developers to extend it.  It creates very good cross platform desktop applications for Mac OS X, Windows, and Linux, web applications that be run on nearly any computer, console applications that run on any computer (soon including Raspberry Pi), and it even lets you create iPhone and iPad applications.  Add in some better business features and what’s not to love? At that point Xojo screams business.

So what say you my fellow Xojo developers?  Are these worthwhile goals or stupid ones?  Did I miss anything?

Xojo Ends Freemium Model

This week the Xojo blog announced that they were ending the Freemium model and going to back to the standard 30 day trial period model. As you would expect this has led to an outcry of folks on the forums and there are lots of opinions as to why Xojo is wrong to end the Freemium model. They’re wrong and here’s why.

Xojo said that the Freemium model increased downloads but didn’t change buying habits. The original thinking was that more downloads would get more eyeballs and thus more revenue in the long run. The IDE was free to try and use until you wanted to do a final executable.  It didn’t.  Period.  Their two year experiment with the Freemium model failed.

I don’t mean to belittle the hobbyist developers out there, but there is ample evidence that many of them simply just ran their apps in the IDE rather than compile them as standalone executables, thus not even purchasing an inexpensive desktop license. Obviously this was not the intent of the Freemium model and certainly violates the spirit of the model if not legally as well.

We can argue all day long as to why the freemium model didn’t attract more paying customers. I’m sure there is not just ONE reason but combinations of many smaller issues and here are some wild guesses. Perhaps desktop programming is experiencing a decline and perhaps web apps aren’t growing as much as once thought. Perhaps iOS isn’t an attractive target without Android. Perhaps the lack of business-only features hurts them. Perhaps the IDE design pushes some people away. Heck, I’ve asserted for a long time that the insistence of dumbing down the IDE in favor of newbie programmers is a detriment to the health of the platform. <Insert your favorite theory here>

One argument I might buy is that they didn’t give it a long enough try.  Some times it takes a while for things to take hold.  Add in that two years ago they changed the name of the company/product and lost whatever internet search rankings they may have had and it’s quite possible that it’s only now that people are finding Xojo.  It doesn’t matter now.

Regardless, the bottom line is that the Freemium model didn’t increase revenue for Xojo. At best, it means that revenue stayed the same and, at worst, they lost revenue. No company can stay in business by having static or negative revenue.  Expenses only go down through layoffs and no one wants that.  It’s the right business decision or otherwise we might not have our favorite development tool around in another year or two.

So while it’s sad it didn’t help them I can’t complain. They know the financial numbers better than we ever will. They told us the reasons so it’s time to move on.

What do you think?

XDC Notes:  Compiler Notes AND Exception Line Numbers

So far I’ve written a couple of posts about information gleaned from the XDC keynote address last week.  One session that revealed some additional information was Joe Ranieri’s Compiler session.

Joe started off by talking about what’s happened to the compiler in the past year.  The list is pretty impressive since that includes iOS (32 bit AND 64 bit), 64 bit for Mac, Windows, and Linux, as well as adding the new framework, and adding better compiler error messages.

He spent some time explaining why the Using and Global keywords came about and how they are used.  It’s interesting that you can mix and match the two frameworks and how that might be desirable.

Iterators were next up in the presentation.  Iterators allow our classes to be used with For Each loops and Joe said that iterators are generally more efficient than alternate approaches.  Two interfaces are available Xojo.Core.Iterator and Xojo.Core.Iterable.  A good example of the new interfaces are in the Xojo.Core.Dictionary class.

The new Text datatype is the attempt to solve the String datatype deficiencies.  Strings could be text or a bucket of bytes which led to issues with encoding.  Text is always a valid textual representation and is a series of Unicode code points (a way to think of this is an array of characters that might be ASCII or a valid Unicode character- either way you, the developer, don’t need to care).  When converting to Text you always give it the Encoding you want so it’s never in question.  One nice feature of Text is that you can convert to and from a String with no penalty.

The New Auto datatype is the replacement for Variant.  Auto’s perform NO conversion of data which led to sometimes subtle issues with Variant as it would gladly convert from datatype to datatype regardless if it made sense or not.  Auto will only do conversions that the compiler would (such as doubles and integers) but raise exceptions when it comes across something it can’t do (like strings to integer and visa versa).  Auto preserves type information exactly so you can use Introspection to determine the type.

New for 2015 R3 is more 64 bit targets.  This includes GUI projects on Windows and Mac OS X, console and web projects on Linux, Windows, and Mac OS X.  Porting, for most of us, should be straightforward.  However, there are a number of problems we’ll face.  Among them are Declares, Integer size assumptions, and Plugins.

A new 64 bit aware plugin SDK is due out soon and Christian Schmitz from Monkeybread was showing off his plugins running in 64 bit apps with no issues (it’s my understanding it was NOT using the new SDK so I’m sure he’s got some work to).  The new SDK is entirely C based and the overloaded C++ functions are going away.  Most of the long deprecated functions are doing away too.

Declares will be a problem, though.  Of particular note is the Windows Functionality Suite.  It won’t work in 64 bit and you’ll have to find replacements for those things you use.  Mac OS Lib is in better shape but needs some updating too.

Structures need to be updated for 64 bit apps to.  The default structure alignment of 1 means it puts each field right after each other and this is wrong for 64 bit apps.  If you use the structure alignment of 0 it will align the structure ‘naturally’ which matches was C does.  I’ll be honest, this was interesting news but way above my pay grade in understanding.  Talk to Joe if you have questions on the implications of this change.

Also new in R3 is customizable array sorting.  Currently we can do this using SortWith but now we’ll be able to pass in a delegate.  Joe really seemed pleased about this addition but I think the implications won’t be immediately noticed by the community.  I for one don’t remember the last time I had to sort an array since we generally load arrays sorted in the order we want later.  You might find this useful.

Joe wrapped up his talk with some roadmap items.  For R3 the IDE debugger is still 32 bit.  Obviously it needs to be 64 bit and that will happen.  The better compiler error messages initiative will continue as well as Xojo-specific compiler optimizations.

Perhaps the biggest bombshell that came out of the roadmap portion was exception line number information!  This means that we should be able to get information on which line of code caused the exception.  I believe at this point several people clapped as determining which line of cause caused an exception can be difficult to determine.

I followed up with Joe after the session and while it’s not finalized, here are the plans.  The compiler will spit out two files on the build.  The first is the application and the second debug information.  When an exception is called there will be a binary blob that can be saved and sent to the developer.  There will be a tool included with the IDE that takes that blob and can show you the original line of code that caused the issue.  AND it will show you the stack like the debugger does now.  It will not have any variable or argument information.

Regardless, this is a feature that people have been requesting for years.  This should lead to better error reporting and hopefully better programs!

The compiler session was the only Xojo led session, that I attended, that had any sort of roadmap information presented (with the exception of the Keynote).  It was informative and was a wealth of information.  This session gets a five start review (except for the purple code against the black background – sorry Joe).

See anything that gives you hope?  Anything makes you want to mope?

XDC 2015 Recap

The Xojo Developers Conference is my favorite week of the year.  It’s where I go to renew friendships, make new ones, talk to potential clients, learn from other Xojo developers, and learn what Xojo is up to.  Along the way there’s usually a surprise or two and this year was no exception.

The first surprise from XDC was that all sessions were recorded.  All attendees will get access to the sessions.  Currently it’s unknown if they will be available to the general public for free, or for a fee.  During the wrap-up session several people gave an impassioned plea to make these available to everyone at no cost.  The argument is that their experience with other conferences showed attendance actually goes up after releasing session recordings.

Not really much of a surprise since they’ve been telling us this for over a year now, but 64 bit builds are coming in 2015 R3.  This is indeed welcome news in a  software world that’s quickly becoming 64 bit.  From what I gather from people way smarter than me (insert joke here) is that 64 bit won’t really change anything in our apps and won’t give us much, if any, enhancements, and will make some things slower.  As Geoff joked at the conference, let’s hope that 128 bit computing doesn’t come any time soon.

Drag and Drop for web applications is coming for R3 as well and I expect this to be a big deal.  There are just some times of applications that do well with a drag and drop environment.  Think graphical editors where you have an object that you select and move by dragging it.  The current web framework has drag events but they should absolutely not be used – ever – since they don’t really work like we expect.  Drag and Drop might very well be my favorite news from XDC.

Raspberry Pi apps built using Xojo.  I think this is a wonderful addition to the product.  Raspberry Pi is a hugely popular processor because of its price and it’s used in a lot of places.  Hobbyists and the DIY crowd really like it and I’ve seen more and more ‘professional’ level projects with them too.  Heck, my sons 3D printer is run by a Raspberry Pi.  The XDC crowd didn’t react much to it when they announced it but as the week went on it came up in conversation more and more.  What a great way to introduce Xojo to new developers!  Really, the only question that’s come up is how much will it cost?  We already know it will be part of the Pro license but what about those that don’t need all the other stuff?

One unexpected surprise was the mention of the long deprecated and removed SpriteSurface and SuperSpriteSurface.  It seems that more than a few people got their start in Xojo/REALbasic developing games using it.  SpriteSurface wasn’t a great class, in my opinion, but it was enough to get started and getting people exposed to the language.  Perhaps we’ll see a Son of SpriteSurface in the future?

One thing that I expected to hear more about but didn’t was Auto Layout.  Norman had a session on it but other than there wasn’t a mention of it anywhere.

This isn’t a surprise because I’ve been many XDC’s now, but the official evening events are usually a lot of fun.  This year there was a mystery dinner theater that most found entertaining but the river cruise to watch the bats come out at dusk was awesome.  What goes on after the official events is even better as clumps of developers go exploring and Austin is a great place for exploring.

I encourage you to go to an XDC.  It’s a very nice event where you’ll learn a lot not only from the sessions but from those attending as well.  No word on where next year’s XDC will be. The cities under consideration:  Seattle, San Antonio, Miami, New Orleans, and I believe San Diego.  If you have a preference, be sure to let Xojo know.

So that’s my recap of XDC 2015.  Did any of the news surprise you?  Anything you expected to hear more about but didn’t?

Xojo Developers Conference 2015 Keynote Notes

Geoff Perlman from Xojo spent an hour this morning talking to the attendees about what Xojo is working on and there was some interesting news.  So let’s dig into the highlights!

In a major change of XDC policy all sessions at this years conference are recorded!  All attendees will get access to all of the videos in June.  According to an announcement in the Xojo forums, these recordings will be for sale at some point in the future.

If you look on the App Store, you can find an XDC iOS application that contains the list of sessions, give feedback, as well as maps.  This app required a bunch of technologies currently not built into Xojo for iOS:  Notifications, iBeacon, and camera access to scan QR codes.  Furthermore, this app and administration application will be open sourced.

Xojo Cloud servers will pretty much double in most of their specifications while keeping the price the same.  The small server will now support DB servers (Postgres and MySQL), have 1 GB of RAM, 20 GB SSD drive, and 200 GB outgoing bandwidth.  The medium and large servers have similar upgrades and all of this will be available in June.  Xojo will contact customers to help them migrate their servers.

Web apps are getting drag and drop capabilities.  Starting in R3 developers can specify if controls can allow a drag or accept a drop.  This includes controls.  The API is similar to the way desktop apps work with drag and drop.  In fact, it’s a little easier than desktop, and while Geoff didn’t promise anything he said it’s possible that this API may make it to desktop at some point.  No word if there is drag and drop being added from client file system to the browser.  I will try to follow up on this.

Xojo gave a little history on how the Xojo IDE came about.  When they redid the Real Studio IDE they wanted a modern looking IDE, that was more approachable, had better search results, and had less tab management.  However, they acknowledged this morning that it has some shortcomings.  The panes take up too much screen real estate, too much time spent hiding/showing panes, to much dependency on the mouse, poor Layout Editor workflow, and poor project Navigation.

Xojo is in the process of designing changes to address these issues.  The changes will reduce pane management, be more keyboard friendly, improve the Layout Editor workflow, and greatly improve project navigation.  No idea on when this will occur as it’s a big change.  And there’s no real way to incrementally change the IDE so it’s an all or nothing change.  Let’s hope that it doesn’t take the two years it took to go from Real Studio to Xojo.

Starting in R3, Raspberry Pi (Linux on ARM processors) is supported.  This turns out to be an interesting addition since these tiny little processors are inexpensive and used in many embedded and hobbyist applications.  This is an interesting new target and might bring some new developers to Xojo.  This new target is included in the Pro license.

Also in R3 we will get the first opportunity to build applications in 64 bit for Mac OS X, Windows, and Linux.  Geoff showed off the Feedback app built as a 64 bit application.  He also said that if you are using plugins it’s likely that your app won’t work until plugin developers can get them 64 bit capable.  Attendees will get Alpha one (emphases on the one) where 64 bit compiling only works on Mac OS X.  Later R3 alphas will work on all platforms.  However, for R3 the debugger is still 32 bit.

Sometime between now and next years XDC we will be able to create plugins using Xojo.  These are available for iOS and 64 bit Mac OS X, Linux, and Windows applications.  32 bit desktop apps will not be supported.  What’s interesting about the new plugin format is that it can contain resources (images, sounds, etc) that current plugins can’t do.  These new plugins can also interact with the IDE meaning that you can have dialogs and editors.  This is very exciting news and should lead to some interesting developer solutions.

EDIT:  Geoff worded this poorly. What he meant is that you can have plugins that use the GUI framework. There’s nothing in the announced roadmap for extending the IDE itself.

Retina support is currently being worked on.  In R2 for iOS we now have image sets and your application will pick the right image resolution at runtime.  This will get moved into desktop targets and into the IDE in 4th quarter 2015.

Updates for Windows.  Geoff showed us a currently usage chart for Windows.  Windows 7 and 8 are now accounting for over 80% of the installed base.  Therefore, starting with R3, Xojo will not support builds in Windows XP.  While Retina support for Mac OS X will come soon, he did mention that Windows HiDPI support is coming.

EDIT:  This was poorly worded as well.  Support for Windows HiDPI is not in the announced roadmap, just that it’s something Xojo would like to tackle at some point.

Those are the highlights.  If you have questions, let me know below and I’ll see if I can get them answered.  Anything particularly excite you?  Anything you dread?

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?

The First Law of Demos

It’s the last full week before the Xojo Developer Conference in Austin.  I’ve gone through my presentation on Reporting Tools in Xojo at least once already.  I have the Keynote presentation done (added a few things), have the sample projects done and ready to upload to the website.  You’d think I’d be done, right?  Wrong!

The First Law of Demo’s says that unless you’ve done the demo multiple times on the hardware you’ll actually use it’s as if you’ve never done it in the first place.  I should know, I’ve been standing in front of a group of people to do a demo only to have the first element fail and then flounder away for the next twenty minutes with plenty of, “well, if this worked I’d be able to show you this feature.”

I have learned from my mistakes, the hard way.  Several times.  Here are Bob’s rules of effective demo’s.

Rule #1:  Disconnect from your normal network/regular computer

There are things floating around on your drive that you tend to use all the time.  So when you take your development project off your home network, or move to a separate machine, you’ll quickly find the things that you forgot include in your demo packages.

In my case, I discovered that a Xojo project had references to graphic files that weren’t included in the folder I moved to the presentation machine.  The graphics weren’t necessary and it was easy to fix but how embarrassing to be in front of your peers to have a simple error like that occur.  It shows a lack of preparation.

Rule #2:  Run all of your Demo’s in the latest version of the software

This sounds silly, I know, but I found that one of the reporting tools I’m talking about in my session doesn’t work with Xojo 2015 R1 and R2.  For whatever reason I was using 2014 when I first created the project and didn’t run into the problem until I started working with it on the laptop which had the latest version of Xojo.

Another reporting tool I’m talking about in my session had to have a number of libraries installed to work properly.  And then it needed a newer version of its plugin.  These issues were not very hard to fix when I have reliable internet access and access to all my files, but once you’re away from home that’s not always the case.  Again, if this happens in a presentation it looks like you have not prepared.

Rule #3:  Practice saying your presentation out loud  

Speaking your presentation is important in a number of ways.  First, it will show you where you have not prepared enough.  If you find yourself um’ing and ah’ing in a particular session that’s an area to do again (and again).  Since you can think faster than you’re speaking you’ll often find yourself saying “I need to mention this.”  Having this happen during your actual presentation is a bad time.  Practicing beforehand will show you these problems.  Practice multiple times to catch even more of them.

I’m a good writer (I’m sure that’s open for debate) and I have my ‘inner voice’ that talks to me when I’m reading something.  That’s not good enough when practicing for a presentation because your inner voice lacks depth.  It lacks the pauses and breaths that you need when speaking.  Practice your presentation as if there are people in the room.  Pause for effect.  Pause for eye contact.  And in technical presentations pause for people to wrap their head around the idea.  Silence is good in a technical presentation and that pause is never as long as you think it is.

A lot of people have a fear of public speaking.  I can’t say was overly enthused about the subject a few years ago either.  I decided to tackle that fear and enrolled in a local chapter of Toastmasters (TM).  At this point I have achieved the Competent Communicator award and feel more comfortable speaking in a crowd.  Frankly, after two years of TM it’s hard not to evaluate all speakers and count their use of um’s and ah’s.  Toastmasters is a safe and friendly environment to learn how to speak in public.

Rule #4:  Practice, Practice, Practice

This seems intuitive but I’ve seen it happen to myself and others way too often.  The more you can practice your presentation, out loud, the better off you’ll be.  I can’t remember which Toastmaster’s speech I was giving but I didn’t have the same preparation as I normally did and it showed.  My use of fillers words was awful, I fidgeted a lot more, and I was uncomfortable with the topic, and I had to use my notes more often than I wanted.  I did okay but it was not my best speech.

Steve Jobs was known for his awesome keynote speeches where he introduced new, sometimes buggy, products to the world.  He practiced, on stage, with the actual product hundreds of times until everything seemed magical and when something didn’t go as planned he could make joke of it and move on (and use the backup device).  That last bit is very hard, but if you’ve practiced your presentation to the point where you’re dreaming of it you should do okay if things go awry.

Rule #5:  Relax

I can’t say I’ve ever been to a technical presentation where the audience was hostile to the speaker.  We usually have a choice on what sessions to attend and we are there to learn something new and hopefully be entertained.  The audience is pulling for you!  When you make a mistake during your presentation know that we’ve been there and had the same thing happen to us.

Toastmasters has another fine tradition of telling a joke to start off their meetings.  It makes everyone relax a bit and if the joke, even an awful joke, can get a chuckle or two it’s a great way to start a presentation.  If you can do a joke somehow related to the topic you’re even better!  One word of caution on jokes, though, unless you’ve practiced the heck out of telling this joke don’t bother!  The timing of joke is everything and unless you’re are comfortable with it don’t screw it up (unless you’re comfortable enough to botch the joke and recover from it and make everyone laugh anyway).

So that’s it.  I have a lot of work to do before the conference next week.  I have to practice some more and when I get tired of talking about it I’ll do it again once or twice.

Hope to see you at the conference.  Please stop me and introduce yourself.  I really enjoy meeting my fellow Xojo developers.

Xojo 2015 Release 2

Xojo Release 2 went public this week.  This release is a typical mishmash of new features and bug fixes.  So let’s dig into it!

iOS

The DatePicker was added to iOS.  This is a most welcome addition and let’s you switch between Time, Date, Date and Time, and Countdown Timer.  There’s still no generic data picker which is a shame.

The Launch Images and App Icons folders for iOS has now been replaced with an editor that allows you to drag and drop images into it.  If the image isn’t the appropriate size for the selected image a message appears saying what the dimensions of the image is and that it will be scaled to fit.

[Edit]   One thing I forgot (because I didn’t see them in the release notes) was that build times are much better in R2.  From comments I’ve seen it may be an order of magnitude faster.

Web Apps

If you are using the HandleSpecialURL or HandleURL the RequestHeaders now has a Secure property telling you if the request came in over a secure channel.  If you are using SSL Certificates they can be specified on the command line.  Another new web feature is the ability to set the HTTPOnly property attribute in the Session.Cookie.Set method.  This should work as a preventative measure against cross site scripting attacks against Xojo web apps.

New Framework

The new framework is making its way to more and more of the overall package.  The Xojo.Data, Xojo.Crypto, and Xojo.IO.Folderitem are now available for all targets and platforms.  The Xojo.Data namespace includes the ability to read/write JSON (no work on XML yet).  The Xojo.Crypto framework gives you access to MD5, RSAEncrypt/Decrypt, RSASign, RSASignVerify, SHA1, SHA256 and SHA512 hash methods.  Xojo.IO.Folderitem gives  you file handling.

Xojo.Net.HTTPSocket now works for all platforms (except Xojo Cloud).  It should be noted that HTTPSocket is now ONLY asynchronous.  No longer can you wait for the response but now you have to use the events from the socket.  This is really a better way of using the HTTPSocket but if you’ve been using it in the old framework synchronously you’ll need to adjust your code accordingly.

[Edit] The new HTTPSocket supports HTTP 1.1, automatically supports proxies on all platforms, and performs proper certificate validation.  It also no longer performs polling on the socket so it should be have significantly lower CPU usage.

The Xojo.Core.Timer now works properly on Mac OS X 10.7 and 10.8.  Apparently it didn’t work properly in older versions of Mac OS X.

Miscellaneous

For many, the recent addition of the Windows ICU DLL was a major setback as they were quite large.  You’ll be happy to know that they’re now statically linking them and removed the unused portion of the libraries so the built package is now considerably smaller.

The IDE receive a large number of bug fixes including a couple of memory leaks.  They also fixed how deleting items works and how the focus works when switching between tabs with the Code Editor displaying.

According to the release notes there are 147 total items that were changed in Release 2.  This number seems a little low in comparison to some previous releases.  Given the short period between the R1 release and XDC I think this makes sense and the engineers have a lot of work to do in getting ready for XDC.

I did not get as much of a chance to run the beta as I usually do but there hasn’t been a lot of chatter on the forums about issues either.  What little I did with the beta was solid and this looks to be a decent release.

Have any comments about this release?

Database Field Madness!

Two clients in the last several weeks have shown up with the exact same issue and it’s time to talk about it.  In both cases the clients had a field in a table that could contain multiple sets of data.  This is a really bad idea and if you find yourself doing it…well…stop it!

In the first case their company table has an email field and at some point in their past they decided that some users needed two email addresses.  Instead of creating an additional field for an alternate email address they simply decided to concatenate the data into one string separated by a comma.

To be honest I’m not sure why it sounded better to concatenate the data rather than create a second field but that’s what they did.  This decision was made years ago, of course, by a developer no longer working for the company, but it’s now up to me to ‘fix’ it.

With emails being prolific it might make more sense to have an email specific table that tie to the customer and can be inactivated.  This solves a number of issues.  It lets users have more than one email addresses.  The other thing it does is keep a history of the customer email addresses so if you are trying to verify a user account via the phone it might be a way to verify their identify when all else fails (not that I’d solely use that).

In the second case the customer table has several fields that can grow over time.  One field has notes separated by carriage returns, another field has billing data and another has payment data and each has ‘records’ in that single field separated by carriage returns and the data in each record separated by pipes.

Example:  The notes field for a single customer might be something like this:

6/20/2010 This is a note

6/30/2010 This is another note

7/5/2014 This is another note that could be pages long.

If you find yourself designing your database like this STOP right now and step away from the keyboard!  Databases are really good at having tables with related data.  Your notes, bills, and payments tables would all have a foreign key references back to the customer table.  That way you can have as many of those children tables as needed without affecting the customer table.  Having fields that grow exponentially in a single record is a bad thing.

Another issue that I see a lot is that you, the programmer, should never, ever, generate your own record id’s.  Let the database do that unless you have some really special-use scenario where you can do a better job of it.  To be clear, I’ve never seen this scenario.  Instead, your primary key should be an auto-incrementing integer and is something that you should never be able to modify.  That’s not to say that you can’t create your own ‘human readable’ code but it should never be used as the primary key of your table.

Another thing, take the time to use the native data types for the database.  If it’s an integer use an integer field type.  If it’s a date then use a Date or DateTime field type.  Booleans, if not a native data type for the database you’re using, can be a TinyInt with a length of 1.  Your conversion to and from Xojo will not be an issue and you let the database do a tremendous amount of work for you.  One client had an Amount field set up as string.  To get a total amount they had to load the entire recordset in, loop through it, convert the string to a double and keep a running total.  Instead, they could have done a simple Sum in an SQL statement and let the database do all the work!  Trust me, it’s much faster that way.

Those are my database hot button topics.  My DBA wife (i.e. The Database Goddess) has her own hot button topics and has beaten them out of me convinced me of the error of my ways and I no longer do them (or at least not without a reprimand).

In most cases the clients didn’t know any better and I’m sure at some point in my distant software development past I did some silly things like that too.  Those silly bad habits were beaten out of me after several accounting projects where database speed was essential.

What sorts of database blunders have you seen that now drive you nuts?

Xojo Desktop vs Xojo Web App Development

The question comes up every now and then on what’s the best target to develop for:  desktop or web.  The answer is sometimes pretty straightforward but, in reality, the answer should be “it depends.”  You see, each target has some very good strengths and also some bad weaknesses that you need to evaluate before you start coding.  Let’s go over some of those issues.  Let’s start with desktop apps.

Xojo has been making desktop apps for it’s entire history.  Thus it is very stable and mature and there are a lot more 3rd party libraries and plugins available.  You get most, if not all, of the goodies that come along with the desktop environment and this can mean your desktop apps can have most of the buzzers and bells that modern users demand.

With desktop apps, if you need 10 more copies, it’s as simple as installing them on new machines.  These days there’s not a lot of issues deploying to Mac OS X and Windows and most versions of Linux, but still, you need to test on all supported platforms.

The major downside to desktop apps is deployment.  Each user has a copy of the software and depending on your needs/requirements you might need to ensure that everyone be on the same version.  Example:  You’ve created a desktop app for a veterinary clinic that handles everything from pet checkin to billing.  All of them connect to the same database so when you introduce a schema change in the database you need all the clients to use the newest version.    For a small organization this might not be so bad but scale that up to a corporation with several hundred copies of your software.  A good organization might have a good IT department and can deploy your software to everyone at once, but my experience says that most organizations don’t handle this well.  So your software has to be programmed to be cognizant of database versions and check at startup and complain if it’s not what it’s expecting.  From experience it’s a pain to deal with.

Desktop apps that are part of an n-tier system also need to be programmed differently.  You can program each client with all the logic it needs, but then you have to worry about record locking issues (i.e. who wins if two users are editing the same record at the same time).  You also have deployment issues, again, since you’re back to the issue of updating every client every time there’s a little change in logic.  The better solution is to have a middleware application that handles the business logic and is the go-between between the client apps and the server.  The middleware app does all of the business logic and handles the transactions between the database and the client apps.  It’s a fair bit of work and is not what I would consider a simple undertaking.  But at least you generally only have to update the middleware app most of the time and the clients can stay the same.

Web apps, on the other hand, have several advantages over desktop apps.  First, they are n-tier by design.  Each client has its own set of logic via Xojo WebSessions even though there is only one application running.  The user runs in a browser and everything is processed on the server.    So when you need to update your web app you shutdown the old one, replace the executable and the next time someone hits the URL the newer version is there and running.  Having only one instance to update is really nice (and quick).  Web apps eliminate many deployment challenges.

Web apps aren’t perfect though.  Since they are generally exposed to more random user interaction via the web you spend way more time dealing with security and making sure nefarious users don’t get into your system or abuse it.  All of your database operations should use PreparedStatements to make sure SQL injection attacks cannot happen.

Web apps run in a browser.  That’s both good and bad.  Users can access your app as long as they have internet access.  In some areas this is no big deal and for others it’s a huge deal.  Browsers also have a lot of built-in security to keep bad things from happening on your computer.  This security also limits what your browser can do in terms of file handling local.  Xojo does not currently support drag and drop operations with the browser.

Xojo web apps are also not as stable and mature as the desktop side simply because it’s younger.  That’s not the same as unsafe but it does mean there are not as many 3rd party options for Xojo web apps.  Some controls, in particular the listbox, are vastly inferior to their desktop counterparts in terms of capabilities and may not be good enough for your needs.  Web Containers go a long way towards solving this issue but it’s not ideal.

Not all web browsers are created equal.  Some perform better than others and all of them have gone through tremendous growth in the past ten years as the internet has become ubiquitous.  This means there are a lot of different browsers, and versions of those browsers, being used by the general public.  Testing the various browser type and version combinations is critical and despite all the efforts of Xojo to get it all right, the speed of new browser releases does mean issues pop up now and then.  Mobile browsers have their own set of issues that you might need to take into account as well.

Desktop apps have a huge advantage in that they don’t have to convert text to UI like web apps do.  For example loading 1,000 rows in a desktop listbox, while slow is blazingly fast compared to doing the same thing in a web app.  1,000 row list boxes in web apps are SLOW simply because the server has to create all that html data, send it through the internet to the browser, and then the browser has to reassemble it for the user to see.  To get around this most websites do data paging where they only show you 25 to 50 records at time.  Again, not hard to do but one more thing to develop.  Also keep in mind that mobile browsers try really hard to minimize data connections over cell connections so what seems fast on your desktop might be incredibly slow on a mobile phone.

Perhaps the biggest issue with web apps (not just those made with Xojo) is scaling.  Your app will react differently when accessed by 1000 simultaneous users than when it has 10.  The way around this is to do load sharing and balancing using NgInx and works well on Apache web servers.  Finding a good web server to host your web app can be challenging too.  Until Xojo releases their 64 bit support for web apps it will be increasingly difficult to find and install 32 bit compatibility libraries that work with Xojo web apps.

As you can see, there’s is no right answer.  Both desktop apps and web apps have their place in the world since they each have strengths and weaknesses.  Before you start development work you need to think through the implications of doing each.

Happy coding!  Was there anything I forgot to mention in the debate of desktop vs web apps?