Real Studio User Database Breakdown

Understanding how you use Real Studio and what your requirements are as developers drives our future development of Real Studio. To that end, we conduct periodic surveys both to gather data and to see how we are doing with the product focus.  A few months ago we did a survey and an overwhelming number of people asked us to share the data (specifically on the database breakdown).

We separate each survey by language as well as edition, which helps us better analyze the results. This information has been useful in helping us with the upcoming changes to our pricing structure. As with any significant change, we make every effort to clearly see the whole picture and know who will be directly affected and how by these proposed changes.

Through this latest customer survey we once again confirmed what we have found or suspected in the past. For example, Personal users are more likely to:

• Build apps for their own use
• Use Real Studio to learn to program
• Run their programs in the IDE rather than building

when compared to Professional or Enterprise users. We also found that the majority of you, regardless of edition, use Real Studio at work, for both your own use and use by others. We were pleased to learn that the majority of Enterprise users are now actively using Web Edition.

As for databases, we polled only the databases supported directly in Real Studio, any third party databases you connect to would be included in the ODBC category. These numbers include both Professional and Enterprise users.

RealSQL	55.98%
MySQL	46.98%
Postgres	20.19%
Oracle	6.66%
MS SQL Server	14.98%
ODBC	22.23%

Paul recently posted a similar survey in the Real Studio Developers group on LinkedIn with parallel results if you are interested in joining that discussion.

Designing for the 80%

On Monday, Greg Keizer of Computerworld blogged about a survey indicating 25% of computer users see no benefit to upgrading their software. The results of the survey are not surprising. New versions of software are not designed to please every user. In fact, they can't be. Designing new releases in an attempt to please every user will result in pleasing none of them completely. I know, I have been guilty of that in past updates to Real Studio. It took me years to learn that you can't please everybody. Steve Jobs said that Apple designs for 80% of the users. Apparently, Apple sees that as the sweet spot. That seems reasonable to me and 80% is pretty close to the 75% of users who apparently do find benefit in upgrading their software.

In the post, Jono Xia, a former Mozilla employee, claimed that upgrades are often productivity sinkholes. Jono was most critical of updates that alter the user interface. Though these criticisms might sometimes be justified, when they are, it's not because the software is being upgraded, but because the upgrade is not aimed at truly solving problems users have. Sometimes altering the user interface is exactly what is needed.

Having said that, most developers would be quite happy if 75% of their users upgraded. Trying to solve enough problems so that more than 75% of your users will upgrade sounds unrealistic to me.

Preserving stack trace when catching and re-raising runtime exceptions

This post offers an introduction to the usefulness of exception handling in general, while also explaining how to deal with a particular shortcoming when you use debugging code and the UnhandledException event handler in built programs you deliver to people. I hope this article will be helpful to both newcomers and veterans alike.

Background (UnhandledException and the Stack Trace)

You probably know the UnhandledException event handler in the App class.

It lets you catch any unhandled exceptions in your program, preventing your program from getting terminated unexpectedly, and allowing you to save any interim data that the user may have not saved yet, and other defensive fallback procedures.

One other use of this handler is to record the location where the exception occurred in order to use that for later debugging. For instance, if you send your built application to others who do not have the Real Studio debugger, your program could still record the so-called stack trace from the exception, show that to the user, and ask him to forward that information to you so you can hopefully deduce what went wrong and how to avoid it in the future.

You get this stack trace by invoking the Stack() method of the RuntimeException object you get passed in UnhandledException. It returns an array of strings, identifiying the methods that were called up to the one that caused the exception.

For instance, if your program causes an exception in a Window's Open event, the stack trace might look like this:

1. RaiseOutOfBoundsException
2. Window1.Window1.Event_Open%%o<Window1.Window1>
3. FireWindowOpenEvents
4. Window.Constructor%%o<Window>
5. Window1.Window1%o<Window1.Window1>%
6. _MakeDefaultView
7. _Startup
8. RunFrameworkInitialization
9. REALbasic._RunFrameworkInitialization%%p
10. _Main
11. % main

The topmost line shows where the exception occured, the bottommost is the topmost caller at that time.

It tells several things:

* The exception, obviously a OutOfBounds exception, occured in Window1's Open event (line #2)
* The Open event was invoked by the Window1's Constructor (lines 4 and 5).
* The Window1 got constructed right at start of the program (line 7). Otherwise, we'd usually see the method "RuntimeRun" up in the stack trace, indicating that the startup has finished and the program is now processing events.

