Xojo 2018 R3

The latest version of Xojo hit the internet this week.  Release 3 has a number of important new features, some changes, and the usual assortment of big and small bug fixes.  So let’s get to the highlights!

The flashiest new thing in Xojo is that it natively supports macOS 10.14 Mojave.  This means that the entire IDE (as well as all of the peripheral apps like Feedback, Linqua, and the Remote Debug Stub) draws properly when the user has Dark Mode enabled in Mojave.  

Perhaps it’s my older eyes the IDE seems very ‘light’ in color in Light Mode – meaning that there’s a lot of white and grey and the contrast isn’t nearly as prominent as it was in R2 and earlier.  Where some buttons have a slight 3D effect the buttons in R3 are flat with no grey background.  Funny enough, I think the contrast of the IDE in Dark Mode is better.

2018 R2

2018 R3

As a long-time Mac user I’m not entirely sold on Dark Mode.  Some of that is change and that I’m just not used to it yet.  In some respects I feel like I’m reverting to my college PC where light text on a black screen was the norm.  I guess the more things change the more they stay the same.

A new property, SupportsDarkMode was added to the Build Properties section to build apps with Dark Mode enabled.  To help developers the application class has a new event named AppearanceChanged to let them know when the OS has switched between light and dark modes.  

Labels, TextFields, and TextAreas running on Mojave will now use the automatic system colors to get the correct appearance on light and dark modes when text is test to opaque black (0, 0, 0, 255) and backgrounds set to opaque white (255, 255, 255, 255).  In a similar fashion, FillColor, TextColor, and FrameColor now map to proper light/dark system colors.

Since there are many OS colors available than what Xojo provides natively, you might want to look at CSTrueColors by Ulrich Bogun at https://drive.google.com/open?id=1vg-sN8_7mz18zeu9XoRWZaBc8Tm-_Enb.  

Currently Xojo does NOT support Windows dark mode but is looking into it.  A Xojo blog post suggests that Microsoft has released several API’s for dark mode and another one is due in the near future.

Incremental compiling for LLVM/64-bit targets now works.  The first run can still take some time but after that it should only compile changes.  This should significantly reduce cycle times on debugging 64-bit applications.

In Windows Xojo updated the text rendering so that it matches Win32 controls.  I’m just guessing but if Xojo ever moves away from Win32 controls the text rendering will have to change to match.  

Windows is now using the native Win32 Label control.  Overall drawing seems to be significantly faster with this change.

Among the changes is one that might affect a lot of legacy projects (we have a number of these) is that drawing directly to the Graphics property is no longer allowed.  To be explicitly clear about the change this does not affect, in any way, the graphics parameters passed into a canvas or window Paint event, nor does it affect getting the Graphics object from a Picture object.  This only affects the graphics *property* on Canvas and Windows classes.  The fact that it’s continued to work for all this time says that it was definitely time to retire this ‘feature’. 

There is also a list of 79 bug fixes.  Some Windows, Mac, and Linux framework issues fixed.  A couple of changes to MySQLCommunityServer and Postgres.  SQLite was updated.

Xojo 2018 Release 3 isn’t just about Mojave dark mode.  The 64-bit incremental compiling is a most welcome feature.  The speed increases in Windows drawing is also well worth the upgrade.  As always, please test your projects fully before releasing them into the wild.

What is your favorite new feature, change, or bug fix?  Anything causing you problems?  What are your thoughts on Dark Mode and the contrast of colors in the IDE?

BKS Tab Control

Lenexa, KS (June 20th 2018) — BKeeney Software releases BKS Tab Control
The BKS Tab Control is a set of classes that offer developers a classic “tabs control” for Xojo Desktop applications. The Tab Control can attach to any RectControl or Window, and will maintain a relationship to this parent control if and when it changes size. Tabs can be displayed in one of four directions (North, South, East, West) and individually offer options like a close button, an icon, a background color, and can be disabled.
Other features:
— Optional CloseBox can be positioned on the left of right
— If the CloseBox is selected a CancelClose event is fired
— Optional Icon can be positioned on the left or right
— Each tab can have a different background color
— Each tab can be disabled
— Each tab text can be stylized with font, font color, text size, bold, italic, underline
— Tabs that overflow the available width may be accessed with an overflow popup menu
— Works in HiDPI and non-HiDPI modes
BKS Tab Control has been tested in macOS, Windows, and several varieties of Linux with Xojo 2018 R1.1 and back to Xojo 2017 R1.  The control may work, unchanged, in older versions of Xojo.
BKS Tab Control is sold as unencrypted source code and costs $75 USD.
More information and demo project download available at:
macOS
Windows
Linux
All Directions

