iOS 7 is a major new release and – most observers agree – a game changer. It’s a whole new UI paradigm for the OS, and will be a very exciting release for both users and developers; there are a whole bunch of new technologies that will let you create even better iOS apps, and will make the whole iOS experience even better for the user — in the core OS or with your apps.

Due to the massive UI overhaul, most iOS apps will need a serious rethinking for iOS 7 to stay relevant – which means extra work for developers, but also extra opportunities. From what i can tell (and am allowed to tell), switching an application over to the core iOS 7 “look” will be simple, but really making an app feel at home on iOS7 will require a lot of thought — no way around it.

I have already started moving two of our (internal) apps to iOS 7 while on site in San Francisco, simply because after (foolhardily) upgrading my main phone to the new OS, i could no longer stand looking at the old UI ;). One app is “done” and was relatively straight-forward – mainly a matter of rebuilding with the iOS 7 SDK, and making a few adjustments here and there to better embrace the new style; the other will be more work.

OS X Mavericks (if you don’t like the name, you are not alone. Virtually everybody i talked to or heard talk about it found it “weird”) is a smaller upgrade, by comparison, but also a significant release with a ton of exciting technologies for developers – two that were highlighted in the keynote include the new Maps API and cool new energy-saving APIs and technologies. (And if you’re not excited by being able to make your apps more power-efficient, then you have no business developing Mac apps! ;).)

Of course the big question you’re all asking is how Oxygene for Cocoa is working with the new iOS 7 and OS X Mavericks. The good (and slightly unexciting, because expected) news is: it works just fine. We’ve long had an article on the Wiki that discusses the (simple) steps for hooking up Oxygene with new beta SDKs, and Oxygene is working fine with iOS 7 and with Mavericks (although i do recommend grabbing the latest beta drop of Oxygene, as we already made some tweaks and improvements there).

All the new APIs (IIRC Apple mentioned a number of 1500 new APIs being available) will work with Oxygene out of the box – no need to wait for anyone to create any wrappers or headers for you, and re-building your Oxygene apps with the iOS 7 SDK will give you the new iOS 7 look right away (but not save you from re-examining how to really embrace iOS 7 best with your app, of course).

There are also a few new non-API features that we’ll be embracing with Oxygene as well, but unfortunately those are (afaict) all under NDA, so i cannot talk about them yet. But suffice to say over the next few months we will of course be doing a lot of testing with Oxygene and the new APIs and SDKs to keep Oxygene up to date with the SDKs and the Xcode 5 tool chain.

Of course we’ll also be testing Data Abstract and RemObjects SDK for Cocoa with the new SDKs, and (where applicable) expanding them with support for new APIs. In my testing so far, they work great (both the apps i mentioned above are DA-based, and run fine on iOS 7, for example).

Support

Talking about new iOS and OS X SDKs is always a tightrope walk, as there’s a lot of information that’s under NDA (but available to all registered Apple developers – so do make sure you check out the beta builds and all the videos from WWDC). But Oxygene, as well as RO/DA for Cocoa, are already working great with the new operating systems, and we’ll be working hard to expand those parts that do need explicit support and work to fully embrace the new OSs.

If you have any specific questions regarding support for or issues with the new SDKs, there’s two places to get help: for one, we’ll be monitoring and participating in Apple’s beta forums, so you can post questions about Oxygene there (maybe add “(Oxygene)” to the subject so we can find them easier). And you can also always directly email support.

We cannot discuss the iOS 7 or OS X Mavericks Beta SDKs on Connect; you could be violating your NDA by posting details there, and we’d be doing the same by answering. So be careful.

Summary

I’m very excited about both iOS 7 and Mavericks (and i assume i’ll eventually get over the name, too), and so should you. I’m looking forward to seeing what you’ll build on the new OSs with Oxygene and Data Abstract.

Recently I’ve spotted a question about Nougat samples in the support thread. Unfortunately, we didn’t offer any sample applications at that time, so I’ve tried to quickly compose one.

We’ve already proposed some New Project templates for Data Abstract for Cocoa though:

Using these templates, and after going through several steps in the wizard, we can get an almost complete data-aware application (we just need to review and adjust the code in several places marked with a #warning directive).

So I’ve started with this New Project wizard and created a client for the PCTrade sample domain exposed by Relatvitiy server.

In this sample, I want to show several things:

• Working with Relativity server.
• Downloading data at the client side in an asynchronous way.
• Using Cocoa NotificationCenter.
• Master-Detail navigation in the data.
• Using Calculated fields for the DADataTable.
• Conditional formatting of the table view cells.
• The application should be universal and support both iPhone and iPad.

At the same time, I’ve tried to keep things as simple as possible to make it easy to understand common ideas.

So let’s start:

Working with Relativity domains

Almost all implementation required for connecting to the Relativity server, including autentication at the Relativity side, is done by the template and new project wizard. Most important places in the code are highlighted with the #warning directive. For example, in the DataAccess.pas file you can see the following place:

    {$WARNING  Define your server address and Relativity domain name, below.}
    const SERVER_URL  =                    'http://192.168.0.22:7099/bin';
    const SERVICE_NAME =                   'DataService';
    const RELATIVITY_DOMAIN  =             'PCTrade Sample';
    const DOMAIN_SCHEMA  =                 'PCTrade';

Here you can adjust the URL of your Relativity server (my server uses http://192.168.0.22:7099/bin).
These constants will also be used for configuring the RemoteDataAdapter instance.

Another place that requires our attention is in the AppDelegate.pas and holds the passwords to log in to the Relativity domain:

method AppDelegate.needLogin(var aLogin: String) password(var aPassword: String): Boolean;
begin
  // The DataAccess automatically takes care of storing login information in Settings and Key Chain
  // and retrieving it as necessary. This method is only called when no login is stored (i.e. on first
  // run) or if the retrieved login was rejected by the server.
  // Typically, you would implement this method to bring up the UI that asks the user for his credentials.
 
  // By default, new Relativity Server domains will use "Data"/"Relativity" as login, unless
  // the login provider setup has been changed by the administrator.
  aLogin := 'Data';
  aPassword := 'Relativity';
 
  result := true; // return YES if the user provided login details, or NO if the user canceled
end;

Of course, in the real application, you can implement a popup window here with to enter login and password, or even get credentials from the application preferences, but I’m trying to keep it simple here.

Downloading data

Again, like in the point above, almost all implementation for downloading data from the server was generated automatically by the new project wizard.

You may notice that all the tables we selected in one of the last wizard step, were created with the appropriate properties in DataAccess.pas and code has been generated to fill them.

method DataAccess.downloadData;
begin
  // ToDo: Add code to download data from server
  // You will need to define fields and, if necessary, properties for your tables.
 
  var tableNames := new NSMutableArray<String>;
  tableNames.addObject('Clients');
  tableNames.addObject('OrderDetails');
  tableNames.addObject('Orders');
 
  var tables := fRDA.getDataTables(tableNames);
 
  Clients := tables['Clients'];
  OrderDetails := tables['OrderDetails'];
  Orders := tables['Orders'];
end;

It is important to note here that the given downloadData method is called asynchronously (in a separate thread), so we get a responsive and non-frozen UI.

method DataAccess.loadInitialData;
begin
  dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), method begin
      ...
      downloadData();
      ...
      dispatch_async(dispatch_get_main_queue(), -> triggerDataReady);

Using notifications

Since we are downloading data in a separate thread, we need to notify our main UI thread with the results.
And here the Cocoa Notification Center comes in to help us.
In the code above you may have notice that after downloading the data, we perform a triggerDataReady call at the main thread. This method just posts a notification to the Notification Center that the job is done.

method DataAccess.triggerDataReady;
begin
  dataReady := true;
  NSNotificationCenter.defaultCenter.postNotificationName(NOTIFICATION_DATA_READY) object(self);
  NSLog('data is ready.');
 
  // ToDo: Add any processing you want to do once the data is fully ready
end;

Thus, if our controller needs to be informed about loading data results, we need to subscribe it to this notification. You can find the code in the ClientsViewController.pas file.

 
method ClientsViewController.viewDidLoad;
begin
  inherited viewDidLoad;
  // Do any additional setup after loading the view, typically from a nib
  ...
  NSNotificationCenter.defaultCenter.addObserver(self) 
                                     &selector(selector(dataReady:)) 
                                     name(DataAccess.NOTIFICATION_DATA_READY) 
                                     object(DataAccess.sharedInstance);
  ...
end;
 
method ClientsViewController.dataReady(notification: NSNotification);
begin
  tableView.reloadData();
end;

That means that when our ClientsViewController receives the DataReady notification, the dataReady: method must be invoked, which then refreshes the content of the table view.

Master-Detail navigation

This feature is part of the New Project template. By default, it generates already configured Master and Detail view controllers and the corresponding storyboards files with proper transitions between views inside.

Concrete implementation depends on device type.
For iPhone/iPod devices with their relatively small screens, when user selects a certain cell, the proper transition will be invoked and we can hook on it and set the info for the detail controller.

method ClientsViewController.prepareForSegue(segue: UIStoryboardSegue) sender(sender: id);
begin
  if segue.identifier.isEqualToString('showOrders') then begin
    var ip := tableView.indexPathForCell(sender);
    var tableRow := self.dataTable.rowAtIndex(ip.row);
    segue.destinationViewController.setDetailItem(tableRow);
  end;
end;

For the iPad device, the master and detail view are visible at the same time – no transition required. So we can just hook at the didSelectRow event and provide the details data for the detail controller as shown below:

method ClientsViewController.tableView(tableView: UITableView) didSelectRowAtIndexPath(indexPath: NSIndexPath);
begin
  if UIDevice.currentDevice.userInterfaceIdiom = UIUserInterfaceIdiom.UIUserInterfaceIdiomPad then begin
    var tableRow := self.dataTable.rowAtIndex(indexPath.row);
    OrdersViewController.detailItem := tableRow;
  end;
end;

About the details data: Since all necessary data is already present at the client-side, we are performing just a local data filtering using NSPredicates:

method DataAccess.OrdersByClient(client: String): NSArray;
begin
  var filterPredicate := NSPredicate.predicateWithFormat('Client == %@', client);
  result := self.Orders.rowsFilteredUsingPredicate(filterPredicate);
end;

Using Calculated fields for the DADataTable

As you might know, we can easily extend any existing DADataTable with our custom lookup and calculated fields which could help us get various related information. For this sample I need to know the amount of orders for each of our clients and also want to know the total for each client order (which can be calculated by summing the OrderDetails rows).

There is the special setupData method in the DataAccess class. It will be called while loading the initial data, so I can be sure that my tables will be extended in a proper way.

Declaring calculated fields is easy, we just need to specify the field name, its type and the target and selector for the method that will be used for calculation.

method DataAccess.setupData;
begin
  // Use this method to implement any setup that is needed on your data tables, such as
  // creating lookup or calculated fields, etc.
  self.Clients.addCalculatedFieldName('OrdersCnt') 
                            dataType(__enum_DADataType.datInteger) 
                              target(self) 
                           &selector(selector(calculateOrdersCntForClientRow:)); 
 
  self.Orders.addCalculatedFieldName('OrderSum') 
                             dataType(__enum_DADataType.datCurrency) 
                               target(self) 
                            &selector(selector(calculateSumForOrderRow:)); 
end;

As a rule, calculation methods take a row instance as the parameter and return an object (id) as the result of the calculation. So here is the sample of our calculation method:

method DataAccess.calculateSumForOrderRow(row: DADataTableRow): id;
begin
  // Get the Order ID value from the row 
  var orderID: Integer := row.valueForKey('OrderId').integerValue;
  // Prepare filter to obtain details on given order
  var condition: NSPredicate := NSPredicate.predicateWithFormat('Order == %d', orderID);
  // Get the order total
  var orderSum: Double := self.OrderDetails.rowsFilteredUsingPredicate(condition).valueForKeyPath('@sum.Total').doubleValue();
 
  // Wrap it into an id object and return
  exit NSNumber.numberWithDouble(orderSum);
end;

Conditional cell formatting

It has become common practice to give a slightly different design to each cell depending on the data it represents. For example, the developer can play with font, size, color, etc. All this makes the data more obvious and easy to perceive.

We will use a similar approach for our application. We already have the method tableView() cellForRowAtIndexPath(): UITableViewCell which composes the cell for any table row we want to show.

method ClientsViewController.tableView(tableView: UITableView)
                 cellForRowAtIndexPath(indexPath: NSIndexPath): UITableViewCell;
begin
  var CellIdentifier := "Cell";
  // Try to obtain cached cell
  result := tableView.dequeueReusableCellWithIdentifier(CellIdentifier);
 
  // This is required only if you are targetting iOS 5.1 or lower
  if not assigned(result) then
    // If there is no such cell cached, then just create a new one
    result := new UITableViewCell withStyle(UITableViewCellStyle.UITableViewCellStyleValue1) 
                                  reuseIdentifier(CellIdentifier);  
  
  // Note that we used UITableViewCellStyleValue1 as the UITableViewCellStyle
  // which makes the cell with the value aligned to the left side and the detail value aligned to the right side of the cell
  var tableRow := self.dataTable.rowAtIndex(indexPath.row);
  result.textLabel.text := tableRow['ClientName'];
 
  // Get the count of orders (as you remember, OrdersCnt is the calculated field)
  var ordersCnt: Integer := tableRow['OrdersCnt']:integerValue();
 
  // And depending on the orders count we can use different colors and different icons for the given cells
  case ordersCnt of
    0: begin 
        result.detailTextLabel.textColor :=  UIColor.blueColor();
        result.imageView.image := UIImage.imageNamed('1');
        result.detailTextLabel.text := 'No orders'; 
    end;
    1: begin
      result.detailTextLabel.textColor := UIColor.orangeColor();
      result.imageView.image := UIImage.imageNamed('2');
      result.detailTextLabel.text := NSString.stringWithFormat('%d order', ordersCnt);
    end;
    2: begin
      result.detailTextLabel.textColor := UIColor.magentaColor();
      result.imageView.image := UIImage.imageNamed('3');
      result.detailTextLabel.text := NSString.stringWithFormat('%d orders', ordersCnt);
    end;
    else begin
       result.detailTextLabel.textColor :=  UIColor.redColor();
       result.imageView.image := UIImage.imageNamed('4');
       result.detailTextLabel.text := NSString.stringWithFormat('%d orders', ordersCnt);
    end;
  end;
  
end;

As a result of our efforts above, we now have the following application:

And finally, as a small bonus, this is how it looks in iOS7 ;)

