New Web App Training Series

BKeeney Software is proud to announce a new 4 1/2 hour video training series for subscribers at  The new LinkShare Web App series takes budding Xojo developers from nothing, to a fully functional web application.  This eight part series is designed to familiarize the beginning and intermediate developer on how Xojo web applications are created and how to create the basic infrastructure required for most modern web applications.

Just a few of the topics covered:
• Project organization
• Database integration using ActiveRecord and ARGen
• Safe password handling, storage and login procedures
• Sending emails and how to communicate with the app via URL parameters
• Basic WebStyles
• Basic WebPage, WebDialog and UI layout and interaction
• Much, much more

The series comes with source code the Xojo developer can use in their own projects.

BKeeney Software has 183 separate videos, with over 52 hours of Xojo and Real Studio training video and source code at  The site is a Xojo web app and has served up over 7,750 hours of streaming video to thousands of developers since it went live.

More information at or contact Bob Keeney at support at bkeeney dot com.

Thoughts on Xojo Web Edition

When Web Edition for Xojo (then Real Studio) was released I can’t say I was overly impressed.  It was missing some features and was buggy (to put it mildly).  I was of the opinion that it just wouldn’t take off.

Since then the worst of the bugs were fixed and the worst of the framework problems were addressed and there’s been a steady improvement in the product in practically every release.  In my consulting business it’s went from being a ‘gee that’s a nice thing to have’ to being roughly half of our overall Xojo consulting business.

The fact that we had very little web development experience hasn’t stopped us from using Xojo for a lot of projects.  It’s great that a WebButton and a regular desktop Button and that a WebPage and Window act the same from a developer standpoint.  All the code experience that we learned over the course of a decade in desktop apps was, with a few notable exceptions (*cough* constructors *cough*), was immediately transferrable to web apps.  While there is a learning curve it’s not like we had to learn a completely new programming language to do some large and complex web apps.  In fact, we turned down work before Web Edition came out simply because we didn’t have the experience and in-house know how to do the work.

Our clients seem willing to forgo the numerous capabilities and power of a desktop app for the more limited capabilities of a browser based app.  I think the biggest reason being that web apps don’t have distribution issues.  There’s only one instance of the app sitting on a server somewhere.  Web apps also work in almost every desktop browser and even work with most mobile web browsers.  Heck, you can even configure the web app to look different based upon what device it’s being viewed on.

There are some disadvantages, of course, to Xojo web apps.  You can’t just put them up on any ol’ server.  You pretty much need a VPS or use the new Xojo Cloud (which is just a specially configured VPS).  Then you have to worry about 32-bit compatibility libraries but, honestly, once you get the first app running on a server the rest of them are pretty easy.  I’ve not had the pleasure of getting a Xojo web app working on IIS but I hear it’s not a pleasure, nor quick, experience.

Apps running in a web browser have a limited subset of capabilities. With Xojo web apps you can’t use drag and drop anywhere out of the box (I think you can do some of this with JQuery but I’ve not tried yet).  The controls, particularly the WebListBox, are lacking a lot of functionality, and there’s just not a wealth of 3rd party controls available for Web Edition yet.

Security-wise, Xojo web apps are compiled making it very hard to compromise an app even if a hacker gets into your server.  There’s still work to make your app secure from SQL injection attacks but that’s a relatively simple thing.  Much of the work is really securing your server so that it’s secure and that’s one thing that Xojo Cloud is doing well (perhaps too well based on my recent experience).

So the question, Dear Readers, is what are your biggest likes and dislikes about Xojo Web Edition?  What do you wish it did better or differently?

Xojo Developers Conference 2014

Geoff Perlman of Xojo gave the keynote address at the Xojo Developers Conference (XDC) today.  In his hour long talk Geoff talked a lot about Xojo Cloud and a little bit about the upcoming iOS version of Xojo.

