With the new Oxygene 5.2 release, we have made some significant improvements to the user experience for our software licensing system.

Licensing is always a necessary evil. You gotta do something to enforce licenses, but you don’t want to go to the extreme and inconvenience the honest users (which are the only ones who see the licensing system, as crackers usually just completely remove it) any more than necessary.

Our licensing system always has been very easy-going and laissez-faire: Your licenses are stored in your account, and our software offers to automatically download the latest licenses for you — but you can also grab a license file from our website manually, if you run the software on machines that are offline. We have no “activation”, and no limit on installs — we trust our customers to do the right thing.

Everwood Live

With the new version of the licensing system, which we internally call “Everwood Live”, we’re going the extra step to make licensing even more simple and more unobtrusive for you. This new system is on Oxygene 5.2, and it will also make it’s way into the all-new RemObjects SDK and Data Abstract 7 and into Hydra 4 later this month.

The first time you use one of the products in your IDE (Visual Studio or Delphi) or via of our tools such as the new Schema Modeler 7, you will be greeted with the following dialog:

Ideally, this will be the first and only time you ever come in contact wit EWLive, on this machine. If you enter your username and password, EWLive will reach out to our server, and automatically download your licenses (for all your products) for you, and right away you are set to use all the RemObjects Software products you own.

As you install newer versions of the product, the way that our licensing system works is that an updated license file will be required (this is to prevent one leaked user license to entitle pirates to free updates for a full year). In the past, the frist time you used a new version you would be prompted for your account details, to download a new license. Not any more — Instead what you will see (if you are quick enough and pay attention) is this dialog:

and after a second or two, your license has been updated and you are ready to go. Chances are, you didn’t even notice this was happening.

Only if there’s a problem downloading your licenses (say you are offline, or — shame on you — your subscription has expired), all you be bothered with a dialog that needs your actual attention:

And Beyond

The UI in Oxygene 5.2 (and the other releases coming this month) is just the beginning of our plans for Everwood Live, and we are are going to to extend this further, including providing much better notifications of new releases (with direct download links), a new UI to manage and check your license and subscription status, and features that go beyond licensing to integrate your remobjects.com account with your product experience (think support, and/or bug reporting).

Behind the Scenes

The new Everwood Live is completely implemented in Oxygene (of course) and WPF 3.5 (because we need to support BDS and Visual Studio 2008). I need to admit that this has been the first project i have done using WPF in a log while (I implemented most of the EWLive UX myself) and i must say i was blown away by how nice and flexible WPF is for building classic Windows UI — the usual prejudice is that WPF is pinkly for fancy 3d graphics stuff — and my experience has really reassured me in recommending WPF as the way to develop Windows GUI applications, today.

EWLive itself is pretty simple; it talks to a few plain HTTPS APIs on our server, to authenticate a user (this happens only once, on the first login screen), to (re)download the license file for a user, or to get the list if current releases.

EWLive stores your user credentials in a secure manner, persisting only your username and an machine-bound “HMAC” that our server can use to authenticate requests for license files. The HMAC does not contain your password, but will be invalidated if you change your password on our website, and is thus fully secure.

I’m happy to let you know that we have just posted the first set of events that RemObjects will be participating in this year on our event calendar at remobjects.com/events.

2011 was our busiest year so far, with eleven conferences and events we participated in. One highlight has of course been our own DSConf in Las Vegas in February. 2011 also has been the busiest travel year yet for myself as well, with 10 cities in 8 countries visited.

While I myself plan to take things easier this year and will (most likely) leave the city and country only for WWDC, 2012 is already shaping up to be an exciting year where RemObjects events are concerned.

We have 360MacDev and 360iDev coming up again, both in Denver. This will be our third year at 360iDev.

There’s also a lot of Android-related events coming up, matching our increased investment in the Java and Android platform with both the recently-released Oxygene for Java and our upcoming Data Abstract and RemObjects SDK for Java. Jim will be doing an in-depth training course at Android Bootcamp next week and will also be presenting at AnDevCon III in San Francisco in May.

There’s also the Boise Code Camp in Jim’s home town, and of course the Delphi Developer Days, which we’re sponsoring once again this year, as well.

Find information about all our upcoming events at remobjects.com/events — and stay tuned; we’re only 2 weeks into the year, there will be a lot more events coming up.

Threads are ways to run multiple things in parallel, at the same time. Each program in Oxygene has 1 or more threads, by default just one, which is the main thread, which is the one in which the gui code runs. Using multi-threading allows you to run something in the background, while keeping your main thread responding to actions from the user (in a gui application). It’s also useful when dealing with blocking operations, like sockets and data access. There’s no practical limit to the number of threads that run at once, it depends on the system resources (memory, cpu) how many will work at once.