You can get sources of the sample download here

Thanks for your attention! ;)

I thought it might make sense to post this message here, to make sure noone misses it.

Dear Embarcadero Customer,

Embarcadero Technologies is pleased to announce the release of Embarcadero Prism XE3.2.

Embarcadero Prism is no longer an included product within RAD Studio as of the XE4 release. Maintenance updates will continue to be provided through August 2013, after which no more maintenance releases are planned.

We wish you success in using this latest Embarcadero Technologies product.

Regards,

Embarcadero Product Management

We want to thank our friends and partners at Embarcadero once again for getting the word out on this, and for letting our shared customers know where to obtain Oxygene going forward, especially beyond August. It goes without saying that we (RemObjects Software) will honor all active SA contracts, on our dime, beyond August. Please contact us if you have any questions.

The first one is public -addNewRowWithDataFromDictionary:inEditMode:

It returns new row with values from specified dictionary which contains key-value pairs with field name as the key and value – as value for given field.

NSDictionary *data = @{
  @"WorkerBirthDate" : date,
  @"WorkerLastName"  : @"Doe",
  @"WorkerPosition"  : @"Boss",
  @"WorkerFirstName" : @"John"
};
 
DADataTableRow *row = [table addNewRowWithDataFromDictionary:data inEditMode:NO];

Since it takes a dictionary, and we know to what field given value belongs, then there is no matter in what order you will put the data – it can differs from order of fields in the table.

This method also perform some basic validation. If you will specify value for field which does not belongs to the table then it throws an exception saying that given field does not exists in the table.

I also need to say few words about adding rows for tables with autoincrement fields. As you might know, when you insert new row to the table with autoincrement key, Data Abstract, at the client side, will provide temporary key value. It is an negative integer value in order not to interfere with existing positive values.

-addNewRowWithDataFromDictionary:inEditMode: method does not allow you to specify custom value for such autoincrement key. Though it does not firbid to change temporary key value before sending an updateData request.

To avoid ambiguity, if you include value for autoinc field to the dictionary then adding new row will throw an exception saying that you cannot specify custom value for autoincrement field.

So general recomendation here will be – If your table has an autoincrement key field then just omit passing its value. It will be generated automatically.

And finally you don’t need to pass values for ALL fields. You can specify only ones you need. It also can be handy for setting defaults.

The second method -addNewRowWithDataFromArray:inEditMode: is less safe. It just takes an array of values for new row. Thus, orders of values here plays the very important role. There is no special validation and checkings of the passed arrays. So you must be sure what you are passing there.

For these reasons, we make this method as internal. You can use it when import proper header file like shown in code snippet below.

The benefit in using this method is in its simplicity and conciseness.

#import <DataAbstract/Internal.h>
...
NSArray *data = @[
   [NSNull null],
   @"Bond",
   @"James",
   date,
   [NSNull null],
   @"Spy"];
 
DADataTableRow *row = [table addNewRowWithDataFromArray:data inEditMode:NO];

As I’ve said, order of values here is important so when I want to skip value for certain field then I need to pass a null object there.

On start, the DA SQL Browser will prompt you to connect to the server with the following dialog:

You can see that several fields are already filled with default values, which will work with a DA Sample Server.
Unfortunately, the login dialog of the DA SQL Browser is not that easy to use when connecting to Relativity Server (after all, the DA SQL Browser was created much earlier than the Relativity project). You have to provide somewhat cryptic “additional login parameters” like Domain=PCTrade Sample;Schema=PCTrade.

Considering this, a new option was introduced, so you can see a checkbox Relativity Server on the bottom of the form.

When you click it, it gives another drop-down lists to pick a Domain Name and a Schema Name. Note that you can still fill these names manually, but as long as the dialog’s Server URL to the Relativity Server is valid, these lists will have all the domains and schemas you need.

Now, you can connect to the Relativity Server and try some queries and (maybe later) include them in your client application. And I hope the DA SQL Browser will help you with your projects.

The Oxygene language now gives ways of coding for all the currently interesting platforms using the three available editions of Oxygene:

• Oxygene for .NET (formerly also known as Delphi Prism) – targets the .NET platform, allowing you to build Windows applications, Windows phone applications, Silverlight applications and so on, using the relevant .NET frameworks. Also targets the Mono platform, allowing applications to go to the many places where Mono goes, such as Mac and Linux and also Android and iPhone/iPad using Xamarin.Android (aka Mono for Android) and Xamarin.iOS (aka MonoTouch) using those frameworks.
• Oxygene for Java – targets the Java runtime, allowing you to build Java apps, Java servlets, Java applets and also, perhaps most interestingly, Android apps. Java apps will use your chosen Java frameworks and Android apps use the Android SDK framework.
• Oxygene for Cocoa – targets iOS and OS X allowing native ARM applications to be built for iPhone and iPad as well as 64-bit native OS X applications. Applications are built against the native OS X Cocoa and iOS CocoaTouch frameworks.

Oxygene is hosted in Visual Studio 2012 (support for Visual Studio 2010 has now been phased out in Oxygene 6.0). If you don;t have a copy of Visual Studio 2012 the Oxygene installer can set up the Visual Studio 2012 shell first.

For existing users of Oxygene for .NET and/or Oxygene for Java there are some new features added to Oxygene 6.0, including a spate of new conditional defines to help distinguish which compiler built your code or which platform you are targeting:

However the main thrust of the release is Oxygene for Cocoa, which works in conjunction (if you want) with Apple’s UI designer to support visual UI design via nib (.xib) files or storyboard files. It also understands and fully supports multi-part method names so that it fits in directly with the Objective-C naming system and can represent and refer to any existing methods. It support the iOS Simulator, supports debugging there and on-device and offers all the options needed to sign and provision your apps. It supports ARC (automatic reference counting), understands bridging and uses an LLVM back-end to generate good ARM and 64-bit Intel code.

It ships with all the standard frameworks imported and has a tool that allows you to import any additional libraries you need to work with. Because Oxygene always uses the frameworks that natively exist on the target platforms, there is not an awful lot to learn specific to Oxygene when building Mac or iOS apps. Anything you learn on the Internet about how to build aspects of Mac/iOS apps applies directly – it’s just a case of expressing the various local API calls in the Oxygene syntax, which is a very familiar Object Pascal based syntax.

During pre-release development Oxygene for Cocoa was called Project “Nougat” and I worked with it a lot to keep tabs on how it progressed. I’ve built a whole bundle of test apps to keep on top of (mostly) iOS application development techniques by simply following various online Objective-C tutorials, and just entering the code in Pascal instead of in Objective-C.