Raising exceptions

Whenever an exception occurs, we say that it gets raised. Realbasic even offers a custom statement for that: The raise command. With that, you can make your own exceptions occur. An example:

  raise new OutOfBoundsException

is equivalent to:

  dim anArray(0) as Integer
  anArray(1) = 0 // this will cause an OutOfBoundsException

(Of course, you can create your very own exception types by subclassing them from RuntimeException. See the Language Reference to learn more about that.)

Now, here's an imporant part: The stack trace that gets attached to any RuntimeException object is created when this raise statement is invoked. And the stack trace is then created from the very calling stack that's in effect at the time of invocation. Logical, right?

Catching exceptions

You can catch exceptions in your methods using the try ... catch ... end and the exception statements.

There are two common cases why and how you'd catch exceptions:

1. Handling the exception

You expect a particular exception to occur and are prepared to handle it. This is, for instance, the case when you use file I/O operations and which you cannot otherwise predict to avoid them, such as that a file cannot be created, causing an IOException.

2. Cleanup

You do not know that any particular exceptions might occur in some subroutines you call but you like to be prepared and do some cleanup if that should happen. In this case, you'll pass on the exception to the caller because you don't know have reason way to handle the exception at that particular point.

Such cleanup handling code usually looks like this:

 try
   ... // your operations
 catch exc as RuntimeException
   db.Rollback // e.g. abort a database transaction
   raise exc // pass the exception on
 end

The complication (catching and re-raising)

Let's assume you have a UnhandledException event handler in the App class, which reads the Stack array and for later analysis (e.g. by writing to a file, creating an email to you or even uploading it to your web server).

So, if any part of your program raised an exception for which you don't have particular handling code, it'll end up in App.UnhandledException, which will eventually allow you to learn where the crash ocurred. That's the general idea, at least.

However:

Consider what happens if an exception occurs inside a subroutine that's called by code using the Cleanup exception handler?

Remember how the stack trace gets created: During the invocation of the raise statement.

This means that if an exception occurs deeper down, then gets caught by the Cleanup handler code, which then re-raises the exception to end up finally in the App.UnhandledException handler, you'll get to see the wrong Stack trace! You won't see the methods that were actually the cause of the exception but only the stack trace from the upmost raise call.

The solution

Finally, we're getting to the root of this article's purpose.

I'm suggesting that whenever you have a raise exc call in your code, you change that to:

  raise new CaughtException (exc)

And, of course, you'll need a new class CaughtException which I'll show you here:

First, create a new Class, name it "CaughtException" and set its Super class to "RuntimeException"

Then add the following two methods to it:

  Sub Constructor(exc as RuntimeException)
    if exc isA CaughtException then
      exc = CaughtException(exc).OrigExc
    end
    self.OrigExc = exc
  End Sub
  
  Function Stack() As String()
    return self.OrigExc.Stack
  End Function

Finally, add this private property:

  OrigExc As RuntimeException

That's all you need to care about.

The trick here is that this class overwrites the Stack() method of RuntimeException, providing the original stack trace instead of the (useless) one created by the raise command. Therefore, your App.UnhandledException handler won't have to be changed at all to make this work.

Even if you do not fully comprehend what this is doing, simply follow my advice of always using this construct wherever you catch an exception and raise it right after again. It'll magically make your debugging efforts easier in the future.

Benefits of using OS X, Windows and Linux

Ryan Matthew Pierson recently blogged about the benefits of using both Windows and OS X. While I agree with many of his conclusions, there is another, very real benefit for cross-platform application developers to use multiple platforms and that's creating a better user experience.

Your users want a great user experience. While it's possible to create a user experience that is better than the one provided via native controls, that's not usually the case. Just using native controls is not enough; you have to think about the expected user experience based on the OS which users are running. Simple things like the spacing and placement of controls can make the difference between your app feeling intuitive and easy versus confusing and difficult.

Real Studio provides several features that make life easier in this regard, not just for OS X and Windows but for Linux as well. For example, you can create constants with platform-specific values for use in your user experience. Your File -> Quit menu item can easily be made to use "Exit" on Windows. Using constants, you can swap the locations of your OK and Cancel buttons in dialogs since Windows/Linux place them in the opposite order of OS X. And since some controls are taller on Linux, you can use constants to control the height of controls as well. This makes it easy to provide the native and thus most intuitive user experience for your end user. Yes, this takes more time but it will also help your application be more successful.