Threading

Thread Class

The thread class represents the basis for all the other ways of working with threads. The thread API is simple to use. The constructor takes a delegate to run as the method for a thread, the “Start” method makes the thread start for the first time. “Join” waits for the thread to finish.

var lThread := new Thread(method begin
  var lClient := HttpClient;
  try
    var lResponse := lClient.Get('http://blogs.remobjects.com/feed/rss').Content.ReadAsString;
    Invoke(method begin // synchronize to the main thread
      LoadResponseData(lResponse);
    end); 
  except
    on e: Exception do  
      Invoke(method begin
        MessageBox.Show('Failed: '+e);
      end);
  end);
lThread.Start;

ThreadPool Class

The ThreadPool class offers static methods to run something when a CPU is available. It will create up to a certain number of threads (configurable, defaults to the number of CPU cores) and execute any task it gets given to it in order. Using the Thread Pool is simple. The QueueUserWorkItem method takes a delegate with an optional “state” arguments that gets passed to this delegate.

method MainForm.UpdateRssFeed;
begin
  ThreadPool.QueueUserWorkItem(method begin
    var lClient := HttpClient;
    try
      var lResponse := lClient.Get('http://blogs.remobjects.com/feed/rss').Content.ReadAsString;
      Invoke(method begin // synchronize to the main thread
        LoadResponseData(lResponse);
      end); 
    except
      on e: Exception do  
        Invoke(method begin
          MessageBox.Show('Failed: '+e);
        end);
    end;
  end);
end;

Task Class

The Task class was introduced with .NET 4.0 and introduces a new way to deal with threading. A task is an asynchronous operation. There are two classes, the Task class has no return value, while the Task<T> class does. Using the Task class is simple:

var lTask := new Task<String>(method begin
      exit lClient.Get('http://blogs.remobjects.com/feed/rss').Content.ReadAsString;
  end);
lTask.Start; // add to the default task thread pool and run on another thread.
 
lTask.ContinueWith(method (arg: Task<String>) begin
    try
      var lResponse := arg.Result;
      Invoke(method begin // synchronize to the main thread
        LoadResponseData(lResponse);
      end); 
    except
      on e: Exception do  
        Invoke(method begin
          MessageBox.Show('Failed: '+e);
        end);
    end;
  end);

Tasks can, in addition to this, also be waited upon with the “Wait” call, and the result can be read with the “Result” property.

Timers

There are 3 timer classes in .NET. One is in System.Windows.Forms.Timer, which does not run in a thread but runs at an interval in the main thread. The other two are about the same in features, except that the System.Timers.Timer has a synchronization object to talk back to the main form, while the System.Threading.Timer is a bit more lightweight. These classes offer a way to run code at an interval, for example every 5 seconds, or every 100 msec. In addition to thread, the version in the System.Threaded namespace allows specifying an initial interval.

var lTimer := new Timer(method begin
    Console.WriteLine('Timeout!');
  end, nil, 5000, 250);

This timer will keep running until the application closes, or the Dispose method is called. It first triggers after 5 seconds (5000 msec), then after that every 0.25 second.

Futures

The Oxygene language offers Futures which can optionally return and run either asynchronous, like a task, or delayed on the caller thread. Futures have the advantage that they’re a language element that are easily portable. Internally asynchronous futures use Task if it’s available, or the Theadpool class if it’s not. Futures are assignment compatible with Task/Task<T> on .NET 4, and Func/Action on 3.5.

var lAsync := new async lClient.Get('http://blogs.remobjects.com/feed/rss').Content.ReadAsString;
 
...
 
MessageBox.Show(lAsync);

When to use what

While opinions may vary on the subject, I tend to use the System.Threading.Timer for anything that runs multiple times at a constant interval. The futures map to Task or the thread pool depending on the .NET version, which I would use over those two. If for some reason I would not want to use a future, then I’d use the Task class when I’m developing against .NET 4 or above and have a short running thing to do, the Threadpool for short running things on versions that lack the Task class, and Thread for anything else.

Synchronization

Main Thread

When running in a thread, sometimes you have to tell the GUI that data is available. Updating the GUI from the thread is not safe, and usually leads to hard to find errors. The way to deal with this is using Windows Forms “Control.(Begin)Invoke”, or WPF/Silverlights’ “Dispatcher.(Begin)Invoke”. These apis take a delegate and will execute this delegate on the main thread. The Invoke methods will wait for the main thread to be done with the given task, the BeginInvoke methods will not and let the thread continue right away.

Object Access

Accessing a complex object is not generally a safe operation. Most objects in .NET are not thread safe, and will fail with strange errors when accessed from multiple threads at once. Do deal with this, you can use locking or interlocked access to simple fields.