I’m delighted Oxygene for Cocoa is now released as I’ve been productive with the tool for quite a long time now. I’ve wanted to make blog posts about how I do thing with it, but given it’s just a syntax shift there hasn’t really been much of a need for it. I guess maybe I’ll do one at some point to show the basics of building up an iOS app in the Visual Studio IDE and getting it launching in iOS Simulator, but after that it’s just writing code in the same way any other iOS developer does; just in Pascal.

On June 17th I’ll be demonstrating the product with a talk at a Developers Group meeting in Maidenhead, UK.

You can find more information about Oxygene for Cocoa at these links:

• Oxygene 6.0 release announcement post
• Tim Anderson’s post on the release
• Oxygene iOS platform links
• Oxygene OS X platform links
• Oxygene “Nougat” overview podcast
• Bridging
• Creating a Turn-based Game for iOS: Tic-Tac-Toe
• Custom iOS controls in Oxygene “Nougat”
• Using Instruments Profile Mac and iOS Apps
• .xib and .storyboard files
• What is “Nougat”? – Part 1 – introduction, emphasising and illustrating the native targeting aspects
• What is “Nougat”? – Part 2 – target platforms, ARC, boxing and references
• What is “Nougat”? – Part 3 – the IDE, building and running an app
• What is “Nougat”? – Part 4 – the build & deploy process

Buying Oxygene is reasonably pocket-friendly. If you’re new to it then $699 gets you all three versions. Otherwise there is a $499 renewal price for existing Oxygene for Java or Prism customers, a $599 cross-grade price for any users of Embarcadero Delphi or of older Embarcadero Prism versions (XE2 and below) and also a $99 academic price.

If you want to see how you get on with Oxygene 6.0 without committing you can always pull down a trial version first.

Hello everyone.

We are more than pleased to announce the release of Oxygene 6, the next major milestone of our Oxygene language. This new version includes a significant update to the existing “Oxygene for .NET” and “Oxygene for Java” editions, but – most excitingly – it also marks the first release version of our all-new Oxygene for Cocoa.

Oxygene for Cocoa is a brand-new edition of our Oxygene language, and it targets native Mac and iOS development with the Cocoa frameworks, using the same great language you already know and love from .NET and Java. We are very excited about Oxygene for Cocoa, and we think it will be a game-changer for how you create apps for Mac and iOS.

Oxygene for Cocoa is a very unique product, in that it is the only language (next to Apple’s own Objective-C) to truly natively target the Cocoa platform and the Objective-C runtime. It gives you access to all the great frameworks and libraries provided by the platform, lets you use all the native UI controls, and generates executables that are lean, mean and blazingly fast – and compiled directly for Intel x64 (Mac) or ARMv7 and ARMv7s (iOS).

Get Oxygene now

Support for all three platforms is available in the new Oxygene 6 package, which is a free update for all active subscribers who bought Oxygene form us since last August. It is available for new users at only $699 (again including all three platforms!), and individual platform support is also included in our Suite Subscriptions for .NET, Cocoa and Java, respectively.

Special renewal pricing is available for existing Oxygene for Java or Prism customers $499, as well as a special $599 cross-grade offer for any users of Embarcadero Delphi or of older Embarcadero Prism versions (XE2 and below).

We’re also for the first time ever introducing a new academic pricing for students, teachers and non-profit researchers, at an amazingly low $99.

And of course, as always, theres a free fully-functional 30-day trial version available, as well.

This is only the beginning

But we’re just getting started with this release and have many further exciting things planned for this year and beyond, including two minor updates for June and July, a significant “6.1” release in Fall, as well as several related products and technologies that will extend the Oxygene ecosystem that we’re not quite ready to talk about yet.

In the meantime, we hope you will enjoy the first release of Oxygene 6.0 and Oxygene for Cocoa – and we’re looking forward to hearing what Apps you will be building with it!

You can learn more about Oxygene at remobjects.com/oxygene and wiki.oxygenelanguage.com.

Yours,

marc hoffman
Chief Architect,
RemObjects Software

RemObjects SDK is an awesome framework. Not only because its development feeds me and my 10 cats ;) but also because it allows to efficiently create applications on literally a dozen different platforms (to name them: Win32 (a.k.a. Delphi apps), desktop .NET framework, Windows Phone, Silverlight, Mono, Android, Android via MonoAndroid, iOS, iOS via MonoTouch, native MacOS X apps, Java and JavaScript). Unfortunately, it takes a bit of time to get started with developing, you can’t just jump right in. I myself (and most of the software developers I know) usually want to try their new, just downloaded toy without reading a ton of documentation pages.

So this article will try to be a kind of “crash course”. It won’t go very deep (there are Wiki articles on just about anything, if you want to delve in deeper, and our support team will help you with any questions), it will just try to give you some ‘feeling’ for the tech, a foothold to conquer the new framework.

This article covers the .NET version of the RemObjects SDK, however, the main approach will remain the same for all platforms (.NET, Xcode, Delphi, Java, JavaScript), so you won’t waste your time with this article, even if you don’t use .NET in your development work.

My colleagues will provide similar articles devoted to the other supported platforms later this month.

Note: This article covers the ‘Client Calls The Server’ scenario and doesn’t touch the ‘Server Pings The Client’ one. At this moment it is enough to know that the latter scenario is possible as well and its implementation won’t affect the former one.

The Core

The very heart of the RemObjects SDK is based on Channels, Messages, Envelopes and Services. Two more components used under the hood are Interfaces and Invokers. Don’t be afraid of these words, things are actually simpler than they look.

Let’s take a look at the ‘Client calls the server method’ scenario:

var methodCallResult = sampleService.DoSomething();

Looks simple, doesn’t it?

Here’s what happens from the RemObjects SDK’s point of view:

The client code calls the Foo method of some object serverService. Here, sampleService is an instance of the auto-generated proxy class, so calling the sampleService.DoSomething() method actually means the following:

1. Sending out a request
The Interface class serializes the request to the server using the configured Message. The Message is then wrapped by the attached Envelopes, if any are set up (f.e. data is encrypted somehow). Then the resulting data package is sent over the wire by the Client Channel.

2. Processing the request on the server side
The Server Channel retrieves the data package and pushes it to the Message component. Message unwraps it using the attached Envelopes, if needed. The resulting data package is provided to the Invoker, which reads the requested service, method names and method parameters from it.

Then the Service method is invoked, which does the actual job.

After the service method has finished, its result (or any exceptions occurred) are serialized, wrapped, and sent back over the wire using the Server Channel (yes, the processing pipeline is similar to step 1).

3. Retrieving the response
The Client Channel retrieves the data package, unwraps it and provides the serialized data package to the Interface‘s method that initiated the remote service call. This method then deserializes the provided data package and provides the method result back to the user code.

The magic is that the entire process is transparent for the user code on both ends of the wire and doesn’t require much attention from the developer. While the service method call pipeline might seem complicated (or even over-complicated), its performance overhead is negligible (especially for the binary serialization-based Message), making the actual network speed the main issue to care about, not the inner RemObjects SDK processes.

Sample Server

Let’s create a sample server and client app in a step-by-step guide and see how the Channels, Messages, Envelopes, Interfaces, Invokers and Services entities are implemented in a real RemObjects SDK-based application.

Prerequisites

For this tutorial you’ll need Visual Studio and either the RemObjects SDK for .NET or the Data Abstract for .NET frameworks installed. Also, a minimal knowledge of C# is required, but the same concepts would apply to Visual Basic for .NET, Oxygene or any other .NET language.

Server Application

As mentioned above, the server application should contain the Server Channel, Message, Envelope (if needed) and Invoker, as well as the Service itself.

1. Create a new Class Library project named BusinessLogic and add a single class to it:

using System;

namespace BusinessLogic
{
    public class StringProcessor
    {
        public Int32 Process (String value)
        {
            if (String.IsNullOrEmpty(value))
                return -1;

            return (value + @"Secret Salt").GetHashCode();
        }
    }
}

This project imitates an already existing implemetation of a real-world business logic method that should be exposed to remote client applications. While it is not necessary to put the business logic into a separate project, it was done here to emphasize that the business logic layer is fully separated from the to-be-implemented communication layer.

2. Add a new Windows Forms project to the solution and name it SampleServer. Of course, a real-world server application should be running as a Windows Service (and RemObjects SDK provides the needed application template), but for this “crash course” it will be easier to use the simple Windows Forms project.

3. Add the following references to the SampleServer project, as they provide the needed classes:

• RemObjects.InternetPack.dll
• RemObjects.SDK.dll
• RemObjects.SDK.Server.dll
• RemObjects.SDK.ZLib.dll

Also add a reference to the previously created BusinessLogic project, as we will expose its methods in the server.

4. Now we need to define the Server Surface Area, i.e. the service name, its methods, their parameters and return values, etc. This step is needed to allow the RemObjects SDK to generate strongly-typed Interface and Invoker classes.

Add a new ‘RemObjects SDK Service Definition’ item to the project.

A new file named NewLibrary1.RODL will be added to the project and the Service Builder app will be started automatically. The RODL is an XML file containing the service definition written in the ‘RemObjects Definition Language’ (or RODL), and the Service Builder provides the GUI to edit .RODL files without diving into the definition language syntax. Please note that the RemObjects SDK exposes the object model that allows to load, parse and generate .RODL files (and even to generate code based on these files), but this topic is outside the scope of this article.

As you can see, the file is almost empty. Select the single topic in the tree on the left side of the app’s window. The edit boxes that will appear will allow you to change the library name, set its namespace or even write its definition. Set the Library name to BusinessLogicLibrary.

A Library contains all the entities in the given RODL file. Consider it as a root of a service definition tree.

The next step is to define the Service. Press the ‘Service’ button (or right-click the Library name in the tree and issue the ‘Service’ context menu command) and rename the just added Service to BusinessLogicService. 

Now we can define this service’s methods. Press the ‘Add Operation’ button (the one with the green “+” glyph). A new method named ‘NewMethod’ will be added. Double-click its definition and change the method’s name to Process.

The last step is to define this method’s parameters and set its return type. Press the ‘Add Parameter’ button and change the parameter’s name to ‘value’. Change the parameter’s type to Utf8String (the ‘Data Type’ editor allows to select a type name from a combo box, so there is no need to enter it manually).

Set the Result type to Integer (the type name can be selected from the combo box as well).

If everything was done right, the Service Builder window should now look like this:

Close the Service Builder.

Set the ‘Build Action’ of the just added RODL file to ‘Embedded Resource’, so it will be embedded into the compiled application. You will find out why this is needed below.