ARGen 3.0

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:

New:

* 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

 

Removed:

* Oracle databases are no longer supported

 

Fixed:

* 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

 

Changed:

* 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

Aggregates Note:

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. 

Serial Devices as Keyboards – Yuck!

We’ve recently had a number of projects that required the use of a serial devices in desktop applications.  In all cases the clients said the devices are, “easy to use,”  since they act just like a keyboard.  If our experience is typical then I’d hazard a guess that many Xojo developers are frustrated with them.

Several projects required the use of barcode scanner.  Having a barcode scanner work as a keyboard makes sense, I guess.  It means that it can work with literally any application, anywhere, any time.  All it needs is focus on a text field and whatever the scanner sees it puts into the control.

In another project we had an ultrasonic sensor that would take the application out of idle mode and present the user with purchasing information.  Again, it acted just like a keyboard which means it works with any application as long as you had focus in a text field.

If you happen to know WHEN this information is going to come in it’s not so bad as you can plan for it.  Putting the focus in a field and waiting for information is easy.  It’s not so easy when that information could come at any time.  Of course all of our applications had data that could come in at any time and we had to be prepared to act on it immediately.

If you rely on a TextField or TextArea getting this information the rest of your interface can really suffer.  It means that when your barcode/sensor field loses focus you have to get it back (or you lose information).  Do you do this right away or wait a few seconds?  And if you have a complex user interface how do you deal with tabbing between controls, or even simple things like a user changing a checkbox because the focus is lost on your TextField?  It can be a nightmare to try and figure out and get right.  The differences between Mac and Windows and Linux can be frustrating!

The answer that we ended up implementing was putting the barcode readers into serial mode.  I’ve not run into a barcode scanner yet that couldn’t be used in serial mode.  Every scanner has a gazillion different modes and properties (all set via barcode of course) and one of them is to make it appear as a serial device to the computer.  On Windows this is a COM port and on the Macintosh they tend to show up as a USB Modem.  If I had to guess I’d say it’s harder getting barcode readers that are Mac and Linux compatible.

Once it’s in serial mode it’s almost trivial to create a class that monitors the serial port and reads the data WITHOUT needing the focus in a TextField.  The class then distributes the data to the objects that can consume the data.  What I do is have the window or objects register itself with the class and then when the data comes in the class sends it to all registered objects.  Each of the objects has an Interface with a simple HandleBarcode method.  This is known as the Observer Pattern and there’s an example that ships with Xojo.

My ultrasonic sensor wasn’t so easy to overcome as it couldn’t be put into serial mode.  However, it did come with a Windows-only SDK (thankfully it was a Windows only project) and with a little help with Declares we were able to get it working so we could tell if someone had walked up to the device and when they had walked away.  I’m not sure what we would have done if it had been a Mac or Linux project.

Serial Devices are relatively easy to work with in Xojo (as long as they show up in the serial list).  Having to deal with devices that act as keyboards not so much.  I’d highly recommend trying to get them to work as serial devices and save yourself a ton of grief.

What’s been your experience with serial devices in Xojo?

Xojo 2017 R2.1 and Updated Roadmap

I’ve had a hellacious travel schedule the past six months so I apologize that I’ve not been up to snuff on Xojo news. Last week Xojo 2017 Release 2.1 was made public and earlier this week Xojo CEO, Geoff Perlman, penned a blog post about the short-term roadmap for Xojo. Let’s dig in!

First, the 2.1 release has a mere 16 bug fixes in it. This dot release fixes some critical Linux, and Windows bugs. A few IDE bugs were addressed and the PostgreSQLDatabase plugin was updated. Many of these bugs won’t affect everyone but it’s definitely worth upgrading from R2 if you have not already done so.

Now on to Geoff’s short-term roadmap. You can read the entire blog at https://blog.xojo.com/2017/09/19/the-short-term-xojo-roadmap/. To summarize it in a nutshell: 64-bit is taking them longer than expected.

To this I say, ‘Duh’. Anyone who expected 64-bit to be done by this time hasn’t been around very long. Xojo has consistently blown their estimates for most (all?) of their big projects. The transition to Cocoa from Carbon took a lot longer than originally announced. iOS took longer than expected. The introduction of the Xojo IDE from the Real Studio IDE was also delayed (as a side note I’m still amused at the accusation that I personally caused a 6-month delay in the Xojo IDE due to a blog post).

