You are browsing the archive for Visual Studio.

Avatar of Scotty

by Scotty

Setting Up For Android Development with Oxygene

January 9, 2014 in Android, Cooper, Elements, Uncategorized, Visual Studio

The purpose of this article is to help you set up Oxygene ready to develop Android applications. It assumes you have already installed Oxygene, but will walk you through installing the Java and Android SDKs, as well as setting up a virtual Android device and configuring your physical device for development. If you have already been developing for Android using another platform or have already set these things up independently, you do not need to read this article.

Android is an operating system for devices such as mobile telephones and tablet computers developed by the Open Handset Alliance led by Google. Application development is focused on targeting the specialized Dalvik Virtual Machine (VM), which is a mobile-optimized VM similar to the Java VM. Oxygene ships with templates for creating Android projects, and produces both native Java JAR files and the Android APK file necessary for deployment to an Android device.

The Pre-Flight Check

Each time you create an Android project with Oxygene, it will do a ‘pre-flight check’ to ensure that it can locate the things it needs, notably the JDK and the Android SDK.

Java Pre-Flight Check

If you’ve installed them into custom locations and it fails to find them, this gives you an opportunity to specify the installation folders by selecting the “Manually Specify The JDK Path” link from the dialog.

Java SDK Paths

Java SDK

Oxygene requires version 6.0 or later of the Java Development Kit (JDK) to be installed. For Windows, we recommend installing the “x86″/”i586″ release of version 7 JDK.

If you have not yet installed the JDK, you can download it from here.

Installing the JDK simply involves downloading the installer and running it, accepting all the defaults.

Install JDK

Once the JDK is installed, click Retest on the Pre-Flight Check dialog. If all has gone well, the dialog should change to report that the Android SDK is missing.

Android SDK

To create Android applications, Oxygene requires the Android SDK to be installed, in addition to the JDK.

If the JDK is installed, but not the Android SDK, the Oxygene pre-flight check will report this.

Android Pre-Flight Check

Download The Android SDK

The Android SDK can be downloaded here.

For Windows, we recommend using the .exe installer available under the “SDK Tools Only” section that is displayed when you expand the “Download for Other Platforms” area of the SDK download page , as it will automatically register the Android SDK with the system so that Oxygene can find it.

Android SDK Download

NOTE: If you download the .zip version of the SDK and manually extract it, you will need to manually configure the path to the Android SDK in the IDE options, as described further down on this page.

NOTE: If the Android SDK installer complains that the JDK cannot be found, that may be because you have the x64 version of the JDK installed (see above). Simply install the x86 (i.e. 32-bit) as well to solve this problem.

Once you have downloaded the Android SDK Installer, run it and accept all the defaults.

Android SDK Installer

After installing the Android SDK, setup will automatically offer to launch the Android SDK Manager. Leave this checked.

Android SDK Installer Finished

The SDK Manager

In the SDK Manager, check to install the “Android SDK Platform-tools” and at least one API version (usually the newest) and click “Install Packages” to install.

Android SDK Manager

In the subsequent dialog you will need to accept any licenses that apply and press “Install” again.

Android SDK Manager License

You should periodically run the SDK Manager to check for any updates to the tools and platforms.

Android Virtual Devices

When the tools and platforms are all installed, you might want to create an Android emulator, also known as an Android Virtual Device or AVD. This will allow you to test your application, in case you don’t have an actual device (or don’t want to use your device for development).

AVD’s are created from the Android Virtual Device Manager, which is accessible from either the SDK Manager by choosing Tools – Manage AVDs or by starting the AVD Manager program directly or from the Oxygene Visual Studio tool bar.

Launch AVD Manager From Visual Studio

The AVD Manager

The first time you launch the AVD Manager there will be no configured AVD’s.

Android Virtual Device Manager

Create an AVD

To create a new AVD, click the “New” button. You will need to give the emulator a name. The AVD manager is pretty strict about what characters you can use in an AVD name, but will warn you when you use invalid characters.