5. As you can see, once you closed the Service Builder, three new code file were added to your project: BusinessLogicLibrary_Intf.cs, BusinessLogicLibrary_Invk.cs and BusinessLogicService_Impl.cs.
BusinessLogicLibrary_Intf.cs contains the Interface classes, BusinessLogicLibrary_Invk.cs contains the set of Invoker classes and BusinessLogicService_Impl.cs is a blank Service implementation class.
There is no need (and it is NOT recommended) to edit the code in the first two files.

In case you change the RODL file (for example add one more method to the service definition), the *_Intf and *_Invk files will be regenerated automatically to reflect the RODL changes. At the same time the _Impl file will stay untouched to prevent any code loss. Since the service implementation class contained in the _Impl file implements the service interface contained in the _Intf file, the service project won’t be able to build until the Service implementation class will match the Service definition.

For example: If you add a method to a service definition, the interface representing this service in the _Intf file will contain the new method definition as well. And because the Service implementation class has to implement this interface, the developer will have to add the corresponding method implementation to the service definition class.

6. Open the Service Implementation file (i.e. BusinessLogicService_Impl.cs) and find the Process method implementation. It is empty, so change it to

public virtual int Process(string value)
{
    return (new BusinessLogic.StringProcessor()).Process(value);
}

At this time, we have defined and implemented a Service (and it probably took more time for you to read the text above than to actually execute the steps in Visual Studio). Now we need to make the service available remotely.

7. Below, we will manually implement the network connectivity layer using the RemObjects SDK components. This is done to demonstrate the ins and outs of the framework as the RemObjects SDK provides the application templates and (starting from the May 2013 release) the pre-implemented NetworkServer class that allows to implement the connectivity layer in literally 3 lines of code.

Open the main form in designer mode (remember that our server app is intentionally primitive, so no properly layered architecture or ‘Run As Windows Service’ support here):
* Add the IpHttpServerChannel and BinMessage components to the main form (note that a licenses.licx file was automatically added to the server app project. Please do not delete this file).
* Open the properties of the IpHttpServerChannel component and open the custom editor for the Dispatchers property.
* Press the ‘Add’ button and select the previously added BinMessage instance as a value for the Message property.

* Press OK to close the dialog and save the property’s value.

That’s it. The server message processing pipeline (i.e. the Server Channel and Server Message) is set up.

8. Open the code-behind file of the main form and add this code line to the very end of the main form class constructor:

this.ipHttpServerChannel1.Open();

This code line will ‘open’ the server channel so it will start to accept the incoming connections.

Now you can start the server app. Open a web browser and go to the page http://localhost:8099/rodl. The server app will show the contents of the embedded RODL file at this address. Note that you can always set the the ’Embedded Resource’ property to None for the RODL file and the server will not advertise its methods.

Client Application

Even the most advanced server application is useless if there is no client application for it. So… let’s create one!

If you remember, a client application needs the following components implemented: Channel, Message, (possibly) Envelope and Interface. This may look scary again, but it will be much easier than it sounds.

1. Create a new Console Application (for simplicity reasons).

2. Add references to the assemblies

• RemObjects.InternetPack.dll
• RemObjects.SDK.dll
• RemObjects.SDK.ZLib.dll

These assemblies provide the client connectivity classes (as you can see, there is no need to reference the RemObjects.SDK.Server.dll assembly).

3. Now issue the ‘Add’ -> ‘Existing Item’ command (available via the context menu for the client application project entry in the Solution Explorer).

4. Select the BusinessLogicLibrary_Intf.cs file (it can be found in the server’s project folder) and add it as a link.

Adding the _Intf file as a link has a little but important advantage over simply adding an existing file to the client app project: when the server RODL is changed, the _Intf file is automatically regenerated. If this file is added as a link, there will be no need to update the _Intf file copy contained in the client app project.

This step adds the Interface part of the client app.

4. Add the following code to the Program.cs:

using System;

namespace SampleConsoleApplication
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.Write("Enter string: ");
            String value = Console.ReadLine();
            Console.WriteLine();
            Console.WriteLine("Processing...");

            // Communicating with the server
            SampleServer.IBusinessLogicService service = new SampleServer.BusinessLogicService_Proxy(@"http://localhost:8099/bin");

            Int32 hash = service.Process(value);

            Console.WriteLine();
            Console.WriteLine("String entered: {0}", value);
            Console.WriteLine("String hash: {0}", hash);
            Console.WriteLine("Press ENTER to continue...");
            Console.ReadLine();
        }
    }
}

The Console.WriteLine and Console.ReadLine calls here are pretty usual for any console application. Let’s take a closer look at these code lines:

// Communicating with the server
SampleServer.IBusinessLogicService service = new SampleServer.BusinessLogicService_Proxy(@"http://localhost:8099/bin");
Int32 hash = service.Process(value);

Here, a proxy for a server app service is created and then a service method is called (the Channel and Message components are automatically created behind the scenes to make this possible).

The IBusinessLogicService interface lists all methods exposed by the remote service, while the CoBusinessLogicService.Create static method creates a proxy class that implements this interface. This makes it possible to perform calls to a remote server transparently for the client app’s code.

5. There are probably some explanations needed regarding where the “http://localhost:8099/bin” URL came from. Let’s take a closer look on each part of the URL:

• http – Protocol used by the server channel. In this sample, we use a simple HTTP channel. The RemObjects SDK supports several other communication protocols as well (f.e. TCP-based ones).
• localhost – Name or IP address of the server’s host.
• 8099 – Port the Server Channel is listening to. 8099 is the default port for the IpHttpServerChannel used in our server application.
• bin – So-called dispatcher name. This is the name of the Message on the server side that processes the incoming data package. bin is the default name for the BinMessage.

6. Build and start both the server and client applications. Enter any string into the client application window and see the result returned by the server app:

Conclusion

At this point you should have a basic understanding of how the RemObjecs SDK-based communications can be implemented. As an exercise, try to add one more method to the Service and call it.

This article doesn’t cover many (or even most) of the RemObjecs SDK features. Server Events, Envelopes, client authentication processing and SSL support were not covered for simplicity reasons. Search our Wiki for the questions you are interested in. If for some reason you can’t find the info you need, don’t hesitate to call on our support via RemObjects Connect or email to support@remobjects.com.

“With Oxygene i need to learn all the new platform APIs. If that’s the case, i might as well learn C# [or Java or Objective-C].”

That’s certainly true. When moving to and learning a new platform, there’s a vast number of things to learn — new classes, new APIs, new concepts, new ways of doing things. Learning a new language, especially if it’s one from the same broader family of languages you already know (i.e. Object Oriented languages) is only a small and insignificant part of that.

But, i think it is missing the point of Oxygene, to think its whole reason d’être is to save you from learning a new language. Quite the contrary.

Oxygene is based on Object Pascal, and is, at its root, very close to the “Delphi” language (which basically represents the state-of-the-art of Object Pascal ca. 2003). The main reason for that is not that Delphi developers (which the creators of Oxygene were too, at the time) do not have to learn a new language. The reason for that is that Pascal — as much as it has gone out of fashion over the past 20 or so years — is a freaking amazing base point for a programming language. It’s clean, well structured, easy to learn, and — very importantly — easy to read.

Many developers underestimate this, but they spend a lot more time re-eading their (and other’s) code than they originally spent writing it — so having a language that makes code easy to parse and understand by the human brain is a very important and undervalued feature of a language. One that Oxygene shines at like no other.

So that’s the why Oxygene is what it is, but is that enough reason to choose it over C#, Java or even Objective-C? No, of course not.

The biggest selling point for Oxygene in my opinion is not that it’s Pascal based, and is not that is allows you to natively compile for today’s three major platforms (.NET, Java and Cocoa) with the same code base, and it most certainly not that it saves you from doing anything (be it learning a new language, or be it spending more money on a more expensive development tool).

The biggest selling point of Oxygene is — quite frankly — that it is an amazing modern language, with features that developers using the other mainstream languages don’t even begin to dream about.

Going into details on all the features that make Oxygene unique and powerful, the features that will change your life as a developer, would require several posts on its own. But the scope ranges from Class Contracts to language-integrated parallelism, from nullable types to the amazing Future types, from small but powerful things like the colon operator and double boolean comparisons to “for” loop expressions (not to be confused with regular “for” loops), and from duck typing to language-native tuples.

The list could keep going on.

So when you’re looking at Oxygene (and i know you are), don’t just look at it from the perspective that it will let you keep coding in Pascal without having to learn a new language. Sure, that’s a big factor too. If you’re a Delphi developer, you probably love Pascal (like we do), and have been using it for the past 10, 20 or even more years. And being Pascal certainly is one thing that makes Oxygene attractive to you.

But don’t stop there; you’re doing Oxygene and yourself an injustice, if you look at that as the main benefit.

Instead, think of using Oxygene as switching to the most powerful and modern object oriented language out there, today. That it’s Pascal-based is just the icing on an already very delicious cake.

Ok, so the cat is out of the bag, if a few days ahead of schedule: starting with the upcoming release of XE4, Embarcadero Prism will no longer be part of the RAD Studio SKU, and there will be no “XE4″ branded edition of Prism.

But worry not. As you all know, Prism has been nothing more than a re-branded version of our Oxygene for .NET product — and Oxygene will keep going on, stronger than ever.

In fact, Oxygene has long outgrown its Prism-branded edition, first when we introduced full native support for Java and Android to the language over 18 months ago, and of course with our upcoming support for truly native iOS and Mac apps, shipping next month.

So “Embarcadero Prism” as a product is going away, but the Oxygene language you have come to love and depend on will continue to shine and evolve, as it always has.

What exactly does all of this mean?

We believe that in the end, this change will be a net positive for Oxygene.

When we first started working with Embarcadero in 2008 to bring Oxygene 3.0 into RAD Studio, Embarcadero had a gap left in their lineup with the discontinuation of their ill-fated Delphi for .NET product. Both companies shared a vision of Delphi and Oxygene — then getting branded Delphi Prism — becoming two sides of the same coin: two languages evolving together and influencing each other to push Pascal forward both for CPU-native Windows development and for managed targets.

Over the years, it turned out that this was not happening, and as Embarcadero was shifting their focus to “(CPU-)native, native über alles” and onto FireMonkey, Prism (and with it Oxygene, as i’m going to start referring to it from now on exclusively) became the odd man out — the product that was there, as part of RAD Studio, but no-one liked to talk about, because it did not really fit the vision of the company.

This became clearer as Oxygene evolved.