The point isn’t, ‘Oh my gosh, Xojo has yet another delay’ it’s that Xojo is very bad at estimating this stuff. Some of this is on them but some of it is beyond their control. Supporting mac OS, Windows, Linux, iOS, Raspberry Pi, desktop, console, and web apps is a mammoth undertaking. I am constantly amazed at the magic Xojo performs without my knowledge. To me it ‘just works’.

Apple, bless their hearts, changes things on a whim every year at a minimum (sometimes even more often than that) and causes Xojo to play catch up. And they usually do this with little notice. The current change being that the iOS Simulator will no longer support 32-bit apps so guess who has to scramble to make it work now?

Linux distributions seem to change daily. Xojo has to scramble to catch up with those changes too. They recently updated Xojo to use GTK3 and that was a big deal. They sort of had to do this upgrade because GTK2 was pretty long in the tooth. I can only imagine the internal efforts they did for testing.

Windows doesn’t change much for better and worse. The technology from ten years ago still works but that’s not necessarily the best ‘modern’ approach for Windows. Many users complain about flicker when windows are resized. This is a valid complaint but because Windows does not double-buffer their windows like Mac and Linux the older Win32 controls flicker like mad under many circumstances.

Regardless, 64-bit is the roadblock for other things. If you were hoping for Android, interops, or plugins compiled in Xojo to be released in 2017 you’re out of luck. This is what happens with a small development team. There simply isn’t enough man-hours to work around delays in some projects. This happens in ALL software development products but with a small team this impacts everything.

The only bit of good news from Geoff’s blog post is that the Windows framework is getting a big update. This update will ‘dramatically’ reduce flicker according to Geoff. No word on what exactly they’re changing though a thread on the forums from Aug 9 might give a little clue. Changing transparency seems like a little thing but perhaps they plan on implementing a double-buffering scheme. Until we find out more it’s not worth speculating. It seems like this new scheme might make it by the end of this year. So either this has been in the works for a long time or it’s not huge from a coding standpoint.

Promising services based on a product feature that doesn’t yet exist is dangerous. If you were promising Cocoa, iOS, or 64-bit versions before they were actually released you did your customers a disservice. I remember one XDC where a database ORM (Object Relational Model), similar to ActiveRecord, was shown with a lot of interest by those attending. I’m still waiting on it. The lesson is to not depend on vaporware!

So what are your thoughts on R2.1 and the Short-term Roadmap?

The Xojo Community is Awesome

Have I told you how much I love the Xojo community?  I’ve been part of it for fifteen years and I’ve met hundreds of Xojo developers at developers conferences and probably exchanged emails with thousands more.  I am amazed at how much this community helps each other and I wish there was a way to promote that as a key feature of the product.  It’s a big deal.  Really!

If you’re just starting out using Xojo know that there are a bunch of people, myself included, that are willing to help out, if we can, on your journey.  Programming is hard.  Well, I don’t think it’s hard because I’ve been doing it for so long, but it is complex at times and that makes it hard.  Just ask your question in the Xojo forums and you’ll almost always get an answer within hours.

Even Xojo pros, such as myself, have need of help.  Xojo covers Mac, Windows, Linux desktop, console, and web apps.  It does iOS apps for iPhone and iPad.  It now does Raspberry Pi for heavens sake!  It works with dozens of different databases.  There is simply no way any one person is going to know everything there is to know about Xojo.  It just can’t happen.  So yes, I go to the forums, all the time, and ask for help.

Just the other day I asked for some help with WooCommerce.  Not Xojo related, really, but certainly related to a project we’re working on for a client.  Within a few hours I had half a dozen developers private message me saying they might be able to help.  Subsequent contact narrowed that list down a bit but the point is that I have probably shaved off several days worth of work simply by asking for advice.

I am biased towards Xojo, naturally, as it’s been my primary development language for fifteen years.  I think I’d be hard pressed to find such a friendly community.  I call many on the forums my friends even though I’ve never physically met them.  The few that I’ve met in person have lived up to their forum reputations and are really friends for life.

So maybe this is my belated Thanksgiving post.  I am thankful that so many years ago I jumped both feet first into the tool.  I asked questions – many of the silly and redundant.  I became more proficient and then made another jump to start blogging about it, making products for other developers, and training the next generation of developers.