The biggest benefit of using all the major operating systems for cross-platform developers is to know the user experience your end users will be expecting so that you can provide it and be more successful.

Databases that work with Real Studio

Real Studio is commonly used to create so-called "database applications."  To make this easy, Real Studio includes a standard database API (Database class and subclasses, RecordSet, DatabaseRecord, etc.)  With this standard API, you can connect to many different databases using very similar code.

In general, databases can be divided into two categories: single-user databases and database servers.

Databases included with Real Studio

SQLite

http://www.sqlite.org
SQLite (aka RealSQLDatabase) is the single-user database engine included with Real Studio.  SQLite is a public domain database and is used by all kinds of software from browsers such as Firefox to programming tools such as Real Studio and frameworks such as CoreData.

PostgreSQL

http://www.postgresql.org
PostgreSQL is a full-blown database server.  It is open-source and free, available for use for just about any purpose.  It can be a bit tricky to install, but is powerful and fast.

PostgreSQL is cross-platform and works on Linux, OS X and Windows.

With Real Studio you use the PostgreSQLDatabase class to connect to a PostgreSQL database server.

MySQL

http://www.mysql.com
Now owned by Oracle, MySQL is also an open-source database server, but has less comprehensible licensing.  Real Studio is able to connect to the Community (free) edition of MySQL, but this edition usually requires you to open source software that connects to it (due to its GPL license).  MySQL is very easy to install and is often available by default on many web servers.  If you choose to use it, be sure you understand its licensing.

MySQL is cross-platform and works on Linux, OS X and Windows.

Use the MySQLCommunityServer class to connect to MySQL.

Oracle Database

http://www.oracle.com
Oracle Database is one of the most powerful database servers around.  It is often used for enterprise software and by larger companies.  Oracle Database has a reputation for being a beast to manage and configure, but is also known to be fast.  It can also be rather expensive.  It runs on Windows and Linux and used to be available for OS X, but it does not look like that is an option any longer.

There is also a free Oracle Database Express Edition.

The OracleDatabase class is used to connect to Oracle database.

Microsoft SQL Server

http://www.microsoft.com/sqlserver
http://www.microsoft.com/express/sql/
Microsoft SQL Server is a database server that runs only on Microsoft Windows.  It is generally easy to use. Both paid and free versions are available.

The MSSQLServerDatabase class is used to connect to Microsoft SQL Server.  It can only be used with Windows applications.

ODBC

http://en.wikipedia.org/wiki/ODBC
ODBC is not a database, but rather a standard for connecting to databases.  It stands for Open DataBase Connectivity.  Originally created by Microsoft in the 1990s, it is now an industry standard.  Using Real Studio's ODBC plugin, you can connect to any database for which you have a driver.  Driver availability varies by platform, but I have successfully used ODBC to connect to Microsoft Access, FoxPro and even IBM DB/2 mainframes.

Use the ODBCDatabase class to connect to any database for which you have an ODBC driver.

Other Databases that work with Real Studio

These databases are provided by 3rd party developers and all easily work with Real Studio.

cubeSQL

http://www.sqlabs.com/cubesql.php
CubeSQL is a database server that uses SQLite as the database back-end.  It is fast and extremely easy to configure.  CubeSQL is cross-platform, running on Linux, OS X and Windows.

To use cubeSQL with Real Studio, you install its plugin and use the CubeSQLServer class to connect.

OpenBase SQL

http://www.openbase.com
OpenBase SQL is a database server that was originally created for OpenStep.  It works on OS X, Windows and Linux.

OpenBase SQL comes with a custom library (written in Real Studio itself) to connect to the database.

FrontBase

http://www.frontbase.com
FrontBase is a database server.  It is freely available for Linux, OS X and Windows.  A native plugin for Real Studio is available from FrontBase, but it is Carbon-only.

Valentina

http://www.valentina-db.com
Valentina is both a single-user database and a database server.  It is cross-platform for Linux, OS X and Windows and uses a native plugin for Real Studio.  Valentina is a "columnar" database and has a reputation for speed.

Studio Stable Database

http://www.studiostable.com/database
Studio Stable Database is a database server that is built on top of SQLite.  It is intended to be a simple way to bring multi-user support to your SQLite applications.  SSD uses a library (written in Real Studio) to connect to the database and is available for free.

MBS SQL and JDBC Plugins