We added support for Java and (more importably) Android, but Embarcadero had their own (very long term ;) vision of how they wanted to pursue the platform that conflicted with what Oxygene had to offer. As a result, Oxygene was forced into a split personality — with Oxygene for .NET remaining under the Prism umbrella, and Oxygene for Java becoming a separate product (for a while).

At the same time, Embarcadero became less and less interested in actually marketing and promoting the product, and it was being relegated to a “filler” to pad up RAD Studio as a worthwhile product suite.

Things got even more complicated when we started working on “Nougat”, our vision for really and properly bringing Object Pascal and Oxygene onto the (misleadingly named) Objective-C runtime that is the engine behind iOS and Mac. Once again, Embarcadero had different plans for the platform, and what is more, they — understandably — raised the concern that Oxygene for Cocoa would be too direct a competitor to their efforts on iOS (albeit once again our two companies were following two very different visions).

To wrap things up short and sweet, as of right now, Oxygene is finally standing on its own two feet again.

During the five years of partnership, RemObjects Software has always been the sole technical contributor to the core Oxygene product, and having Oxygene “back to ourselves” really just means one thing: that we can, more aggressively and consistently, continue to drive the product on all three target platforms, according to the vision we have for it. And trust me, we have some amazing things planned for 2013 and 2014, with “Nougat”, our Mac and iOS support, only being the tip of the iceberg.

What does this mean for existing customers?

Worry not. We have every eventuality covered.

First of all, if you already bought Oxygene directly from us or one of our reseller (i.e. without an Embarcadero serial number), none of this will affect you at all, you’re already set.

If you’re an Oxygene user from the Embarcadero side of the fence, now more than ever, make sure you register your XE2.x or X3.x serial number with us. This way, we know about you and can take care of you moving forward.

Once you have registered your serial, you can take advantage of our special renewal price for Prism customers and renew to a full Oxygene package licensed directly from RemObjects Software, for only $349. Remember, this not only renews you for future updates to Oxygene for .NET (the product you have now), but it also gives you the Java/Android and Mac/iOS targets, as well!

If you have active software assurance (SA) with Embarcadero that covers Oxygene, that will of course be honored. Up until August (i.e. one year from when XE3 shipped), you will continue to receive the latest updates to Oxygene for .NET from Embarcadero. This will (assuming your SA is still active at the time) include the upcoming major 6.0 release, next month.

Once your current SA expires, renewing it will not include renewed access to Oxygene, but you can use the link above at any time to renew to the full Oxygene package from us. (Note that the current renewal price of $349 is a special offer and will increase slightly once “Nougat” ships next month.)

It’s probably unlikely that you’re buying RAD Studio XE4 “fresh” without already being an existing RAD Studio user, but if you do, i’m afraid you will not receive “Prism XE4″ as part of it. You (and every other Delphi user) can use our special cross-grade offer to purchase a full Oxygene package from us, at $399 (this is also a special offer, and the price will increase slightly once we ship 6.0 next month).

In Summary

As the old saying goes, The King is dead, long live the King! Embarcadero Prism is no more, starting next week, but Oxygene is going stronger than ever.

We, and i personally, are incredibly excited about Oxygene, and about the things we have planned thru-out the rest of the year and beyond. We can’t wait to walk down the road ahead with you.

yours,
marc hoffman
Chief Architect & Oxygene Team Lead
RemObjects Software

The whole thing was literally done and up on GitHub in about twenty minutes, start to finish (writing this blog post will probably take longer than writing the app ;), and i figured i’d give you a rundown of what it does, how it works and how i did it.

I started by going to developer.apple.com and setting up a new App ID with a Push Notification certificate. Any app using Push Notifications needs a unique, non-wildcard ID, so i could not just use one of my existing IDs and profiles.

After downloading the profile and the new Push Certificate, i exported it from Keychain Access as a .p12 file without password protection (to keep things simple).

(The .p12 file is the only piece missing from the WWDCNotify distro on GitHub. You must create your own to run the app, or else we’d get our streams crossed when more people run the app with the same certificate.)

Next, i created the server app. I wrote that in .NET, so i can use Mono to either run it locally on my Mac, or i move it to one of our Linux servers on EC2, if i wanted to.

I started with the RemObjects SDK for .NET new project wizard. The server is really simple, as it doesn’t define any of its new services, it just links in our open source Apple Push Provider (source on GitHub), which provides two pieces of core functionality needed for Push notifications on the server:

1. It provides the APSConnect class that encapsulates the protocol for submitting notifications to Apple’s servers.
2. It provides a ready-to-go RemObjects SDK Service that clients can call to register for notifications — along with all the infrastructure to manage the list of registered devices.

Nothing but these few lines of code are needed to set up the Push service:

var lCertificatePath := Path.ChangeExtension(typeOf(self).Assembly.Location, 'p12');
PushDeviceManager.DeviceStoreFile :=  Path.ChangeExtension(typeOf(self).Assembly.Location, 'devices');
PushDeviceManager.CertificateFile := lCertificatePath;
PushDeviceManager.APSConnect.ApsHost := 'gateway.sandbox.push.apple.com'; // for this app, we're staying in the sandbox
PushDeviceManager.RequireSession := false;

I tell the PushDeviceManager.RequireSession the path to the .p12 file (which i included in the project and set to be copied next to the .exe), the file to store the registered devices in (again, it goes next to the .exe to keep things simple), the URL of the Apple Push Server, and finally i tell it to not bother with requiring clients to authenticate.

And with that, the server is done and ready to let clients register for push notifications…

Of course there are no notifications being sent yet. To handle that, i created a quick static class that uses a timer that fires every five minutes. When that happens, it downloads the content of the website and compares it to the previous version:

var lNewWebsite: String;
using lClient: WebClient := new WebClient() do 
  lNewWebsite := lClient.DownloadString(URL);

if assigned(fLastWebsite) and (fLastWebsite ≠ lNewWebsite) then begin
  …

If that is the case, it will send a notification with message and sound to all registered clients:

for each d in PushDeviceManager.Devices.Values do
  PushDeviceManager.APSConnect.PushCombinedNotification(d.Token.ToArray, 'ALARM ALARM! The WWDC Website has changed', 0, 'default');

It’s that simple.

Because i have a mild case of OCD, i also made the server send a regular notification without sound (every few hours), to assure me that the service is still running. And on startup, it will also send a notification that the server has been (re)started — again really just to set me at ease that everything is working, when launching or re-deploying the server.

Ok, if you think “well, that was easy”, wait till we get to the client. I added a second project to the solution, this time an iOS app based on the Simple App template — which does nothing but show an empty view. (For completeness sake, i went into Interface builder and made the empty view show the Default.png image, instead of just a white screen.)

To communicate with the server, i imported the interface file for our Push Server by going to the RemObjects SDK|Import Service menu and choosing the RODL file from the Push project above (i could also have pointed it to the URL of the running server instead).

Literally all the code that drives the app is in the AppDelegate class:

In application:DidFinishLaunchingWithOptions:, we add one line of code:

application.registerForRemoteNotificationTypes(UIRemoteNotificationType.UIRemoteNotificationTypeAlert or
                                               UIRemoteNotificationType.UIRemoteNotificationTypeSound)

to let the OS know we are interested in notifications, and want alerts and sounds.We then implement two callback functions that will be called either if registration for push was successful, or if it failed (which will happen when running it in the simulator, for example). application:didRegisterForRemoteNotificationsWithDeviceToken: and application:didFailToRegisterForRemoteNotificationsWithError:.

When registration fails, we simply show an alert view with the error message.

The success case is more interesting:

method AppDelegate.application(application: UIKit.UIApplication) didRegisterForRemoteNotificationsWithDeviceToken(deviceToken: Foundation.NSData);
begin
  var p := new ApplePushProviderService_AsyncProxy withURL(new NSURL withString(URL));
  p.beginRegisterDevice(deviceToken, UIDevice.currentDevice.name) startWithBlock(method (aRequest: ROAsyncRequest) begin
      p.endRegisterDevice(aRequest);
      var lAlert := new UIAlertView withTitle('All set!') 
                         message('You are registered for Push Notifications!') 
                         &delegate(nil) 
                         cancelButtonTitle('Okay!') 
                         otherButtonTitles(nil);
      lAlert.show();
    end);
end;

Here we do an async call to the RegisterDevice function exposed by the server, passing the deviceToken we received (this is the token the server will hold on to and use to later send a message to our device). We pass a block that gets called back when the call was successful and — just for completeness — we show a message that everything went well when that happens.

And that’s it. I run the server with “mono WWDCNotify.exe”. Run the client app once to let it register, and then forget about it.

Cocoa always had the ability to “toll-free bridge” between Cocoa objects, such as NSString and their underlying non-object-oriented CoreFoundation equivalents, like CFStringRef. Before ARC, you could just cast back and forth between them as you pleased, but ARC made the rules a bit stricter, and Objective-C introduced new “bridge casts” to formally express these toll-free bridge casts in an ARC-safe manner. Oxygene also supports these casts, with the bridge<T>() compiler magic function.

Questions?

So how do bridge casts work, when do you need them, and what is the difference between the three distinct types? That are questions that i think a lot of people are confused about. I’ll admit i myself wasn’t quite sure what the differences and implications of “bridge” vs. “transfer” vs. “retain” were, until Carlo and i sat down the other day to really formalize how we would properly expose them in Oxygene (and thus had to understand them really well ;)).

As most Objective-C developers who use ARC will know, the answer to the middle question is the easiest. When do you need a bridge cast? Simple: every time you want to go from a Cocoa object to a CoreFoundation entity or back. You know this, because the compiler will tell you by refusing to compile code that was perfectly fine in pre-ARC, such as:

NSString *s = (NSString *)myCFString;

Instead, you now need to write:

NSString *s = (__bridge NSString *)myCFString;

Or do you? The answer is, it depends. As i mentioned before, there are three different types of bridge casts, and it is important to pick the right one (lest you will end up in the land of chasing down memory leaks and weird crashes, once again).

I say there are three types, but you can really think of them as two groups of casts.

“Regular” Bridge Cast

First, there’s what i like to think of as the “regular” bridge cast. In Objective-C that’s expressed with the __bridge keyword; in Oxygene, it’s the default when calling bridge<T> without a BridgeMode enum value (or with BridgeMode.Bridge, the default):

Objective-C

UIColor *u = [UIColor redColor];
CGColorRef c = [u CGColor]
id o = (__bridge id)c;
[u set]; // or something else that keeps "u" around.

Oxygene

var u := UIColor.redColor;
var c := u.CGColor
var o := bridge<id>(c);

You can think of this as making the original item (a CGColor) available “on the other side” (as featureless “id”, in this case, as CGColorRef is not toll-free bridged to a Cocoa class), without affecting the original.

The original ownership of the CGColor remains with the UIColor object it was obtained from. The cast object is merely a second view onto the same item, in a different form.

The “regular” bridge cast works both ways — going from a Cocoa to a Core Foundation, or the other way around.

Transfer/Retain Bridge Casts

The second type of casts are the transfer/retain bridge casts casts. I lump them together because they form two sides of the same coin. Different than the regular bridge cast, they do not work in both directions; instead, the transfer bridge cast can be used when going from CoreFoundation to Cocoa, and the retain bridge cast when going the opposite way, from Cocoa to CoreFoundation.

In Objective-C that’s expressed with the __bridge__transfer and __bridge_retained keywords; in Oxygene by calling bridge<T> with a BridgeMode.Transfer or BridgeMode.Retained value.

Why this distinction is necessary will become clear soon, but first let’s look at an example:

Objective-C

CFStringRef c = CFStringCreateWithCString(nil, 'hello', CFStringGetSystemEncoding());
NSString *s = (__bridge_transfer NSString)c;
c = nil;

Oxygene

var c := CFStringCreateWithCString(nil, 'hello', CFStringGetSystemEncoding());
var s := bridge<NSString>(c, BridgeMode.Transfer);
c := nil;

As the name implies, the transfer cast transfers the item, and its ownership, to the other side. After the cast from the CFStringRef to an NSString, the NSString (stored in “s”) is the only true owner of the underlying string. The original CFStringRef is no longer relevant, and as you see, we do not (must no) free it.

Essentially, the transfer cast says, “give me a Cocoa object, and then let’s forget the CoreFoundation thing ever existed”.

This is highly useful when writing more concise code. In the example above, we could have used a regular bridge cast, and simply called CFRelease(c) afterwards and everything would have been fine. But imagine the same example written as a single line of code:

Objective-C

NSString *s = (__bridge_transfer NSString)CFStringCreateWithCString(nil, 'hello', CFStringGetSystemEncoding());

Oxygene

var s := bridge<SString>(CFStringCreateWithCString(nil, 'hello', CFStringGetSystemEncoding()), BridgeMode.Transfer);

Here we have no reference to the original CFStringRef object, so the transfer cast is essential.

Conversely, you can imagine that using the transfer cast on the CGColor example above would be disastrous. The Original CGColorRef is owned by the UIColor we received it from; we’d have no right to transfer it and invalidate it underneath the UIColor’s feet. Things will crash, eventually. (In fact, a bug report with just this problem that we received from a tester of Oxygene was what promoted me to write this post ;)).

At this point, you might already begin to understand why transfer bridge casts can only work one way in an ARC language and why on the flip side the retain bridge casts is needed:

Objective-C

NSString *s = [NSString stringWithFormat:"hello, %@", name];
CFStringRef c = (__bridge_retained CFStringRef)s;
...
CFRelease(c);

Oxygene

var s := NSString.stringWithFormat('hello, %@', name);
var c := bridge<CFStringRef>(s, BridgeMode.Retained);
...
CFRelease(c);

When we used transfer bridge casts above, a true transfer happened; the CoreFoundation reference was no longer valid, and we did release it. Going the other way, we do not have this luxury: The original Cocoa object (a string in this case) is managed by ARC, and there is no way to not release it. If a true transfer bridge cast were allowed, ARC would go ahead and over-release an “invalid” object. And that cannot happen.

Instead, the retained bridge cast does the next best thing. It gives us back a CoreFoundation entity we fully own (and have to release), and it leaves the Cocoa object untouched.

You can think of the retain bridge cast as “just like the transfer, but leaving the source object for ARC to deal with”.

When to Use What?

The answer to this question will not always be clear-cut, but a good rule of thumb is to use the regular bridge cast — i.e. __bridge or bridge<T>() w/o mode — when you do not own the original item and/or are merely “borrowing” it to be used on the other side. Use the transfer/retain bridge cast when you do own the original object and want to take ownership of it “on the other side”.

So How Does this Work Under the Hood?

To be honest, you probably don’t really want to know, or at least not think about it, because what the bridge casts do under the hood can be really confusing how you think of them on the higher level.

Let’s start with the transfer bridge cast. It essentially does “nothing”, just as the regular cast would have done before ARC; it converts the pointer type and that’s it, and it does not affect the retain count of the object at all.

Because of how ARC works under the hood, it assumes ownership (or a +1 retain count, if you will) of the Cocoa object pointer and this affectively acts as if the original CoreFoundation object had been released (i.e. gotten a -1 on its retain count). The actual retain count of the item has not changed, but ARC now has staked claim on it.

The regular bridge cast is essentially the same as the transfer, except it does an extra retain on the resulting object when going from Core Foundation to Cocoa. This way, ARC can deal with the object (and eventually release it again). But the underlying CoreFoundation reference is unaffected and keeps its own claim on the entity. When going from Cocoa to CoreFoundation, it does nothing — because ARC is not involved in handling the life cycle of CF objects, it can just pass the original object off as an unowned entity.

Finally, the retain cast works much like the regular bridge, but does an additional retain on the item, before the cast. This way, the original object reference remains retained, and the resulting CF entity is owned (i.e. needs to be freed) as well.

The thing to keep in mind is that there’s a single retain/reference count for each entity. It’s really just a sleight of hand on the compiler’s side how the bridge casts “move” the ownership around between the Cocoa and CoreFoundation references.

But as i said, you probably want to forget about these implementation details, and just think of these bridge casts in the logical terms described above ;).

Summary

I hope you found this article useful and that it helped to provide some insight into the different bridge cast types on the Cocoa platform. Let me know what you think!

Now it is even easier for you to give the possibilities of Data Abstract for Java a try. Just install it on your device and try to fetch some data using SQL from our externally available PCTrade Sample Server. The sample is preconfigured to talk to http://remobjects.com:8099/bin, but you can change it on the Settings screen and direct the application to any locally accessible DA Sample Server. Make sure to also try the other available settings.

Other details about the usage and the concepts covered can be found at the sample’s wiki page.

More samples will be available in the near future. Meanwhile, please note that you can always download and install Data Abstract for Java and compile and run any sample manually. These samples can give you a good starting point in developing your own application with the Data Abstract for Java framework, be it for Android or any other Java-powered target platform.

P.S. We have published two more Android samples lately.

Filters Sample shows how to use Dynamic Where and Dynamic Select features for obtaining data from the Data Abstract servers.
wiki page, Play link

Simple Sample shows basic Data Abstract functionality, including loading, changing and updating of data from and back to the Data Abstract servers.
wiki page, Play link

Install, try them ant tell us what you think!

Frankly, i’m not surprised about these issues, because from where i stand, Core Data in iCloud uses a fundamentally wrong approach that can only fail. Let’s see how that is so.

Do you remember when Steve Jobs took the stage at WWDC a couple of years back and introduced iCloud? It was going to be better than all of Apple’s previous cloud services, and to explain the reason why, Steve used one catch phrase: “The truth is in the cloud”. Developers rejoiced and gave a standing-o — and rightfully, because Steve was correct.

For a cloud service to work reliably, the “truth” — that is, the authoritative representation of what your data is — needs to be in one central place. The cloud.

And Steve was not lying to us. That claim he made is true for most of iCloud, and if we’re honest, iCloud is working pretty well for most of the services it provides. Cloud-based documents work great. Cloud-based settings (the Key-Value-Store) work great. All the non-developer features of iCloud (Calendar/Contacts, Backups, heck, even things like iTunes Match) work pretty well. The only thing that is causing developers (and by extension, users) headaches is “Core Data in iCloud”. Why is that?

It’s because Core Data in iCloud violates the core promise Steve made about why iCloud is better. Core Data’s truth is not in the cloud. Instead, Core Data merely uses iCloud as a dumb conduit to sync data back and forth between the different devices a user runs your app on — and leaves the onus for sorting out the sync to the individual devices.

And as we all know, “syncing is hard”. And worse, syncing is impossible, if the app doing the syncing has no control over the data flow (for example when the user disables iCloud for a while), and the developer has no way to debug what is going on.

If 15+ years of working with networked data and disconnected clients has taught me anything, it is that this is an unsalvagable situation. In order to have data in your apps and reliably reproduce and “sync” it between multiple devices, you need to take control of that data, and have a single truth source — ideally in the cloud.

It just so happens that here at RemObjects Software, we have spent the past 10 years thinking about these problems, and have developed a technology and libraries around it that solve them.

This blog post is less about selling you on Data Abstract (although i of course hope that you will have a look at it), and more about showing how taking control and hosting your own data will solve your problem in ways that Core Data in iCloud can not — and give your app additional capabilities, to boot. So i will look at this from the perspective of using Data Abstract, our product, but many of the ideas covered will be applicable just as well, should you decide to “roll your own” or use a different infrastructure.

What is Data Abstract?

Data Abstract is a combination of a client library that you link into your iOS or Mac application (it is also available for other platforms), and server-side infrastructure in form of our free Relativity Server.

One of the “downsides” of giving up Core Data/iCloud is that you will need to look at hosting your own data. That seems like a daunting task, but is really not as difficult, or as costly as it might seem. And in fact, you will come to see it as an upside in the long run.

To get started, in most cases a tiny and cheap Amazon EC2 server instance will do the job — we’re talking monthly costs of around $20 or so. This will be enough to handle the initial load of most apps — and of course, if your app sells really well, the extra costs for upgrading the specs, or “scaling out” to more than one server will be peanuts to you, anyways ;).

Setting up the server is really simple. Most Linux servers you can rent or host, including EC2, already come with a database such as mySQL or PostgreSQL (we use the latter a lot, ourselves). All you need to do is install our Relativity Server, and you’re set. You can of course also use Azure, or other more traditional hosting solutions (and we are working on providing a ready-to-use EC2 image that will let you get set up with this even quicker, soon).

You can then design your database as you see fit, and Relativity Server lets you expose the data to your client applications — you decide what tables get exposed and who can access what, and you can write custom logic to control and influence data access and updates via JavaScript. The Relativity Server Explorer makes this easy and visual.

On the client side, Data Abstract is an easy-to-use static library that you can link into your application, and it will handle all the data access for you. The library is built on modern Cocoa principles, for example it uses GCD blocks to handle network access in the background, making it easy to keep your app responsive. Also, it is designed from the ground up for offline data, meaning you do not need to spend a lot of effort worrying about what happens when your user loses network connection — they can work with data while on a plane, and sync back up later when they get back online.