So if you are in need of a cross-platform development tool I highly recommend Xojo.  It ain’t perfect but no development tool is.  If you jump in I think you’ll love the community.  I know I do.

What say you fellow Xojo developers?

Xojo and UTExportableTypes

The folks a Ohanaware wrote a blog post a few days ago that all Xojo developers creating Mac apps should read since it involves the UTI (Uniform Type Identifiers) created for your Xojo applications for Mac OS X.

The basic summary is that there is a bug in the 2015 R2.x series (possibly older versions are affected too) that can mistakenly lump all of the UTI’s into the Exportable Types that goes into the application’s plist file. This error can cause the Launch Services database to get corrupted and in Ohanaware’s case, prevented Quicklook from previewing PDF’s.

Thankfully, there are some simple things you can do to prevent this from happening. The first and best solution is to open the FileTypes Editor in Xojo and make sure its settings are correct. Under Build Settings in the Navigator choose OS X. Then press the File Types button that’s in the Inspector. This opens the Editor. The checkboxes on the left should ONLY be checked if your app is creating the file otherwise those files will get lumped into the Exportable Types.

Screen Shot 2015-09-30 at 9.14.09 AM

At this point I’ll take a step back and let you know that I’ve never even really thought about this editor – ever. The user interface is very simple but it lacks information on what these things do. The heading on the dialog does say “Select which file types your application will accept as file drops under OS X” which is pretty clear. However, as Ohanaaware found out it’s exporting it incorrectly.

I did a quick search in the Xojo User Guide and there is a brief blurb describing the roles in UserGuide-Fundamentals PDF. Otherwise, I’ve been unable to find any documentation on the exact use of this dialog.

The second method of fixing this problem is to use App Wrapper utility. This Ohanaware utility has been around for a few years and is a great way to code sign your applications as well as get all those little nasty bits set in your application for release. Have a Retina capable application? It can verify that the assets are all there. Releasing for the Mac App Store? It can help you set the entitlements and also strip your project of verboten items that will cause automatic rejection. And now, after their experience, version 3.4.1 of App Wrapper will do check these settings and can move them from the Exportable Types list to the Importable Types (which is what they should be doing).

Because this was such a disastrous problem Ohanaware also released a free utility called “Preview Reset” for Shine customers that were bit by this bug. I’ll give Ohanaware credit for owning up to it and working diligently to find the solution.

Ohanaware reported this bug to Xojo: <feedback://showreport?report_id=40907>. The good news is that it’s marked as fixed and should be in Xojo 2015 Release 3. However, it’s still in beta so until it’s released take extra special care with your Mac builds.

The Good, the Bad, The Ugly of Deploying Xojo Web Apps

It’s been a very busy first half of the year at BKeeney Software.  We’ve just finished up three medium sized web apps.  One was deployed to Windows Server, one deployed to a Linux web server, and the last to Xojo Cloud.  We’ve done a couple of small web apps to a Xojo friendly host too.  I will describe our experiences below.

Windows Server

The first project was a CRM project where we converted a really old MS Access and ACT! system to Xojo.  The UI wasn’t all that complicated but the data conversion was a pain since it was so dirty.  We ended up using a MySQL database server.

Since we didn’t want to go through the hassle of getting an IIS server we made the decision to deploy as a standalone app.  The hardest part of the whole installation was figuring out how to create the service.  We ended up using NSSM – the Non-Sucking Service Manager http://www.nssm.cc to create the service.  After that, installation and updates were a breeze by simply stopping the service, changing the files, and restarting the service.  We are able to VPN into the server and copy the necessary files over.

The server was virtual and running on a VMWare server.  Despite our specifications the server was set up initially with a single core (virtual) processor.  Performance all the way around sucked.  We complained, the client complained, and as soon as they upped it to dual core processors (as we specified) everything went smoothly after that.

Xojo Cloud

The second project was another CRM-type project though a little smaller.  It was using an SQLite database.  We converted the data from a FileMaker database.  The data was much cleaner and more straightforward so it was a relatively easy transition.

The client decided to host on Xojo Cloud so deployment is done from with the Xojo IDE.  The only file we didn’t deploy via the IDE was the database itself which we transferred via SFTP to the appropriate shared document directory on the Xojo Cloud server.