http://www.monkeybreadsoftware.de/realbasic/plugin-sql.shtml
If you need to connect to a database that is not listed here, be sure to check out the SQL Plugin from MonkeyBread which has support for Oracle, Microsoft SQL Server, Sybase, DB2, Informix, Interbase/Firebird, Centura SQLBase, MySQL, PostgreSQL, ODBC and SQLite.

In addition, the JDBC plugin (Java DataBase Connectivity) is particularly useful, allowing you to connect to any database for which there is a JDBC driver.

Database Usage

Other than SQLite, databases that use the Real Studio database API require Real Studio Professional, Web or Enterprise.  When Real Studio 2012 Release 2 is available, databases that use the database API will need a Database Access license in order to use them in your built apps.

The following databases work with Real Studio Personal and will not require a database license for Real Studio 2012 Release 2 (mostly because they do not use the standard Real Studio database API):

• SQLite (standard API)
• OpenBase (proprietary class library)
• Valentina (plugin with proprietary API, standard API is also available but not required)
• Studio Stable Database (proprietary class library)
• MBS (proprietary API)

All other databases connect to the database using our standard database API and require Real Studio Professional, Web or Enterprise for now and a Database license starting with Real Studio 2012 Release 2.

Multi-Browser Web App Testing

One question that came up a lot at Real World this year was "How many browsers should I test my web apps on?" The answer is "All of them!" You should test your applications in as many browsers as you can get your hands on.

Which Browsers

As I mentioned in my sessions at Real World this year, we support the following desktop browsers:

• Apple Safari 5.x+
• Google Chrome
• Mozilla Firefox 5.x+
• Internet Explorer 6 with Google ChromeFrame plugin
• Internet Explorer 7+

Additionally, we support:

• Mobile Safari (on iOS Devices)
• Android Browser 3.x+

When it comes to the browsers, you should test as many platforms as you can because they will sometimes render slightly differently. For instance, Safari attempts to maintain the platform look and feel, so buttons may render at slightly different sizes!

Tools of the Trade - Equipment

When it comes to testing, there's nothing like having a real machine around for testing. When it comes to testing web sites & apps, that's often not financially feasible because you'd need to have at least 4 or 5 computers on your desk to cover all of the possibilities. The next best thing is to create a virtual machine using one of the virtualization products such as:

• Parallels
• VMWare 
• VirtualBox 
• VirtualPC

Tools of the Trade - Browsers

Safari & Chrome

When it comes to Safari and Chrome, you can pretty much use the latest versions on OS X and Windows to test. As Apple moves forward with 10.8 and beyond, you may want to keep a virtual machine around that still has 10.7 and an older version of Safari on it for testing. Google Chrome automatically updates to the latest version, so users will most likely have a very recent version.

If you're interested in the bleeding-edge of what's going on with Webkit, check out http://www.webkit.org.

Firefox

Firefox is a tricky target because it wasn't until recently that they started forcing upgrades on their customers. Sometime this spring, they announced that they would be auto-upgrading anyone using version 4 or earlier to the latest supported version for their machines. This means that there are still people out there that are running versions 5 - 12 (version 13 is current as of today). One way to solve this is to keep several versions on your machine. On OS X, all you need to do is name each of the browsers with the version number. On Windows, you need to be sure to change the installation directory each time you install a different version.

Internet Explorer

Now lets talk about Internet Explorer. Like most internet geeks, I like to have the latest & greatest version of a browser on my machines because they tend to work the best and are more compatible with the latest sites. Unfortunately the same does not hold true for many customers and businesses that use the Internet on a daily basis. The fact is that you cannot guarantee that any particular user will be using an up to date browser. For instance, Windows XP came with Internet Explorer 6 when it first shipped!If you don't have a computer with IE7 and IE8 on it, you shouldat least be testing with DebugBar's IETester for Windows. It'll give you a very close approximation of how those browsers will behave. I still prefer using a virtualization product for older configurations. If you have Windows 7, VirtualPC/XPMode is a free download.


iOS

Testing for Apple's iOS devices requires that you either have a device or a Mac with the iOS Simulator included with the Xcode Developer Tools. Personally I like testing on a real device, but for the most part the version of Safari that is included in the simulator functionally equivalent.

Android

As with the iOS devices you should either use a physical device or the Android SDK. Again, I prefer actual devices, but with the proliferation of different Android devices out there, it's often not an option to have one of each. The Android SDK allows you to create virtual devices that match particular hardware configurations.