This years XDC sold out and attendance was up over 16% over last year.  Attendees represented 14 different countries and over half were first time attendees.  Early on in the presentation Geoff acknowledged over 20 attendees that have been using Xojo since version 1.0.  He also presented Marc Zeedar (of Xojo Developer Magazine) with having attended every single conference.

Geoff then went on to acknowledge that the name change from Real Studio to Xojo has gone well.  There is one issue in that a sports drink made it to market about the same time with the same name.  The two separate companies are on friendly terms and on Friday all of the attendees will get a bottle of the sports drink.  This may or may not be a good thing on a Friday in Las Vegas.

Xojo Cloud

Xojo Cloud has now been released.  It has a number of benefits including zero configuration, one-click deployment, no maintenance, and better security.  The latter issue is incredibly huge since Xojo discovered that it takes about 15 minutes for a brand new server on the internet to get its first unauthorized access (attack).  With Xojo Cloud the servers are automatically configured with security in mind.

In the long run anyone creating web apps does not want to be a security expert.  However, those developers should be, so the security focus of Xojo Cloud is worth the additional cost.  Xojo admits that it is not the cheapest host, but it doesn’t take too much of your time doing configuration and maintenance on your (non-Xojo) server to make up the cost difference.

Xojo is paranoid about security and this is a good thing.  It was during XDC 2013 that their servers got hacked.  They feverishly moved all their backups into the Xojo Cloud servers.  Since then there have been no infiltrations (that they know of) in over 15 million scans.  When they reviewed their security with RackSpace (their server provider) who told them, “Only our most paranoid customers have this much security.”

Framework Changes

Parts of the Xojo framework have been been around for 15 years.  In that time Xojo has supported Mac OS 68k and PPC, Windows x86, Linux, Mac OS X, Cocoa, and Web (to name a few).  Obviously there are a few areas of cruft that have crept in and there are inconsistencies in the API.  Add in iOS, ARM, 64 bit, and LLVM and Xojo has some serious issues in the framework.  Thus a new framework is in the works.

The existing framework (classic) consists of the desktop and web.  Each of these sits on top of the console framework.  The console framework consists of non-ui items like FolderItem, TextInput/OutputStream and BinaryStream.

With the new frameworks there will be framework namespace for each platform (desktop, web, iOS) and will contain things that are specific for each.  For common elements (like buttons) these will live in the UI framework that lives underneath the platform frameworks.  The ultimate goal of this change will be copying common UI from a desktop app and pasting them into a web app the controls will just work with no problems.  This can’t be done now as the desktop and web controls have separate frameworks.

The new framework will arrive first in console, then web, iOS (initially it will have its own version of the new framework), and then finally desktop.  My advice is to not stress out about this until more information is known.


The big news of the day is that iOS is very close to being sent to alpha users.  The current schedule (always take schedule news with a grain of salt) has the alpha shipping in May with a beta in June and hopefully shipping to end users in the third quarter of 2014.

Pricing will be $400 for those users that want iOS only.  Pro licenses will go up $200.

Geoff did an initial demo with the iOS application running in the iOS Simulator.  This is similar to things we’ve seen before.  What was new, however, was that Geoff did a final build, used Apple’s Configuration Utility and ran the demo app on an iPhone and an iPad.

From this evidence it seems that work on the LLVM and ARM compiler is well advanced.  Built iOS apps are currently only 32 bit.

Another interesting tidbit from the demo was that Auto Layout is in full force in iOS.  Auto Layout is a super advanced way to handling automatic layout for windows, views, containers, etc. and is much more advanced than the simple locking properties.  This should really help in localization.  Other than the quick aside in the demo there was not much said about it.

All-in-all the keynote was fairly quiet.  Not a whole lot of new information was given out.  Ta ta for now and if I find out more information I’ll share it with you.


Container Control Love

We are big fans of Container Controls for a lot of reasons.  Containers, in my opinion, are one of the most powerful tools in Xojo and they are often misunderstood and under used, in my opinion.

Complex UI

Complex UI