Locking can be done with the “locking” statement. Locking is done on any object instance, generally this is an object not used for anything else.

type
  MySafeStringList = class
  private
    fLock: Object := new Object;
    fList: List<string> := new List<String>;
  public
    method Delete(s: string);
    method Add(s: string); 
    method GetCopy: List<string>;
  end;
 
method MySafeStringList.Delete(s: string);
begin
  locking fLock do fList.Remove(s);
end;
 
method MySafeStringList.Add(s: string); 
begin
  locking fLock do begin
    if not fList.Contains(s) then fList.Add(s);
  end;
end;
 
method MySafeStringList.GetCopy: List<string>;
begin
  locking fLock do begin
    exit new List<String>(fList);
  end;
end;

The locking statement will make sure only 1 thread at any given time have a lock on the object during the time the statement after it runs.

The other way to deal with values safely is with the Interlocked class. This class is limited to a few types and a few operations and makes it possible to exchange, compare, increment and decrement values safely.

Waiting for threads or resources

Sometimes it’s required to wait until some data is available, or to have the thread idle for a specific amount of time, but still make it possible to terminate it safely. An “EventHandle” is useful for this. There are two different event handles, one resets automatically, the other does not. These classes are called AutoResetEvent and ManualResetEvent. An event can have two states: Set and Unset. When it’s unset, the Wait operation will either timeout after a while, if a timeout is given, or wait for it to be set. The Set operation can be called from any thread and lets any possible waiting thread return with reset. At this point it will reset to Unset if it’s an AutoResetEvent, or stay set if it’s a ManualResetEvent. A useful use of this is to terminate a thread:

CheckForUpdatesThread = class
private
  fEvent: ManualResetEvent := new ManualResetEvent(false);
  fThread: Thread;
 
  method Work;
public
  constructor;
  method Stop;
  method CheckForUpdates;
end;
 
method CheckForUpdatesThread.CheckForUpdates;
begin
  ...
end;
 
 
method CheckForUpdatesThread.Work;
begin
  loop begin
    if fEvent.WaitOne(10000) then  // Wait for 10 seconds, returns true if it was set.
      exit;
    CheckForUpdates;
  end;
end;
 
method CheckForUpdatesThread.Stop;
begin
  fEvent.Set;
  fThread.Join; // wait for it to finish
end;
 
constructor CheckForUpdatesThread;
begin
  fThread := new Thread(@Work);
  fThread.Start;
end;

Concurrent Structures

.NET 4.0 introduces several new collections that are safe access from multiple threads. Among these structures are ConcurrentDictionary and ConcurrentStack. These have slightly different methods for adding and retrieving members than their non-thread safe counterparts but provide a fast way to work concurrently with shared data.

Original article

This is the first item in my series “Oxygene by Example”, this time about singletons.

Singleton classes are used when there’s only ever one instance of a class needed. They differ from Static Classes in that they have an actual instance, can implement an interface and you can use them as parameters to a method. There are different ways of writing singletons, but the easiest way is by using a readonly class variable:

type
  IObjectCache = interface
    method GetOrCreate(aName: string; aNeedNewValue: Func): T;
  end;
  GlobalObjectCache = class(IObjectCache)
  private
    fCache: Dictionary := new Dictionary;
 
    constructor; empty; // required to be private; so nobody can instantiate it
  public
    class property Instance: MySingleton := new MyObjectCache; readonly;
 
    method GetOrCreate(aName: string; aNeedNewValue: Func): T;
  end;
 
method GlobalObjectCache.GetOrCreate(aName: string; aNeedNewValue: Func): T;
begin
  locking fCache do begin
    var lValue: Object;
    if fCache.TryGetValue(aName, out lValue) then exit T(lValue);
    result := aNeedNewValue();
    fCache.Add(aName, result);
  end;
end;

Using the singleton is simple, GlobalObjectCache.Instance gives access to all instance members of the class:

  lblSystemName.Text := GlobalObjectCache.Instance.GetOrCreate(
    'ComputerName', -> Environment.MachineName);

The latest version of this article can be found Here.

Last week I started on a series of articles called Oxygene by Example. They’re stored in the wiki at wiki.oxygenelanguage.com/en/Oxygene_by_Example and go over different problems while providing a solution written in Prism. So far I’ve written articles about:

• Singleton – Single instance class
• CommandLine – Parsing command line arguments and options
• Threading – Working with threading in Prism
• XML – Reading and writing XML files
• Parsing – A simple expression tokenizer and parser
• Visitor – A Visitor/Mutator pattern that can be used to do anything with a tree

Suggestions for other things I should write about are welcome, my ideas for further articles are the activator pattern, iterators, the observer pattern, working with linq, working with reflection, sockets and binary trees.