We have a lot of development topics around DA and Relativity server covered in our documentation Wiki, a good starting point is this page: Developing Database Applications for Mac and iOS.

In addition to providing all that Core Data/iCloud promises (but reliably), hosting your own data also provides additional benefits that cannot be achieved (by design) with iCloud data, even if it were working perfectly otherwise:

• In addition to each user having their own private data, your app can share data between users, where applicable — be it between individual users, or publicly with all users.
• You can build apps for other platforms, including Android, Windows, or Mac apps not sold in the Mac App Store, that share the same data. (Data Abstract has dedicated libraries for creating native apps for both Android and Windows, as well.)
• You can build a web front-end for users to view their data, either via server technologies such as ASP.NET, or client technologies such as a pure JavaScript based browser client. (Again, Data Abstract provides libraries for both, and our library for JavaScript is even completely free.)
• Most importantly, though, you as the app developer are in full control of the data. If one of your users calls you and says that something is wrong with their data, you’ll know exactly where to look.

Summary

I hope you found this article interesting, and that is has given you a fresh take on the intricacies of adding data “syncing” to your app — on iOS and elsewhere.

The key point i hope you will take a way from this is that Core Data in iCloud, being essentially a client-to-client sync mechanism, just like MobileMe and others before it, is fundamentally flawed, so that the myriad of problems many developers are seeing are hardly surprising. And that the solution to that is taking control of your own data, and hosting it with a single “truth in the cloud”.

I’d be lying if i said i didn’t hope you would consider using Data Abstract as your solution for this problem. We’re a small team of developers dedicated to this problem, and i believe we have a great and unique solution to it that provides a lot of benefit and can save you a lot of time and resources. Data Abstract sells as developer license, with no deployment costs or royalties.

Let us know what you think!

Whatever solution you choose, we wish you best of luck with your data-driven apps, and are looking forward to what you’ll produce!

Yours,
marc hoffman

Chief Architect,
RemObjects Software

In addition to the native development tool provided by the platform vendor, there are 3rd party development tools providers (such as ourselves) with their own solutions. The 3rd party tools typically either focus on providing a better solution for the specific platform, or sacrifice native platform support with the objective of cross-platform simplicity. There is no reason to sacrifice platform support, as you will see in these top 10 reasons to program to platform native APIs.

Platform Native APIs are Great

Those who programmed MS-DOS applications or the early Windows API no doubt remember what a pain those APIs (or lack of) were to work with. Back then it was great to have a good abstraction to make the platform easier to work with. Today’s platform native APIs encompass all the productivity enhancements that are found in the the best abstractions. Typically, the productivity enhancements that come from additional abstractions are only in the form of familiarity and developer’s resistance to learning a new API and framework. You know things are getting carried away when there is a Java abstraction for developing Windows Phone 8 applications and a .NET abstraction for building Android applications.

The Law of Leaky Abstractions

“All non-trivial abstractions, to some degree, are leaky.” If your tool forces you to use some non-trivial abstraction on top of a platform’s API, at some point it will leak – there will be something that the abstraction cannot do, or somewhere the abstraction behaves differently from platform to platform. If you are serious about developing for any platform, you need to understand the platform’s native API. The more non-trivial the abstraction, the less of the platform it can abstract successfully and the more likely you will need to move to the platform native API. If you are going to need to learn the platform API anyway, you might as well start there. No need to learn both the abstraction and the platform API – that is twice as much work.

Native Documentation

Documentation is a lot of work. Good documentation is even more work. On each platform, the platform vendor provides the documentation of the platform along with all the best practices and examples. For each additional level of abstraction that requires another level of documentation to consult. Chances are that the documentation will eventually refer you to the platform API documentation. Wouldn’t it be nice to just start at the ultimate authority and not have to wade through incomplete and outdated layers of documentation?

No Bloatware

If your abstraction adds additional graphic libraries or run-times, your application suffers with bloat. These abstractions replace the functionality already present in the platfrom and make your app bigger, slower to start-up and less responsive at runtime. Some of these add-ons are worthwhile, but if you need to double (or more) the size of your app just to write “hello world”, then you are probably using the wrong solution.

Rapid Release Cycle

When a platform vendor releases a new API you want to be able to take advantage of those features right away. It may surface new hardware features, or just introduce better ways of doing things. If you are forced to use an abstraction, you need to wait for the 3rd party to update their abstraction. This may be fairly quick, or you may have to wait for their release cycle, which, depending on where they are in development, could mean the release after the next. No matter how fast a vendor has been in the past at updating their abstraction library, a point will come where they are not updated when you need them.

Support for Platform Deviations

If a hardware vendor comes out with their own SDK extensions or variations on a platform, they will provide their support at the level of the platform API. If you are stuck behind an abstraction, you will not have access. The openness of Android is a great example with extensions like Google TV, Epsion Moverio, Ouya, and Google Glass. If you are interested in cutting edge platforms like these, you need a development tool that doesn’t lock you behind an abstraction.

Native User Experience

Each platform has a typical user experience. This comes from the native platform user interface widgets and the way they behave. It also comes from design guidelines provided in the platform documentation. If you are using an abstraction for your user interface, even one that tries to look and act like the native one, it will get in the way of this native user experience. When it comes to user experience, close isn’t close enough. Using the native platform user interface controls is the only way to give your users the experience they expect.

Less Points of Failure

Everything always works great in the demonstrations, but the more layers of interoperability and wrappers required to make your application run, the more points of failure. When you develop for the platform API directly, you are not handicapping yourself with black boxes or other points of failure for your app. The first time you find yourself debugging into that abstraction layer, you will really wonder if it was worthwhile to shackle yourself with it.

Maximum Developer Flexibility

Platform APIs are huge. In the process of creating a wrapper, choices are made to simplify or eliminate options. These simplifications and eliminations result in less flexibility for the developer. Tying a project to a subset of the features of the platform reduces what you can do with your project. Don’t tie your hands!

3rd Party Support

The majority of 3rd party components and books are going to support the platform’s API. The further you are from that, the less support you are going to have. Want to use a cool 3rd party custom control? Hope they port it to your favorite framework. And what are the odds of a book about the specific features of the platform you want to explore covering it via your specific pair of shackles?

Summary

Cross-platform abstractions are only going to get in your way and tie your hands. Any benefit in getting you up to speed faster will be lost in the long term when you hit the rough edges of the abstraction. That is the reason Oxygene is designed to use the platform native APIs directly. There is no forced or complex abstraction to get in your way of using the platform and making the best app possible.

I’m not a big gamer; i don’t find myself playing games much, and i have certainly never written one before, so this was a great opportunity to explore something new.

For those of you not familiar with it, Game Center is a technology Apple ships in iOS (and now also Mac OS X) that allows for games to interact across the network to create multi-player games, and to keep track of achievements. Game Center is not about graphics, or game UI, or anything of the sort (there’s other frameworks for that), it’s only for bringing players together.

I decided to create a simple turn-by-turn game, that is, a game where multiple players (in this case two) can interact, but only one player is active at a given time. Once a player has made their move, it’s the next player’s turn. To keep things simple, i picked a game that everybody knows and that is dead simple to implement, game playing wise: Tic Tac Toe. This way, having to explain the game itself won’t get in the way of the sample code.

To start with, i had to dig myself into the Game Center documentation and i watched a couple of videos on Turn-by-Turn gaming from WWDC 2011 (sessions i didn’t attend at the time). As it turns out, the API for interacting with Game Center for such a game is surprisingly easy and straightforward, and i was up and coding in no time.

Before we get started looking at the code, let’s look at the prerequisites:

• Here’s the amount of effort anyone from the Oxygene team had spent on thinking about or working on making GameKit (the framework for interacting with Game Center) available to Nougat, before i started this endeavor: 0. Nada. Nil.

• Here’s the amount of legwork i had to do before i could work with the GameKit APIs, just like every other Cocoa developer would: i added a reference to GameKit to my project. Done.

That’s it. No begging someone to translate header files, or waiting for someone to create a crappy abstraction wrapper class. Add a reference, and use the APIs as Apple intended them — that’s the way development should be.

The Code

Let’s dive into the code.

First of all, the full code of Tic-Tac-Toe is included in the latest Nougat beta, and it’s also available in my Github account for anyone to explore.

There’s really three separate parts that are of interest as a sample project in this app:

1. The GameKit integration
2. The game board, implemented as a custom UIControl
3. The computer player algorithm, generously provided by my good friend and long-time Oxygene user, Jeremy Knowles.

Let’s look at GameKit first.

Working with GameKit

There’s four main classes or concepts that you will work with for GameKit.

The first is the local player, a singleton object that can be obtained via a call to GKLocalPlayer.localPlayer. This objects provides the game with information about the local player — most importantly their ID, and whether the local player is in fact registered and authenticated with Game Center or not. If the player is not set up for Game Center, Tic Tac Toe will simply disable the appropriate UI and just allow local vs. computer game play (although it would be possibly for a game to provide a signup UI, if so desired).

Next is the GKTurnBasedMatchmakerViewController, which provides access to the standard GameCenter UI. It gives the user access to any and all games they might already have going on, as well as the chance to start a new game. In Tic-Tac-Toe, i make this UI available via a button in the navigation bar, and all that’s needed to show the view is code like the following:

var request := new GKMatchRequest;
request.minPlayers := 2;
request.maxPlayers := 2;
 
var mmvc := new GKTurnBasedMatchmakerViewController withMatchRequest(request);
mmvc.turnBasedMatchmakerDelegate := self;
mmvc.showExistingMatches := true;
presentViewController(mmvc) animated(true) completion(nil);

This code brings up the Game Center UI, with the list of games (if any) or straight with the “Start New Game” (if not). Via the GKMatchRequest, we force the number of players to exactly two. (Game Center itself allows games for up to 16 players):

The way Game Center works for starting new games is that it lets you either invite a known friend who also plays the game or — much more interestingly — auto-match you with another random player. One thing that’s cool is that after starting a game, it will always be your turn — you will either be thrown into another game that was started earlier by a different user, or you will get to start a fresh game, depending on what games are currently live and waiting for players. If you start a fresh game, you get to make your first move, and then and only then does Game Center go out and try to find someone for you to play with.

Going back to the code level, what we are looking out for is a callback on the turnBasedMatchmakerDelegate that we assigned above. Our root view controller class implements some 4 methods from the IGKTurnBasedMatchmakerViewControllerDelegate interface, and the match-maker view controller will call us back on these when interesting things happen. This is a very common pattern in Cocoa, and is how the platform handles “events”.

