Thursday, March 29, 2012

The Intended Use of AddHandler


Real Studio recently introduced the AddHandler feature that lets you wire events up to objects at runtime. The goal is to allow a cleaner separation of responsibilities and hide more implementation details from the outside world. "AddHandler" provides users a means to set up, purely in code, a class that has some events (say a timer) and respond to the events that class defines. It's intended to be in places where you want to hide the implementation since you can't put classes inside other classes. For instance if you want to provide this class to other Real Studio users and don't want to require adding several classes to use your code.

A class that needs a timer to provide a timeout mechanism may do so entirely in code instead of having to declare a special subclass that handles the Timers events.

Situations like this make sense to use AddHandler.

But it's NOT intended to be a substitute for a well designed API, interfaces, or subclasses.

For example a socket class that needs to time out after a certain number of seconds. In prior versions of Real Studio, you would have had to create a new Timer subclass in your project that only exists to handle the Timer's Action event and relay it back to the socket.

With the addition of AddHandler, your socket can simply have a Timer property and hook the event up via AddHandler as follows :

Class FancySocket
Inherits TCPSocket
Private Sub Connected() Handles Event
StartTimeout( 1000 )
End Sub
Private Sub Error() Handles Event
CancelTimeout()
End Sub
Private Sub StartTimeout( period as integer )
mTimer = new Timer()
mTimer.period = period
AddHandler mTimer, AddressOf DoTimeout
End Sub
Private Sub CancelTimeout()
RemoveHandler mTimer, AddressOf DoTimeout
mTimer = nil
End Sub
Private Sub DoTimeout( sender as Timer )
Disconnect()
End Sub
Private mTimer as Timer
End Class

AddHandler, in general, leads to very tightly coupled behavior by design and this isn't what you want in most cases. In fact, usually you want to make your program as decoupled as reasonably possible.

You also need to be careful to manage the reference counting correctly with AddHandler. It's easy to create reference cycles because the behavior is slightly more subtle: using AddressOf on an instance method creates a new Delegate that keeps a strong reference to the base object. If needed, you can use WeakAddressOf to create a Delegate that holds a weak reference to the base object.

In the example above, we have a cycle created in StartTimeout because our socket holds the Timer and the Timer holds the delegate we created via AddressOf. It's not a problem in this case because we always will get the Error event once we've successfully connected.
However if we neglected to remove the handler then its possible we could just leak this object if there were no other references to it in our application.

AddHandler can be very useful but it comes with a cost to you the developer as you have to be more careful about NOT create reference cycles.

Sometimes the right thing to do is the 'old' style with special subclasses or interfaces.

Tuesday, March 27, 2012

Running a Standalone Web Application as a Windows Service

In my last post, I wrote about how you can run your Real Studio web applications as a daemon.  Windows doesn't have daemons, but it does have an equivalent feature called Services.  Like a daemon, a service is a background process.


As luck would have it, web applications are actually services under the hood so they work just fine as Windows services.  The trick is how to install it as a service on Windows.


The magic command is called "sc" for service control.


Here's a quick example:
  1. Create a simple web project and build it as a standalone web application (I use port 8100).  Note the path of the resulting executable.
  2. Start the Windows command line with administrator privileges.
  3. Enter the sc command to install the service.  Do not leave out the spaces after each = in this command:
    sc create RSWebSvc type= own start= auto binpath= c:\Path\To\Exe\WebApp.exe
  4. You should see: [SC] CreateService SUCCESS
  5. Now open up Control Panel and go to the Services Manager.  It is located in Administrative Tools and is called Services.
  6. Find the service you just created, RSWebSvc.  Click on it and select Start.
  7. Your web application is now running as a service.  To test it, navigate to the URL in your browser:
    localhost:8100
  8. To stop the service, click on it in Service Manager and click Stop.

Thursday, March 22, 2012

Apps for Income


Earlier this month we announced our Apps for Income campaign which is providing 20,000 free Real Studio Personal licenses to unemployed workers worldwide. According to a recent report released by technology trade group TechNet, app development in the United States has created 466,000 jobs since 2007. Programs like Code for America are already empowering citizens through software development; check out Code from America founder Jennifer Pahlka's keynote at SXSW this year.

As so many of you already know, Real Studio allows people with little or no software development expertise to easily create a wide range of applications that have proven to be primary or supplemental income sources. “With the global economy remaining sluggish, we feel that offering Real Studio for free is a great way to give people struggling to find work the chance to create their own opportunities,” said Geoff Perlman.

We've been very encouraged by the enthusiastic response to Apps for Income so far, receiving requests from people throughout the United States and around the world. If you are reading this and know someone who could benefit from our program please pass it on. As Jennifer Pahlka put it, "It's not so much just about technology. It's about people."

Wednesday, March 21, 2012

Daemonize Your Standalone Web Applications

Perhaps you could always do this, but I only just recently learned that you can Daemonize your standalone web applications.  A daemon is essentially a background process. Using a daemon makes it much easier to deploy your web applications to remote web servers.


In the case of a Linux server, you would upload your Linux web application using FTP.  Then you connect to your server using SSH and start your app from the command line.


Here's a quick example:
  1. Create a new Real Studio Web Application project.
  2. Add a label to the default page that says "Daemon Test".
  3. In the App.Open event, add this line of code:
    Call Daemonize
  4. Change the Linux App name to DaemonWebTest.
  5. Change the build settings so that the build type is Standalone.  You should also change the port to something that is not used like 8100.
  6. Save the project.
  7. Build your web application for Linux.
  8. Using your favorite FTP software (I use ForkLift), upload the app to your Linux server.  I put it in a folder called "daemontest".
  9. Connect to your server using SSH from the terminal:
    ssh name@myserver.com
  10. Navigate to the location that contains your web application (this varies depending on the Linux distribution you use):
    cd /var/www/vhosts/myserver.com/httpdocs/daemontest
  11. Run your app:
    ./DaemonWebTest
  12. You will immediately be returned to the command line because the app is running as a daemon.
    You can verify that the daemon is running using the ps command:

    ps -C DaemonWebTest
  13. Disconnect from SSH:
    exit
  14. Test the web application by navigating to it in your browser:
    http://myserver.com:8100
You can also use the Daemonize method on on OS X, but Apple would rather you use launchd to start daemon processes.

This technique does not work on Windows, where you have to start your standalone web application as a service, the subject for another blog post.

Friday, March 16, 2012

Is developing ON a smartphone practical or just a novelty?

Google just released AIDE, their Android Java IDE. It's probably a good idea that they provide a development tool rather than rely on tools they don't control. Most platform vendors provide tools. What's different about AIDE is that it's designed to run on Android itself.


This means you can develop Android apps on an Android tablet or smartphone. This sounds really intriguing at first until you start imagining what this might really be like. A tablet might make some sense, but as someone who developed software on a Mac with a 9 inch screen, it's not ideal. Yes, today's tablets have a higher resolution than my circa 1985 Mac, so there are more pixels in a 9 inch tablet screen. Still, developers generally want as much screen real estate as they can get. The minimum screen size for developers here at Real Software is 27 inches and some have multiple monitors. I would expect the many Real Studio users would be similarly configured. A 9 inch tablet screen doesn't seem like a very productive environment for developing an application. The only thing worse that I can think of would be attempting to develop software on a 4 inch smartphone screen. Oh, wait. That's exactly what Google is suggesting. The screenshots and demo videos seem to focus more on using a smartphone than on the tablet.


I can see the novelty of this but it doesn't seem at all practical. Just because you can create an IDE that runs on a 4 inch screen doesn't mean you should. Also compiling, even to Java byte code, is processor-intensive which I'd expect is going to drain the battery faster than a lot of other activities. Developing also involves a lot of typing. The touch-based keyboards on smartphones and tablets work fine for the kind of work that is typically done on those devices. But development usually involves typing a lot of code and a full-sized, tactile keyboard is really required for reasonable productivity.


The user reviews on the site are all quite positive which surprises me. Perhaps they are just caught up in the novelty of it and haven't considered the productivity issue.


Seems like AIDE should be designed primarily to run on a PC but perhaps include a version that runs on Android so that developers can get to their projects from anywhere. This would likely require Google to have a sync system like Apple's iCloud and Google certainly has the infrastructure to easily provide it. Heck, the projects could just be another type of Google Document.


Is it just me? What are your thoughts?

Wednesday, March 14, 2012

The Best of SXSW Startups

SXSW Interactive has been dubbed the “innovations fair” of tech startups. Looking back on the trend of companies that had their big break in the heart of Texas during SXSW, it doesn’t look like it’s slowing down anytime soon. With influencers growing by the thousands and flocking to our hometown of Austin, it’s only safe it wonder who we are going to see emerge as the new-found talent this year. Mashable recently wrote a piece on three apps that they believe will find their fame this year. Any apps out there that have caught your attention?

Wednesday, March 7, 2012

Minimum OS X version for Cocoa Support

When considering what will be the oldest version of any operating system we can effectively support, there are two considerations: the number of users of that version and the cost for us to support it. When the number of users is small but the cost is large, obviously it probably doesn't make sense to support it. This is the case we have run into with OS X 10.5.