Define a Device

The quickest way to set up an AVD is to emulate an actual device the DVD Manager already knows about. If you select the Device drop down, it will offer you a number of different Google devices it can emulate along with a set of generic devices.

AVD Device Selection

If one of these predefined devices match the type of device you are targeting, then simply select it from the list.

If none of the devices in the list match the device you wish to target, you can set up all the fields in the AVD manager manually. For a full list of settings check out the AVD Hardware Options Documentation.

Select an API

You will also need to select the API level for the Target field. You can choose any installed API level, for example Android 4.4 – API Level 19.

AVD Target Selection

Device Memory

When you choose a predefined device it will set the RAM setting for the AVD to match the actual device. In practice, this number may be too high to properly emulate and you could get a warning.

AVD Memory Warning

In this case, you will probably need to adjust the RAM setting to something more appropriate. (What’s appropriate will depend on the amount of memory in your development machine.)

Save The Device

Once the AVD is defined, click OK to save it. You will be shown a dialog confirming all the settings that will be used to create the AVD.

Save Setting Dialog

On clicking OK, the new AVD should now appear in the list of available AVD’s. If the AVD seems to be fully configured correctly, it will have a tick next to it in the list.

AVD in List

Test The Device

Once you have created an AVD, you can run it by selecting it in the list and clicking the “Start” button.

You will be presented with some launch options where you can simply click OK unless you need to change something.

AVD Launch Options

The AVD will then begin to start.

AVD Start Progress

After a few seconds, a blank emulator screen will appear. From this point, depending on the spec of your development machine, it could take several minutes for your device to appear in the emulator.

AVD In The Emualtor

Testing Your AVD Setup

Now you are ready to test your setup. Leave the device running. From within Oxygene, start a new Android Application Project.

New Android Project

This will create a very simple Android Template Application. Click the “Start” button on the Visual Studio tool bar and Oxygene will build your project and deploy it to the emulator where you should be able to see it running.

New Android Project Running In Emulator

Setting Up An Actual Device

AVD’s are great for testing your application on devices you don’t own. If you do however own a device, you can test your application right on the device itself. In many ways this is preferable to using an AVD, as you get to see exactly how it will run and perform.

Enable USB debugging on your device

Before you can debug an Android application on your device, you need to enable it for USB debugging.
On Android 4.0 and newer, you need to go into Developer Options and turn it on.

NOTE: On Android 4.2 and newer, Developer options are hidden by default. To make them available, go to Settings > About phone or Settings > About Tablet and tap Build Number seven times.

Once turned on (if necessary) you can find Developer options in Settings > Developer options.

Android 4.4 Developer Options

If your device is running Android 3.2 or older, you can find the Developer options under Settings > Applications > Development.

Install USB Drivers For the Device

In order to connect to an Android device to test your applications, you need to install the appropriate USB driver. This page on the Android Developers website provides links to the web sites for several original equipment manufacturers (OEMs), where you can download the appropriate USB driver for your device. However, this list is not exhaustive for all available Android-powered devices. The page also gives information on how to install the driver once you have it.

Running Your App On The Device

Once the USB driver is installed for your device, make sure the device is connected to your machine. From Oxygene you can then choose to debug your application on your device by selecting your device from the Crossbox area of the Visual Studio tool bar.

Select Android Device

The first time you run your application from within Oxygene on your device, a dialog will appear asking for permission.

You Are Ready To Go

That’s it. You are now set up and ready to begin developing Android applications using Oxygene.

Good Luck!

Avatar of Anton

by Anton

Code Deodorant

October 28, 2013 in .NET, Elements, Tools, Visual Studio