In the first picture you see a very complex layout.  The client only wanted a single window for everything.  Each item in the family list is its own container.  Each of those containers has a tab control and you can see a fairly typical layout.  In almost every case each of the tabs has its own container as well.  The project takes it to the extreme but adding these dynamically is really fast.

Screen Shot 2014-02-15 at 2.06.15 PMThis project was a conversion from VB6 and everything really was in one window.  It was a nightmare to debug and in the process of converting it and breaking it apart into containers we found numerous errors they had never been able to find due to the shear amount of code in this one window.  To load the container we simply create a new instance of one (if it doesn’t already exist), give it the database file and the container literally does everything else.  The Xojo window has about 200 lines of code for everything.  The old VB6 window had over 10,000 lines of code.

Containers let you create really complex UI layouts and treat it as a single entity.  I see this a lot with projects with tab controls where each tab has 30 controls on it and you have 10 tabs.  That’s a LOT of controls and logic to load and save the data to them.  What we do is create a container for each tab and the container has the load, validate and save logic.  Then we place the container on the tab control or page panel.

Doing things like this does a couple of things for us.  First, it makes the coding of the Window very simple.  Instead of having 300 controls you have 10.  When the Window is opened or when the user presses the tab to expose it to the user we tell it to load the data (this is where using ActiveRecord comes handy).  The window itself doesn’t know or care about the individual controls.  So all the code for the container is where it makes the most sense – in the container.

The second thing this does is simplify what the IDE has to display.  I’ve made no bones about it that I do not like the Xojo Navigator.  The more objects you have in it the worse it gets.  Finding stuff is hard and I find it to be a royal pain.  Using containers reduces this issue.

The only real drawback to using containers at this point is that they draw really slow in the Layout Editor.  This appears to be addressed in the latest 2014 R1 beta but until it’s actually shipped you never know if it will get pulled for some as yet undiscovered show stopper bug.

Containers are also the only reasonable way to make repeating rows of controls.  Many people bag on Xojo for not having a powerful grid component but I think by using Containers you can do a lot of the same things.  To make a very sharp repeating rows control you need to have at least 4 different containers.  The overall container, an inner bounds container, the overall list of rows, and finally the row itself.  This is for desktop apps only since you can do the same thing in Web with only two containers.

Doing this type of repeating row control is not possible in carbon apps since the controls do not respect the container bounds but it works in Cocoa apps.  In Windows there is no issues but in Linux you need to use the new transparent property on all of the containers so the controls will respect the bounds of the container.  Xojo just did a blog post on this.

The drawback to the repeating row strategy is that you don’t want to have hundreds or thousands of rows.  Each container consumes memory and they can quickly make your UI slow and unresponsive.  At that point it’s much better to page your data so that your user can only see x number of rows at a time.  We usually settle on 50 as a nice starting point.

As I said earlier, Web Edition repeating row lists are even easier.  You simply add the container row to the container list and it knows to add a scrollbar.  It also knows how to scroll when the user uses the mouse scroll wheel.

One caveat about this is WebDialogs.  There is a super nasty bug in the framework where WebDialogs don’t get events like they should.  If your web dialog, and subsequent container, happens to be over a WebListbox and you try to scroll, the underlying listbox will receive the scroll events.  If you find this happening to you, you can try disabling the listbox.  Still, this bug sucks.

There is huge overhead using the EmbedWithin method in web apps.  Every time you use it the app has to serve up a new page and send it down the pipe.  I saw an example project the other day that had 50 rows and each row had 10 container cells on it.  With very little data and no style information it took almost have a second to display the repeating list in the browser on the same machine.  Add some additional time going over a slower connection and your app looks slow and unresponsive.

The answer for now, is to not do that.  The performance of the embed within command is simply too big to use it a lot.  We had one largish web project where we used containers for each of our tabs and were adding them at runtime.  It was not good.  The lag time was simply too big so we ended up embedding the containers into the page at design time.  Now we take a little bit of a hit when the page is first displayed but the user doesn’t notice anything when they switch tabs.