In particular, the callback we care about for starting a new game is:

method turnBasedMatchmakerViewController(aViewController: GKTurnBasedMatchmakerViewController) 
       didFindMatch(aMatch: GKTurnBasedMatch);

This method actually gets called any time the user picks a game in the Game Center UI — whether they are starting a new game, or selecting an existing game. This is neat, because it means we can leave all the game management to GameKit, and don’t need to keep track of ongoing games ourselves.

This callback receives the third important class, a GKTurnBasedMatch. “All” we need to do when this method is called is load the passed match as the active game. In the Tic-Tac-Toe app, we do this by calling our own loadCurrentMatch() method, which does all the heavy lifting.

Every match contains a binary blob in the matchData property that describes the current game state. The content of this binary blob is entirely up to our game, but we can use it to store up to 4KB of data, and this data will automatically be passed between all the participants as they take their turns. In turn, our Game will read the data, let the active player make their move, and then store the updated game state, as we will see in a few moments.

Loading a Game

Loading a game is done with two method calls, first, a a small helper function loads the binary data into an NSDictionary, and then we ask the board to load its game state from that dictionary (the idea being that in a future version, our game might store additional info in the dictionary that the board does not care about — that’s why i decoupled the data the Board class reads/writes from the actual binary format).

var lDictionary := dictionaryFromData(fCurrentMatch.matchData);
fBoard.loadFromNSDictionary(lDictionary, …);

The same happens in reverse when we later save the updated game state. Of course, when a new game is first started, there will be no data present (GameKit doesn’t know anything about how our game data is structured, after all), so our code will need to be prepared to find an empty NSData object in matchData.

The second part, in addition to loading the board data, is determining the active player (if any) and enabling the game play. Each GKTurnBasedMatch has a currentParticipant property of type GKTurnBasedParticipant which links to the current player (it also has a participants array that contains all (two) players). We can compare this participant’s playerID to that of the local player.

If they match, it’s the local player’s turn, so we display “your turn”, and enable the board. If they don’t match, it’s either the remote players’ turn (if currentParticipant is assigned), or the game has finished. In either case, we show the proper status message, and leave the board disabled.

Playing a Turn

If it was the local player’s turn and we enabled the board, we’re done for now, and await the player to make a move. This all happens inside the Board class, which will call us back via the board() playerDidSelectGridIndex() method, once the player made their move.

What we need to do then is determine the game status (the player might have made a winning move, for example), re-encode the game status, and pass control back to game center.

There are three scenarios we need to cover:

1. The player has won by managing to place 3 “X” markers in a row.
2. The board has been filled (and the game just tied).
3. Any other case — the game is still on.

In the two game-over scenarios, we set the appropriate status (Won/Lost/Tied) on each of the game participants, and then call endMatchInTurnWithMatchData() completionHandler() to tell Game Center that the match has ended as part of the player taking his turn.

In the other case, we call endTurnWithNextParticipant() matchData() completionHandler() to let Game Center know that the local player is done, and game play can move to the next player.

In either case, we will pass the updated information on what our game board looks like now, via the matchData parameter.

It is worth noting that it’s up to our game to tell Game Center “who’s next”. In our case, that decision is trivial (it’s the player that’s not the local player), but Game Center allows for turns to be passed in arbitrary ways, depending on your game’s needs — it doesn’t always have to go around the (virtual) table.

Once we called either of the above fund methods, it’s no longer our turn, and all we can do is wait for the remote player to make a move.

Handing Remote Turns

Of course, eventually the remote player will make their move, and GameKit provides a second delegate interface for this case, IGKTurnBasedEventHandlerDelegate, which we have hooked up to the GKTurnBasedEventHandler.sharedTurnBasedEventHandler singleton.

What will happen once the remote player moved is that Game Center will show a notification banner to the user, saying something along the lines of “It’s Your Turn”, and play that annoying fanfare sound. When and only when the user taps that notification, will we receive a call to the

method handleTurnEventForMatch(aMatch: GKTurnBasedMatch) 
       didBecomeActive(didBecomeActive: Boolean);

method to let our application know that something happened. This is nice, because it saves us from worrying about showing any UI to the user to ask if they, say, want to switch from the game they are currently looking at to the one that has received a response. When we get the callback, we already know that the user has decided to view the game in question.

So all we really need to do is the same as we did in … didFindMatch() above: load the passed match and enable the board, if appropriate.

House Keeping

This basically takes care of all the Game Center interaction needed for our simple game. There’s a few more minor items that i won’t go into detail for this post; for example, there’s a callback you will want to handle to quit games if the user selects to delete them in the Game Center UI. There also are APIs for providing a custom UI for the list of games, instead of relying on the standard UI provided by Game Center (all Tic-Tac-Toe does with this is adjust the Game Center button to either read “Games” or “Start”, depending on whether there are any games ongoing or not).

In Tic-Tac-Toe, all the GameKit interaction is located in RootViewController.pas, which is only ~500 lines of code total, so it should give you a good overview and starting point for your own game.

Caveats

There are a couple of caveats you might want to be aware of when working with Game Center games; these had me stumped for a short while, so hopefully pointing them out here will help save you frustration:

• In order for Game Center to work, your app needs to be registered on iTunes Connect with the appropriate app ID. Even for the simulator. This is counter-intuitive if you are used to App Store development, because normally you don’t have to go to iTunes Connect to register your app until you’re (almost) ready to go and submit it. For Game Center, you need to register it first. If you don’t, GKTurnBasedMatchmakerViewController will just come up looking all empty and dysfunctional.

• As best as i can tell, you must specify “gamekit” in the UIRequiredDeviceCapabilities section of your Info.plist file for things to work properly.

• Finally, and most importantly, notifications do not work in the Simulator. If you worked with Push Notifications before, this might not come as much of a surprise, but realize that callbacks such as handleTurnEventForMatch() … will never, ever be called on the Simulator — which seriously will impact how you test game interaction. (In essence, i found the only way to work around this was to manually invoke the GKTurnBasedMatchmakerViewController and re-select the active game to trigger the app to reload the game data and detect the changed game state.)

The Game Board

The second piece of interest in the game is the Board class, which implements all the UI of the game as a really simply UIControl descendant.

The implementation is fairly straight-forward; the class maintains a 3×3 array to keep track of which player has claimed a particular spot on the game board, and in which move (by keeping track of the move number, the game can show different versions of their “X” and “O” markers, making the board look more dynamic).

The begin/continue/endTrackingWithTouch() withEvent() methods are overridden to keep track of — you guessed it — the user’s finger, and they use animations to fade the user’s game piece in and out, and to move it to the next appropriate spot, as the finger moves. (You’ll notice that while the user can move their finger all over the board, the game piece will always “snap” to a fixed position in the closest matching grid spot with a smooth animation.)

All the game pieces (the grid, the “X” and “O” game pieces, etc.) are pre-created images, and the game pieces come in 5 versions (since 5 is the maximum number of moves any one player can make).

The entire Board class is really straightforward and there isn’t much worth covering here that won’t be clear from looking at the code. Worth pointing out is the makeComputerMove method, which invokes Jeremy’s mean ComputerPlayer class, which is used when not playing in Game Center mode.

Summary

I think that’s it (and it’s probably enough ;). Make sure to check out the code on GitHub, and let me know what you think!

Oh, and: even though the code is written in Oxygene, as are the code snippets here, i hope the general description of how to work with GameKit will also be useful to “regular” Cocoa developers using Objective-C. Another nice thing about Oxygene working directly against the standard Cocoa APIs without any abstractions!

The advantage of this approach is that it makes the client responsive for input validation, and simplifies the degree of coupling between the client and server. The disadvantage is that if a different client connects to the database, the business logic is no longer enforced. This compromises the integrity of the database. There are other disadvantages to client server development – to learn more, read the white paper on “Why Multi-Tier”.

With the introduction of Multi-Tier database application development, the business logic moved to a Middle-Tier.

This has the immediate advantage of keeping the database secure no mater which client connects, while also simplifying client development. The disadvantage is that the client has to make a round trip to the server to validate user input – a major hit in the user experience department.

What I’ve seen some developers do is duplicate the input validation business logic from the middle-tier into the client. This speeds up input validation, but increases the complexity of client development, and requires that any business logic updates be made in two places – duplication of code is rarely the right answer.

Thankfully Data Abstract has a solution for this thanks to the new Business Rule Scripting support. Not only does it allow you to easily define your server side business logic in JavaScript, but also, select scripts are shared from the server to the client for fast and convenient validation and the best possible user experience.

This has the advantage of running the validation logic twice – once on the client for fast response, and then again on the middle-tier to protect the database. This is the best of both worlds – you keep your database secure and your client application responsive with no duplication of effort or code to keep synchronized. Data Abstract takes care of all that for you.

Additionally, Data Abstract’s schema technology keeps the client completely decoupled from the database. This keeps the database easier to maintain, and allows your application to easily migrate to a new database when your project requires it.

Both schemas and business rules scripting are supported in all editions of Data Abstract: .NET, Java, Delphi, Xcode and JavaScript. Learn more about Business Rules Scripting on RemObjects TV.

While Oxygene “Nougat” can of course use any such controls directly and without having to convert or wrap them, i thought it would be fun to try and port the code over to Nougat and see what it looks like (and what kind, if any, challenges would be involved).

We don’t have Oxidizer support for Objective-C yet, so i did this manually, but it was still a very straight-forward process, and below are a few notes:

• It turns out the new “Auto-Fix” for = vs. := assignments that we are shipping in the February release (which RTMs today) is a huge time saver. Just leave all the “=” in place, and the compiler will fix them for you when you hit build. This is new since i last converted code a few weeks back, and a much appreciated improvement.

• There’s really only two “repetitive” tasks i found myself doing a lot to convert Obj-C to pascal: (a) changing Objective-C style “[]” method calls to use regular Oxygene “.” or “:” operators and (b) replacing type names with “var” in local variable declarations, such as CGpoint centerPoint = … to simply var centerPoint….

• There were a couple of C macros used in the original code, which translated nicely into inline methods — a new feature in the Oxygene language for version 6.0.

All in all, i spent maybe 30 minutes last night converting and then tweaking/cleaning the code, and then the control and surrounding sample app was working perfectly (i also found a couple of new compiler bugs — remember Nougat is still beta — which always makes Carlo happy. When i woke up this morning, they were already fixed ;).

If you’re at all interested in creating your own controls for iOS (whether in Nougat or in Objective-C), i recommend to check out Yari D’areglia’s post. His original code can be found on GitHub, as can be my ported version.