We all write smelly code from time to time. Reasons are different, from ‘I’ll rewrite this code later, I just need this feature working now somehow’ to ‘Deadline is coming and this pesky bug is still not fixed’ or some mistake from a junior developer, yet the result is always the same. Every large codebase has lines of code that smell and stink. Of course there is an ideal codebase repository somewhere that does not have a single line of dirty code, or odd reinvent-the-wheel solutions, or patterns misuse etc… But, I’m afraid, that is along the lines of a flying unicorn. In the real world, we sometimes have to sacrifice code purity to deadlines or other reasons. In this case the main goal is to keep the unclean code and the technical debt caused by it manageable. Not a simple task, when the project has more than 55k lines of code, like ROFX/.NET (i.e. Data Abstract, RemObjects SDK, Internet Pack and Script for .NET) does.

So we need a tool that analyzes our source code and helps to pinpoint code that is potentially dirty. Such tools are called Static Code Analyzers. There are several of them available for .NET and I’d like to highlight the one I like best. This particular tool is not tied to C# or VB.NET and works perfectly with Oxygene code. It also provides Visual Studio integration (including the upcoming VS 2013), and it can also be run on a build machine as a part of the build process. This awesome tool is called NDepend (http://www.ndepend.com/).

In the following, we will create a simple application and apply NDepend to it. We’ll use Oxygene, as I need to show you how to avoid some sharp edges. While C# support in NDepend is near perfect, there are some (minor) nuisances that need to be avoided for Oxygene projects.

Let’s create an Oxygene for .NET Class Library project and add some code like this:

namespace SampleClassLibrary;

interface

type
  Class1 = public class
  private
    var fUnusedField: Int32;

    method NeverCalledMethod(); empty;
  public
    constructor(); empty;
  end;


  UtilityClass = public class
  public
    class method Foo(); empty;
  end;


 SomeBaseClass = abstract class
  public
    constructor(); empty;

    method AbstractMethod(); abstract;
  end;


implementation
end.

As you can see, there are several things that are not ideal, like unused fields and methods or the public constructor of an abstract class. This is, of course, simplified code, where all such things are clearly visible. At the same time, it is very hard to find all suspicious places in a real-world codebase, where the code was created by dozens of different developers and is spread between several projects containing several hundreds of code files. Of course thorough code review would help, but it is still a question of how much efforts it would require. And the question that remains – even after the code review – is to be sure that everything is clean?.

Enter NDepend.

Attach NDepend to the current solution using the menu item NDepend -> Attach new NDepend project to current VS solution.

Because NDepend doesn’t recognize Oxygene projects out of the box, we need to reference the compiled assemblies instead of the source code project, as we would do for C# or VB.NET projects. Press the ‘Add assemblies in Folder‘ button and select the folder containing the current project’s compiled assemblies. Note that NDepend will automatically preselect the folder containing compiled assemblies for the active project.

Confirm the folder selection. Assemblies will be added to the NDepend project.

Press the ‘Analyze a single .NET assembly‘ button and the project analysis will start. After it completes (a very fast procedure, even for big full Data Abstract for .NET solution), a helper dialog will appear.

Open the NDepend rules explorer (NDepend -> Rule -> View Queries).

As you can see, some entries are marked with a warning sign. These are rules that are potentially violated and were successfully detected by NDepend.

  • The abstract class SomeBaseClass should have a protected constructor instead of a public one.
  • The UtilityClass class should be static.
  • The abstract class SomeBaseClass is potentially dead code (it has assembly-only visibility and isn’t used anywhere it this assembly).
  • The Class1.fUnusedField field is not used anywhere and is thus not needed.

Try NDepend on your project and most likely you’ll find some potentially dangerous code lines.

As you can see, NDepend is mostly language independent, so all tutorials and tips ‘n tricks found at http://www.ndepend.com/ can be used with Oxygene, too.

One last advice: For some rules you won’t be able to navigate to a method or class violating some rule by double-clicking the method’s name.