If you are not using containers you really might want to look at them again.  They really are powerful tools.  With a little time and practice you can make your coding life easier while developing some incredibly complex layouts.

Network Link Conditioner

If you’ve been using Xojo Web Edition for any length of time you’ve probably run into this problem:  You code your app and debug it on your local machine and you’re very happy with it but when you put it on your web server it’s slow, unresponsive, or generates some random javascript errors.

Welcome to web app programming.  What’s happening is that on your local machine there is, for all practical purposes, zero latency between the browser and the application.  You can do amazing things wish no latency issues.  I once had a working D&D Mapping helper for Dungeon Masters that used drag and drop on a web page.  That is until I put it on the web server and then it practically ground to a halt.  The end result is that it was a very hard lesson to learn (thankfully it was a ‘for fun’ project).  Drag and Drop in a Web Edition application really doesn’t work due to this latency (not even sure why the events are even there).

Latency is an issue all web apps have to deal with and since Xojo apps do nearly all of their processing on the server this can be of particular concern.  Short of putting the apps on my web server there wasn’t a lot I could do to test this until I found out about The Network Link Conditioner for Mac OS X.

Screen Shot 2013-12-14 at 5.32.53 PMThe Network Link Conditioner is available through Xcode and allows you to simulate network conditions on your Mac as if you didn’t have the super speedy connection you really have.  It’s quite instructional to do this.  You can simulate speeds from Edge, DSL, 3G, Wifi, and Cable Modem with varying degrees of lossy conditions in the wireless options.

To get The Network Link Condition open up Xcode and select the Xcode -> Open Developer Tool -> More Developer Tools and log into your Apple Developer Account and in the Downloads area search for Hardware IO Tools for Xcode.  This package includes a number of things, including the Network Link Conditioner preferences pane.  Download the disk image and mount it.  Simply double click on the Network Link Conditioner prefPane file and the Finder will install it in your System Preferences panel.

Then it’s simply a matter of starting it and selecting the network type you want to test against.  This tool is very cool and I highly recommend it if you are developing for Xojo web applications.  What it will show you is how slow your app is over these types of network connections and will most likely show you where you need to do some optimizations.  Perhaps you need to preload some things on your first page so they’re slower later on.

In one of our current projects we were loading a number of WebContainers dynamically.  This made sense since we felt we didn’t want to load everything when the user logged in and only load the container when they selected it.  This was great but this made the initial selection of the user slow as the server had to create the objects and then push them down to the browser.  The perception was that the app was very slow.

Of course, during development on our local machine we never saw that issue.  Everything was fast and speedy.  But when we started using the Network Link Conditioner we could see it rather well.  We also were able to replicate a few sporadic javascript errors that only occurred on the server (doing things in the WebContainer open events is bad too).

The solution was to load the pre-load containers when the user first logs in.  It takes longer at first, but when the user makes a selection the app has to only issue visible commands to the browser which is very fast.

A word of warning is in order.  Remember to turn Network Link Conditioner off!  It’s easy to forget that it’s on.  If you forget, though, your entire machine will seem slow if you’re doing anything over the network or internet!

What other tools and tips have you found for helping you debug your web applications?

Xojo: Operation Lockdown

It’s always nice when a client gets to talk in the keynote address at Real World (now Xojo Developer Conference).  Brent Huston, CEO of Microsolved, was invited to speak during the Xojo keynote address last week.  Brent talked about the Operation Lockdown that his company, Real Software (Xojo, Inc.) and BKeeney Software are participating in.

Brent has been using Real Studio desktop applications for some of his security apps for a number of years with great success.  He’s now interested in Web Edition and wanted to see where the vulnerabilities were in the framework and what we could to do fix them.

We (BKeeney Software) came up with a simple Web Edition app that mimics what a typical web app would have in it (Login page, admin only pages, user pages, etc) and hardened it to the best of our ability.  Brent’s team then took the standalone web app and used their hundreds of hacking and infiltration tools to see if it would fail.  They also attempted manual penetration testing of the web app.