Looking at the numbers, OS X users essentially fall into two camps: those using 10.5 (Leopard) and below and those using 10.6 (Snow Leopard) and above. According to the data we have gathered, over 80% of OS X users are using 10.6 or 10.7. While that does mean that almost 20% of OS X users are still using Leopard or earlier, that number is dropping.


Next, let's look at cost. Because of improvements in 10.6, supporting 10.5 and earlier often doubles the amount of effort for us because we have to code things one way for 10.5 (and earlier) and another way for 10.6 (and later). This means we fix fewer bugs and spend more time and energy on new features than would otherwise be unnecessary. Supporting 10.5 would make it impossible for us to use some of the new features of OS X 10.7 (Lion) as well. So the cost of 10.5 support is pretty high.


Because of these two factors, we have decided that the minimum OS X version we will support for Cocoa starting with Real Studio 2012 release 1 will be OS X 10.6 (Snow Leopard). Because Real Studio 2012 Release 1 will also be a Cocoa application, the minimum version to run the IDE will also be 10.6.


If you need to support users with 10.5 and earlier, you can continue to compile a Carbon version for those users. Projects saved in 2012 R1 will open in 2011 R3 which means you could even compile for Carbon on PowerPC if necessary. However, in this case, do NOT save your project in 2011 R3 once you have saved it in 2012 R1 as you may lose data. Just use 2011 R3 for compiling to PowerPC.


We don't make decisions like this easily or lightly. But they must be made in order for Real Studio to continue to move forward.

Monday, March 5, 2012

Creating Installers for your Desktop Applications

From time to time, I see people on the forums and mailing list ask about ways to create installers for their Real Studio desktop applications.  I'm going to cover some of the tools I have used which have worked well.

Mac OS X
The simplest thing to do on Mac OS X is to distribute your application as a zip file.  Your user can then unzip it and drag it to the Applications folder.

This might seem too simplistic for you, so another option is to distribute your app using a DMG (Disk Image) file.  The user double-clicks this file to mount it in the Finder and then drags your application to the Applications folder.  If you use a tool, such as DMG Canvas, you can also add a background (and Applications alias) to the DMG to make it easier for your users.

The final option is to use an installer.  Even if installers are somewhat uncommon on Mac OS X, they can still be useful.  You may find your users are more comfortable running an installer even it it doesn't do anything more than copy your app to the Applications folder.  And an installer can make it easier to copy files to other locations and prompt for authorization.

Apple includes a tool called PackageMaker for free with their Xcode developer tools, but I've found it difficult to use and a bit crashy.  So I use Iceberg instead.  Iceberg is a free tool to create installer packages.  I've used it on most of my projects for several years now and it works great.

Keep in mind that you'll still need to deliver your installer as either a zip or on a DMG.

Windows
Windows users expect an installer, so you can't really get away with just using a ZIP file.  Depending on the project, I've used two installers on Windows: InnoSetup and Advanced Installer.

InnoSetup creates setup.exe installers and is pretty easy to use once you get it set up.  Unfortunately, you do have to create your script by hand.  There is an example script in the documentation wiki to get you started.

Advanced Installer has a full-blown UI and is quite easy to use.  The free version will likely suffice for most of you, but they also have a more powerful paid version ($300).  In addition to the nice UI, Advanced Installer can create MSI (Microsoft Installer) files, which are preferred by IT departments.  From what I understand, an MSI makes it easier to do remote and bulk deployments.

There are plenty of other installers for Windows, including the popular and expensive InstallShield tools.  But I think that Real Studio packages up your application so nicely that you are not likely to need all the capabilities that the more sophisticated tools provide.

Linux
Often I don't bother with an installer for Linux, figuring that if the user is sophisticated enough to be using Linux, they probably don't need an installer.  But I had a client that really wanted an installer for their customers.  After some research, I found a nice little tool called InstallJammer.  It is free (open-source), but unfortunately looks like it is no longer being updated.  It's still worth looking at, though.


Thursday, March 1, 2012

Documentation Changes


You may not be aware but the Real Software Documentation Wiki has had quite a few updates recently.

First, the main page has been redesigned to better organize the sections of the Documentation.  The Language Reference is at the top, Desktop and Web Applications share the center and General Information is at the bottom.

The Web Applications section has three new articles about hosting your web applications:
In order to improve searching, more redirects have been added to the wiki for common search terms. For example, try searching for "control arrays" or "attribute editor".

The Language Reference has also been updated quite a bit.  View the Recent Changes page to see all the changes.  These Language Reference changes will be available in the local Language Reference when Real Studio 2012r1 ships.

I hope these changes make our Documentation Wiki easier to use and more useful.