This happens because in some cases (for navigation purposes) NDepend relies on its built-in language parser (that is limited to C# only) rather than on .PDB information. This custom source code parser is used because .PDB files provide information about source code declarations of concrete methods only, so additional effort is needed to acquire information about source code for namespace and type declarations.

To make it easier to find the problematic method, modify the code validation rule output by adding the full method (or class) name. To do this, just change the “rule output statement” (usually found at the very end of each rule’s query code) from code like this (for the Methods that could have a lower visibility rule):

select new { t, t.Visibility , 
                CouldBeDeclared = t.OptimalVisibility, 
                t.TypesUsingMe }

to this:

select new { t, t.Visibility , 
                CouldBeDeclared = t.OptimalVisibility, 
                t.TypesUsingMe,
                t.FullName }

Now you’ll see the full path (including namespace and class name) of the problematic entry.

P.S.: Don’t be afraid of the NDepend query language. It is a very powerful way to define own or customize existing code validation rules. At the same time, the predefined rules set allows to use the code analyzer without even touching the query language at all (except for the above-mentioned issue).

P.P.S.: Before you say ‘Hey, this thing is way too expensive’, try to estimate how much time it will save you and your team members and how much this time costs.

Avatar of marc

by marc

Visual Studio 2013 is here (for some values of “here”)

October 22, 2013 in Data Abstract, Elements, Visual Studio

The time has come, and Visual Studio 2013 is officially RTMed and available on MSDN, even though the official launch event is not scheduled until November 13th.

What does Visual Studio 2013 mean for our users?

Oxygene has been ready for Visual Studio 2013 for a while now (and i personally have been using 2013 exclusively ever since i redid my development VMs earlier this year and when VS2013 was still a private CTP we weren’t allowed to talk about). Visual Studio 2013 support for Oxygene made it into our public releases back in August, and our latest September 2013 update is fully ready for the RTM version of Visual Studio 2013. SO if you have an MSDN subscription, you can download your copy now, run the latest Oxygene installer, and you’ll get the full Oxygene experience in the fresh new IDE.

We’ll be rolling out the Visual Studio 2013 Shell with Oxygene in our upcoming (major!) November 2013 release. (We got one more release coming up before, the incremental October 2013 update, but that had been locked down before the RTM was available, and also we’ve been asked to hold of shipping the 2013 Shell until after the official launch event. ;).

Data Abstract and RemObjects SDK also have been made ready for Visual Studio 2013 with the last update we shipped in September. This applies to the .NET editions, Data Abstract for JavaScript and also – if you are using Oxygene – the editions for Java and Cocoa. We’ll be doing more testing with the RTM release, and the next update might include additional tweaks and improvements to round this off.

 

Avatar of marc

by marc

Announcing the Oxygene 6 “July 2013″ Update

July 30, 2013 in .NET, Cocoa, Cooper, Elements, iOS, Java, Nougat, Oxygene, Platforms, Visual Studio, Windows


Oxygene "July 2013"

We’re thrilled to inform you that the “July 2013″ update for Oxygene 6 is available now.

The team has been incredibly hard at work since we shipped Oxygene 6 in May, both on this update and on the next feature release coming up in August, and the “July 2013″ update brings with it a good ~140 fixes and improvements across all three editions and across the entire toolchain, from compiler to IDE.

Even though we consider this update a “bug-fix release”, we could not stop ourselves from including two major compiler/language enhancements, as well: On the Java/Android side, the Oxygene language has gained full support for unsigned integer types — a feature not available in the Java language and not officially supported by the Java Runtime, we know that a lot of you who use Oxygene on Java have been looking forward to this. On the Cocoa side, the compiler has been updated with support for Oxygene’s trademark Future Types (one of my favorite features), based on GCD under the hood.

With these two changes, we’re taking another big step towards bringing the Oxygene language closer together on all three platforms.

What’s Next?

We’ve also been busy at work for the upcoming 6.1 release (for which alpha/beta builds have been available for a while now) and beyond. Check out my blog post for more details and some hints at what is coming up. We’re very excited.

Prism

Embarcadero Prism customers, please note that the “July 2013″ release will be the last update made available to you under the Prism brand, and the last release to accept Embarcadero serial numbers.

Please make sure that you have your Prism XE3.2 serial number registered with us, so that we know about you and can contact you about moving forward. As mentioned in the past, we will honor existing SA agreements you may have with Embarcadero beyond July – but we can only do that if we know who you are ;).

As always, if you have any questions or concerns at all, please contact us at sales@remobjects.com.

Yours,
marc hoffman
Chief Architect

Avatar of Anton

by Anton

RO/DA for Visual Studio 2013 is here

July 4, 2013 in .NET, Data Abstract, Visual Studio

The Red Queen once said, “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!“.

Several days ago Microsoft released a preview of the Visual Studio’s next version – Visual Studio 2013 Preview (it can be downloaded from the official Visual Studio site). So Data Abstract for .NET and RemObjects SDK for .NET (as well as the other Visual-Studio-based editions) were updated to support the new Visual Studio version, and I can gladly report that New Project Wizard, DA LINQ Wizard and other IDE integration stuff “just works” in the new IDE.

Visual Studio 2013

To let you get started with Visual Studio 2013 yourself, we have made a new Gamma release available on beta.remobjects.com. Note even though this version is technically a pre-release, it is identical to the May 2013 release except for the added VS2013 support, and should be very stable and production safe. We will release a ‘real’ Beta soon with other bug fixes and improvements (and marc lets me know that an Oxygene 6.1 beta with VS2013 support is imminent, as well).

Anton,
Team Lead, DA/.NET

Avatar of marc

by marc

Announcing Oxygene 6 and the new Oxygene for Cocoa

May 28, 2013 in .NET, Android, Cocoa, Elements, iOS, Java, Mac, Oxygene, Visual Studio

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

Avatar of marc

by marc

Creating a Turn-Based Game for iOS: Nougat Tic-Tac-Toe

March 11, 2013 in Elements, iOS, non-tech, Nougat, Oxygene, Visual Studio, WWDC, Xcode

Over the past couple of weeks, i have been working on a new sample project for Oxygene “Nougat” on the side. After having gotten Browse500 into the App Store in January and showing how to reimplement a simple native UIKit control from Objective-C in Nougat last month, i wanted to create another example that illustrates the benefits of how Nougat interacts directly with the native APIs, and i picked a technology i knew nothing about at all to do so: Game Center.

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):

Tic Tac Toe Game Center

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.

Tic Tac Toe Board

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!

Avatar of marc

by marc

Custom iOS Controls in Oxygene “Nougat”

February 22, 2013 in Cocoa, Elements, iOS, Nougat, Oxygene, Visual Studio, Xcode

A week or so back, Yari D’areglia had an excellent tutorial on his blog on How to build a custom control in iOS that gave a nice rundown of some of the tasks involved, including handling touches, drawing some non-trivial custom UI, and returning events to the application via the target/action pattern.

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.

 

Screenshot

Avatar of marc

by marc

“Nougat”, Beta 3

February 11, 2013 in Elements, iOS, Nougat, Visual Studio, WWDC

Beta 3

On Friday, we shipped BETA 3 of Oxygene “Nougat”, a major milestone in our progress to bring the Oxygene language you know and love to the “Cocoa” platform for truly native Mac and iOS development.

The big benefit of Oxygene “Nougat” over other non-Apple tool chains for Mac and iOS is that it fully embraces the platform and is a native compiler for the Objective-C runtime (which is at the core of Mac OS X and iOS development) that works directly with the native Cocoa API and controls.

This means you get all the benefits of the platform and you can work with and access all the same APIs that Objective-C developers using Xcode can. You can, for example, attend WWDC or NSConference or read and watch any of the trillion online tutorials out there on iOS (and Mac) development — and all the things you see and learn apply directly to the code you write with “Nougat”.

My friend and college Jim has created a great new video to introduce “Nougat” and show you around Beta 3, which you can find here.

Beta 3 is a huge milestone for us, in that we believe it represents a state in the development of the product where we can call it “usable for production work”. That doesn’t mean we’re close to RTM yet — we have big and strict plans for how solid we want the product to be for “1.0” this summer — but it does mean that it is solid enough that you can start doing serious work with it. I should know, as i already have my first app created with Nougat in the App Store: Browse500. (Full source is on GitHub, too).

What’s Next?

As mentioned above, we still have a long way to go before RTM. Beta 1 last October had the goal of, well, getting something out to you guys to play with, and we got a lot of great feedback. For Beta 2 we focused on getting all the basic tool chain support in place (debugging, deploying, etc.) and our main focus for Beta 3, which we just shipped, was stability, so we spent most of our time fixing bugs in the compiler, IDE and toolchain. For Beta 4 we are shifting focus back on features — there are still quite a few things missing in the language, and we have lots of improvements and enhancements planned for the tool chain and the Visual Studio IDE support.

“Nougat” is not standing still, and the next two months should be a whirl-wind of new stuff going into the product.

After Beta 4 (and possibly a Beta 5), we are still on track for an official “1.0” release (actually, it will be 6.0) in late spring/early summer.

Get Nougat!

How do you get “Nougat”? If you bought or renewed Oxygene from us since last October, you already have Oxygene “Nougat” as part of your product portfolio. Simply head over to beta.remobjects.com and get your copy of Beta 3 (and don’t forget to participate in the beta forums as well to let us know what you think).

(If you have a Suite Subscription for Xcode, that of course includes access to Oxygene “Nougat”, as well).

If you have a license for Oxygene for Java or for Embarcadero Prism XE2 or XE3, you can renew to the full suite of Oxygene for all three platforms at $349 in our secure online shop.

If you own Delphi XE2 or later, you can take advantage of our cross-grade offer for $399 to get the full Oxygene package.

And finally, the full Oxygene package is available for new users at $499.

Avatar of marc

by marc

Using Instruments with Oxygene to Profile your Mac and iOS Apps

January 14, 2013 in Elements, iOS, Mac, Nougat, Visual Studio, Xcode

One of the coolest tools in Apple’s Xcode tool chain is Instruments, the profiler.

Profiling is an essential debugging tool for every developer, whether you want to tune the performance of a particularly time-sensitive piece of code, or drill into some memory issues (be it leaks or general memory load). With ARC, just like with Garbage Collection on .NET or Java, regular object leaks are rare, but one scenario where they can still happen (opposed to GC) is with so-called “retain cycles” — where object A holds on to object B, and vice versa.

Because Instruments is such an essential tool for the Cocoa developer, we have deeply integrated support for it into the Oxygene “Nougat” tool chain as well, and i’d like to demonstrate that in a quick (only somewhat contrived) sample.

Let’s say you have the following code:

type
  DummyData = class
  private
    fData: NSMutableArray;
  public
    method init: id; override;
    method Work; empty;
  end;
 
  DummyDataItem = class
  private
    fOwner: DummyData;
  public
    property owner: DummyData read fOwner;
    method initWithOwner(aOwner: DummyData): id;
  end;
 
implementation
 
method DummyData.init: id;
begin
  self := inherited init;
  if assigned(self) then begin
    fData := new NSMutableArray;
    for i: Int32 := 0 to 1000 do
      fData.addObject(new DummyDataItem withOwner(self));
leak
  end;
  result := self;
end;
 
method DummyDataItem.initWithOwner(aOwner: DummyData): id;
begin
  self := inherited init;
  if assigned(self) then begin
    fOwner := aOwner;
  end;
  result := self;
end;

Looks innocent enough. DummyData holds an array of DummyDataItems it initializes on creation; the code (naïvely) assumes the array and everything else to be released when the DummyData object itself goes out of scope.

Except it doesn’t, and your customer calls to complain that the app’s memory footprint is growing. How do you find out what’s going on? Instruments to the rescue.

In Oyxgene “Nougat” (as of BETA 3), Instruments is available right from inside Visual Studio. We’ve added a new menu item to the Debug menu (and you can also add it to the toolbar of course): Start With Instruments:

Hit that and Oxygene will build your app (if necessary), and via the magic of CrossBox, you’ll see Instruments popping up, Mac side — by default asking you what kind of analysis you want to perform:

Select Leaks and that will open an Instruments document, and also start your application running. Play around with the app and trigger the code paths that lead to the memory increase. In the Instruments window, you san see what’s happening, live — the overall memory load of the app keeps increasing (as shown in the Allocations instrument):

Quitting the app and selecting the Leaks instrument shows all the memory that was leaked — that is, not properly released. The picture is quite clear — it seems that 31 DummyData instances were created and never properly released. What’s up with that? After all, your code that creates DummyData is dead simple:

method MainWindowController.buttonClick(aSender: id);
begin
  var d := new DummyData;
  d.Work();
end;

“d” goes out of scope right after it’s used, and that should release the object, right?

Fold open one of the DummyData items in the list and click on the little arrow next to its address to drill into its retain/release history. You’ll see a huge list of roughly a thousand calls to retain. The call stack on the right tells you these happen from within “DummyDataItem.initWithOwner:”. That makes sense — your code creates a thousand of them, after all.

At the very end of the list, you see that from “buttonClick” your DummyData is being released though.

What’s going on? Shouldn’t “d” going out of scope release the array, which in turn releases the DummyDataItems, which in turn… wait, we’re getting close to the problem! It looks like our data structure contains what is called a “retain cycle”. The DummyData holds on to the NSArray, which holds on to the DummyDataItems which, in turn, hold on to the DummyData itself. Even though “d” is going out of scope, its retain count is only going down to 1001, because all the DummyDataItems still have references. As a result, the DummyData object actually never gets freed, and neither does the NSArray or the DummyDataItems inside it, which, in turn, can never give up their hold on the DummyData itself.

Though in this case we found the issue fairly quickly, Instruments has one more tool up its sleeve to make it even easier to find retain cycles: Click on the Leaks item in the navigation bar and select Cycles & Roots:

Instruments has actually detected any retain cycles for us and shows them in a list (in this case, 31 of the same), along with a nice graphical representation of what is going on.

From this view (even without our previous investigation), it becomes immediately clear that the fOwner reference from DummyDataItem back to DummyData is the culprit.

How do you break this vicious circle (assuming you cannot simply drop the owner reference altogether)? Weak references to the rescue!

type
  DummyDataItem = class
  private
    fOwner: weak DummyData;

By default, all variables and fields in Oxygene (and Objective-C with ARC) are strong — that means when an object is stored in the variable, its retain count is increased. By contrast, weak references just store the object, without affecting retain count. In fact, they do one better: they also keep track of the referenced object and automatically get set to nil when said object is released — so you never have to worry about the variable pointing to a stale object (which is a big problem in non-ARC languages).

Sidebar: A third type of object references are so-called unretained references. These behave like regular pointers in old-school languages; they store the object address, and when the object gets released that address will be stale — your code will be responsible for worrying about that.

With the code fixed, hit the Start With Instruments menu again. Your app will launch and Instruments will profile, and as you work with your app, you will notice that the memory load now stays down — as originally expected.

Of course, the Leaks pane will remain empty, but just to confirm, you can select the Allocations instrument, select Created & Destroyed in the sidebar and then locate and drill into one of the DummyData objects. As you can see, the retain/release history is much more sane now — no 1000 extra retains from DummyDataItem — and the object actually was released at the end of “buttonClick”.

Success!

 

So what have we seen in this article? We’ve had a quick look at how Instruments works and can be used to inspect memory allocations (the first phase of the investigation above does not just apply to bona-fide leaks and retain cycles, but can also be helpful if you just want to get a general impression of what memory your app is holding on to, and why), learned about retain cycles and strong, weak and unretained object references and we have also seen how Instruments can be used from Oxygene Nougat (which was so dead simple, it hardly warranted mentioning, wasn’t it?).