I’d love to say they found nothing but that’s not the case.  They found a few critical, a few minor, and a few false positive issues.  The good thing is that the critical issues have already been taken care of by Real Software and will be in Xojo Release 1.  Some of the minor issues and other requirements will be added later, according to Xojo, Inc.

The very good news is that the Web Edition framework is pretty stable.  The Session management, according to Brent, is very robust against all known forms of attack.  Using some very simple coding techniques Web Edition web apps proved to be immune to SQL injection attacks and other common vulnerabilities.

Brent recommended that when Xojo R1 is released all Web Edition developers re-release their web apps compiled with it since a number of items his team found are fixed in the upcoming version.

During a Friday session Brent shared, with a packed room, how bad guys (and certain nation states) view your web applications and data.  It was very, very scary stuff and I think everyone walked out of the room wondering not IF our personal/business data has been hacked but how long ago it was compromised.  Scary stuff.

Lot’s of things to think about but it was encouraging to hear that Web Edition was pretty secure.  Perhaps what’s even better is that I overheard a Xojo engineer saying something to the effect of, “That will be changed for R1 to prevent THAT issue from happening,” in reference to a “man in browser” vulnerability.  It’s nice to know they’re taking security seriously in Web Edition (though the irony of their website getting hacked did not go unnoticed by conference attendees).

FAQ: What Do I Do My Videos In?

One of the questions that I field, a lot, is what program to do I use to create my Real Studio Training (and other) videos?  The answer is ScreenFlow from Telestream.

When I first started thinking about training videos a little over 2 years ago I looked around and did my research.  ScreenFlow had most of what I wanted but the only thing it lacked (at the time) was an export to Flash.  I think within a matter of 3 or 4 months it was added in a new version.  I guess that’s one of the things I like about the software as they are always improving the product.

I think ScreenFlow is incredibly intuitive.  A simple interface starts and stop screen recording.  If you’ve ever used iMovie or Final Cut Pro to edit video the timeline editor is simple to figure out and intuit.  There are many options for zooming, and adding text and callouts, audio levels, cursor options, etc.  In other words, way too many features for me to spell out and frankly I use but a handful of them.

One of the bigger features that I use is the ability to Split a Clip and get rid of wasted time (like all the time I spend trying to figure out what I did wrong in my code, or redoing a sequence), or speeding up a long typing sequence.  Also, being able to mute the inevitable cough or the cell phone ringing is pretty important.

ScreenFlow has a number of exporting options but since it didn’t export to Flash (at the time) I ended up using iMedia Converter from iSkySoft.  It converts practically every audio and video format you can think of.  I used this to figure out the byzantine ways of getting Joomla to display both HTML5 video and Flash.  I could use ScreenFlows export now, but since I can do batch processing in iMedia Converter I can literally let it run overnight and do 40 or 50 videos if I need to.

One of the things I learned when doing the ARBP conferences was that good audio is critical.  Use a Plantronics gaming headset that plugs in via USB.  My only complain wasn’t with Plantronics, but with Apple.  If I recorded a video where I did recording for over 45 minutes, I would consistently have three minutes of static filled audio.  Then it would go away but it makes for bad audio at that point.  Sometimes it doesn’t affect anything and sometimes it does.  I haven’t done a really long video in a while so this problem might not be there now.

I talked earlier about Joomla and how I found it difficult to get video up and running.  Now our training is 100% Real Studio Web Edition.  Not that Web Edition is perfect, but I’ve been able to add more features to it in 4 months than I was able to do with Joomla with 2 years of trials and tribulations.  At least with Web Edition I have more control over the web app than I did with Joomla.

In fact we’ll be integrating closed captions to the training videos, first in English, and then hopefully in French and Spanish.  This is enough info for another post describing what a pain that’s been, but let’s just say that it’s coming “soon”-ish.  Currently I’m handling all of the PayPal transactions manually so there’s some delay between payment and me actually setting it up and we’re hoping in the next couple of weeks to get PayPal fully integrated so I don’t have to do any manual setup anymore.  Did I mention how much I like having more control over the app?

