This final post in the mini-series re-creating a random number app for OS X, Android and .NET has taken a while not because it’s complicated but because I’ve been distracted by a far more significant cross-platform project and some significant and exciting developments in the world of Fire and Elements. More on that later
First, let’s get this .NET app out of the way.
For this exercise we actually have to leave Fire and use the Visual Studio hosted Elements compiler. As mentioned before, Fire does not provide any UI designers so for WinForms applications the UI design has to be done in Visual Studio (or create the UI in code explicitly of course).
You can compile a .NET application in Fire, in which case it produces a mono application, including support for WinForms. But although the Elements compilers also fully support WPF applications for .NET (again, with Visual Studio providing the design surface) mono itself does not provide any support for WPF. As a result those projects cannot be compiled in Fire. They can of course be developed fully in Visual Studio.
There really isn’t much to be gained from using mono to run .NET code on a Mac when you can just create native OS X apps (and which look far better than mono Winforms apps). So for this exercise I’ll just go ahead and create the .NET apps in Visual Studio.
First up, here is our UI design which should be very familiar by now:
Now for the code, most of which in this simple case is boiler-plate, produced by the template or the form designer. The only work I have to do is add the existing Shared Code code project to the references of the .NET project.
The solution already contains the shared code project I need because this is the same solution I was working on in Fire itself. Similarly when I re-open the solution in Fire I will see the new .NET project I have added.
Worth nothing here is that the build configuration settings used to determine which projects are included when the solution is built is one of the few things that are not shared between Fire and Visual Studio. So with the same solution I can fluidly switch between Visual Studio and Fire to build the projects appropriate to the platforms I am working on in each IDE.
Back to the .NET project. With the shared code project added to references, I can then add RandomNumber to the uses list of my form:
namespace RandomNumber.NET;
interface
uses
System.Drawing,
System.Collections,
System.Collections.Generic,
System.Linq,
System.Windows.Forms,
System.ComponentModel,
RandomNumber;
type
/// <summary>
/// Summary description for MainForm.
/// </summary>
MainForm = partial class(System.Windows.Forms.Form)
private
{$REGION designer-generated code}
method btnSeed_Click(sender: System.Object; e: System.EventArgs);
method btnGenerate_Click(sender: System.Object; e: System.EventArgs);
{$ENDREGION}
private
property Random: RandomNumber read write;
protected
method Dispose(disposing: Boolean); override;
public
constructor;
end;
So that’s two lines of code added: One to bring in the namespace containing my cross-platform RandomNumber class and the other to declare a private read/write property to hold a reference to an instance of that class.
Which leaves just the implementation of the two button click events which again is mostly designer generated code and some very familiar calls to the methods of the random number generator:
method MainForm.btnSeed_Click(sender: System.Object; e: System.EventArgs);
begin
Random := new RandomNumber;
lblText.Text := 'Random Number Generator Seeded';
end;
method MainForm.btnGenerate_Click(sender: System.Object; e: System.EventArgs);
begin
if assigned(Random) then
lblText.Text := Random.Next(100).ToString;
end;
And that’s it.
It bears mentioning again I think that although I called RandomNumber a “cross-platform” class, this isn’t strictly accurate. In fact, it’s not at all accurate.
Remember that for .NET my class is simply mapped – directly – to the .NET framework Random class. There is no separate class that is some cross-platform wrapper around the platform classes. This reference to a RandomNumber instance is in fact a reference to an instance of System.Random (on .NET). On OS X it is an entirely new class which encapsulates the required posix PRNG API’s.
In the case of the RandomNumber class, this has been a fairly trivial (some might even say ‘pointless’) exercise. But it provides an introduction to the basic idea which we can build on for far more useful exercises.
And the utility of consistent, cross-platform implementation is likely to become ever more significant for Elements with the recent introduction (today in fact!) of the first beta of Island.
Because this adds two entirely new platforms to the Elements stable, in addition to .NET/mono, iOS/OS X and Java/Android. The two new platforms are:
- Linux CPU-Native code
- Win32/64 CPU-Native code
Very interesting and exciting times indeed and I shall be posting on these as and when I learn more about them (the beta is downloading as I finish up this post). 🙂
Exciting times indeed.