Xojo Cloud, for the most part, works flawlessly.  There have been occasions, however, where it fails to upload properly.  It’s a frustrating experience, to be sure, but Xojo customer service has always been able to fix it.  When it happens on a weekend you’re kind of out of luck.  Here are a couple of suggestions to try and get around the issue:  1)  Restart your server via the Xojo control panel.  2) Change the application ID of your application and try uploading again.

Linux VPS

Our third application has been around a while but we switched over from using SQLite to MySQL after our little db reached about three and half million rows in single table.  It still worked but some of the queries were taking *minutes* to complete.  The decision to move over to MySQL wasn’t a hard one.

You’d think that updating an existing app would be easy.  This one turned out to be anything but easy.  Since this one bites a lot of people deploying Xojo web apps to various Linux distorts it’s worth writing them all down.

  • Until Xojo web apps are 64 bit you’ll have to make sure the 32 bit compatibility libraries are installed.  Each is different so it’s ‘fun’ finding them.  Honestly, check on the Xojo forums to see what people have found.  Hopefully, this becomes a non-issue with Xojo 2015 R3 being scheduled to compile 64 bit apps.
  • Make sure permissions are 775 for all files and directories *including* the overall directory.  The latter one has bitten me more than once.
  • Make sure permissions for the config.cfg file is 664 or 666 (I’ve seen it both ways and I’ve never had a problem with either one).
  • Make sure the owner and group of the files matches that of the system.  If you’re FTP client shows owners/groups and it says something like “mixed” you’ve got a problem.  You’ll need to figure out how to change the owner/group on your own.  This may involved getting SSH access.  It may be easier to work through the CPanel File Manager to upload files because you’re guaranteed, then, to have the right owner/group.
  • Make sure the .htaccess file has been uploaded.  Since it’s a hidden file on Mac OS X it’s easy to miss this one.  If you zip the output directory and then upload the zip it will be there automatically.  If you’re zipping the contents of the directory don’t forget it!
  • Does the server have libicu installed?  Xojo 2015 R2 requires libicu and if you don’t have it your app will just crash with maybe an obscure error in the error log like “Can’t find missing file.”  I had this happen to me this week and when I reverted to 2014 R2 the app started up right away.  If you suspect you’re missing a library and have SSH access, try starting the app via the command line.  It will tell you what the missing library is.  You don’t always have SSH access so that’s kind of a drag.

Not really an issue with web app deployment, per se, but it’s an issue we deal with quite a bit.  MySQL on Mac OS X doesn’t care what the case is of a table or view.  tTable (mixed case) is the same as ttable (all lowercase).  On Linux and Windows this does not appear to be the case.  I know there’s a system variable that can turn this on or off but for this project the client had existing databases on the server and I really didn’t want to muck anything up on them.  Many queries that were running great on our local (Mac) system were not on the server.  Switching everything to lowercase isn’t a big deal (especially with ActiveRecord) but some db apps this will be a nightmare.  So don’t forget to test!

1701 Software Inc. http://www.1701software.com

We have deployed to 1701 Software several times in the past six months for ourselves and for various clients.  We’ve found their servers to be Xojo friendly from the get go (not so with most hosts) and their service is excellent.  They also offer a number of database options that Xojo Cloud does not like CubeSQL and Valentina in addition to MySQL and PostgreSQL.  Frankly, the fact that they are Xojo developers too makes them the top of my list of non Xojo hosting services.  Their prices are pretty good too for those that are price conscious.

That is our experience with deploying Xojo web apps in the past six months.  When everything works right it’s incredibly easy.  When it doesn’t – well, you tend to swear like a sailor.  Hopefully you’ll find this guide to be somewhat useful.  Anything I forgot?

Happy Coding!

[Edit:  Updated to not include an implied timeframe for the R3 release.]

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?

BKS Spell Checker 1.0.2

picBKS_SpellCheckerWe released a new version of our Mac/Windows spell checker plugin today.  Version 1.0.2 works better with foreign language Hunspell dictionaries that are in different encodings.

The Spell Checker plugin has two different spell checking modes.  In the first mode it  works with the native spelling dictionaries on each platform.  On all versions of Mac OS X (that Xojo supports) and Windows 8 and above it uses the built-in spell checker dictionaries.  If you can’t, or don’t want to, use the native dictionaries you can use the Hunspell dictionaries.  There are hundreds of Hunspell dictionaries available for use in a variety of languages and speciality industries.

There is no Linux version at this point due to lack of interest.

More information, including downloadable demo, pricing, and usage is available at http://www.bkeeney.com/allproducts/bks-spell-checker-plugin-for-xojo/