Anyway, this has turned into a longer post than I anticipated.  Thanks for your support!

Web Edition Learning Curve

I had a conversation with another RB developer this morning that stuck in my head after I said it.  We were talking about how Web Edition has come a long way since it first came out.  I did a commercial project using one of the first public releases and it was, how shall I say, really rough around the edges.

Anyway, my comment was that at times I felt as if coming from the Real Studio desktop side really hindered my learning of Web Edition.  There are just some things you do in Real Studio desktop apps, like using Window constructors, that are just not possible with Web Edition.  Sometimes closing a WebPage immediately after showing another one isn’t a great idea whereas on the desktop side you don’t even have to think about it.

It takes a while to wrap your mind around the difference between a desktop app and a web app.  The desktop is easy.  It executes locally and gets data locally (there are exceptions of course) but it’s all really quick and it’s designed to interact with the local operating system.  When you want to delve even further into the OS you could always use Declares.

That isn’t how Web Edition works.  When you first start using Web Edition you think it’s on the local machine (it is) so you get this false sense of security about how fast it is.  It’s not until you put it on your web server, which might be half way across the planet, that you realize that there are latency issues to deal with and that changes to the UI get pushed down to your browser.

It only looks like your app is running on your local machine.  In fact every event (that’s used) gets sent to the web server for your app to process.  So this means that if you implemented the MouseMove event every time your mouse moves a message gets sent to the server for processing.  It is very easy to get too many things in the pipeline for your app to respond correctly.  As a good friend of my once said, “You can only piss so much pixie dust down a straw” meaning that the data pipeline (the internet) is only so fast at moving data and it will pass it as fast as it can and no faster than that.  Quite philosophical, no?

The fact that your ‘windows’ are really running in the browser is also hard to wrap your mind around if you’re coming from the desktop side.  And frankly when you’re debugging your Web Edition app you really should be running it in multiple browsers just to make sure it acts the same in each one.  Not all browsers are created equal.  And, just to make life a little harder, test them in different operating systems.  It’s really not much different, at that point, with desktop development.

If you are planning on using Web Edition and you’ve been using Real Studio desktop plan on some extra time.  It’s not THAT much different, but where it IS different will throw you for a loop.  There is a learning curve but with a little patience you’ll overcome it.

Then there are differences in web servers.  Which Linux version?  Do you have 32 bit compatibility libraries installed?  What version of Windows IIS Server or Apache?  Debugging installation issues is, in my opinion, a huge problem since there there is no “step 1 – try this, step 2 – look at this” sort of solution and it seems that every server is just a bit different.

What parts of Web Edition have you struggled to figure out in comparison to desktop apps?

Google search and Web Edition

If you use Real Studio Web Edition right now the contents of your app are invisible to Google. I think a lot of people are using WE for internal projects or for apps that need a user to log in before anything useful is available. This isn’t a problem for that kind of project but for some web apps it would be nice to have certain areas show up in Google’s search results.

This isn’t just an issue with WE, other AJAX based web apps have the same type of issue and Google has a document that describes how to make AJAX web apps crawlable:

The basic idea is that you have special hash tags for the parts of the your app that should be indexed. When Google sees those it asks your app for snapshot of what the app would look like after the JavaScript has been evaluated.

One approach that Google suggests for getting snapshots is to use something like HtmlUnit. HtmlUnit is a program that acts like a web browser but doesn’t have a user interface. It executes JavaScript just like a browser would and then you can extract the contents of the page.

I did a little bit of experimentation and found that this approach works for simple cases. I ran into a some problems with a real application but they probably have solutions. It seems like the best solution, though, is for WE to support Google’s approach itself. I’ve created a feedback report requesting this as a feature.

If there are parts of your app that could serve as entry points and you want to be able to drive search engine traffic to them, please sign to this report: