You are browsing the archive for Prism.

Avatar of marc

by marc

Custom iOS Controls in Oxygene “Nougat”

February 22, 2013 in Cocoa, iOS, Nougat, Oxygene, Prism, 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

Oxygene Gets Big(Integers)

January 18, 2013 in .NET, Oxygene, Prism

A huge part of cryptography is big numbers. Really big numbers. For example, the SHA-256 cryptographic hash produces a 256-bit thumbprint of any data you give it. Exactly how big is 256-bits?

  • 8 bits = 256
  • 16 bits = 65536
  • 32 bits = 4294967296
  • 64 bits = 1.84467E+19
  • 128 bits = 3.40282E+38
  • 256 bits = 1.15792E+77

So the maximum value for a 256-bit unsigned integer is:

115 792 089 237 316 195 423 570 985 008 687 907 853 269 984 665 640 564 039 457 584 007 913 129 639 936

Unfortunately most programming languages only have 32-bit or at most 64-bit numbers available. So in order to store large numbers like these they require you to make the awkward move to byte arrays or some other complex construct. That isn’t the case with Oxygene.

Oxygene has the BigInteger datatype. BigInteger is an arbitrary length signed integer, so it can be as big as you have memory for, and it can be used like a normal integer.

To include BigInteger support you just need to add a reference to the System.Numerics.dll assembly (part of the .NET 4.0 Framework), add System.Numerics to your uses clause, and you are good to go. Now you can use BigIntegers just like any other data type.

Behind the scenes, BigInteger is actually an object with methods, properties, constructors and operators to make it easier to work with BigIntegers. So instead of using Math.Abs use BigInteger.Abs.

You are probably wondering “What does all of this have to do with cryptography?”. I’m glad you asked. Here is a method to calculate a SHA-256 on a string and return the value as a BigInteger

class method Hash.Sha256(text: String): BigInteger;
begin
  using hash256: SHA256Managed := new SHA256Managed() do begin
    var bytes := Encoding.UTF8.GetBytes(text);
    var hash := hash256.ComputeHash(bytes);
    exit new BigInteger(hash);
  end;
end;

The ComputeHash method on the SHA256Managed object returns a byte array containing the value of the hash. Luckily there is an optional constructor for BigInteger that takes a byte array as a parameter. This creates a BigInteger from the value of the byte array.

Another great place to use BigIntegers is with the cryptographic random number generator. Unlike the random number generator you are used to, the one provided by the RNGCryptoServiceProvider is cryptographically secure – meaning future values cannot be predicted. The RNGCryptoServiceProvider will generate a sequence of bytes of any size, which makes BigIntegers another great fit.

About creating a BigInteger from a byte array: Since a BigInteger is signed, this is just about as likely to result in a negative as a positive number. If you always want a positive number, you can append a zero byte to the end of the byte array, we will do that for our random number routine.

This method will return a BigInteger of the number of bytes specified.

class method Rnd.BigRnd(bytes: Cardinal): BigInteger;
begin
  using rng := new RNGCryptoServiceProvider do begin
    var tokens := new Byte[bytes + 1]; // one extra byte for the sign
    rng.GetBytes(tokens);
    tokens[bytes] := 0; // keep the result positive
    result := new BigInteger(tokens);
  end;
end;

Take a look at the code and see what sort of uses you can find for really big integers. BigInteger support was introduced a while ago for Oxygene for .NET – yet another feature you probably didn’t know you had.

Avatar of marc

by marc

Working with User Interface files in Oxygene “Nougat”

January 2, 2013 in Cocoa, iOS, Mac, Nougat, Oxygene, Prism, Visual Studio, Xcode

In this article, i want to talk a bit about working with user interfaces in Oxygene Nougat.

As you know, Nougat is a native compiler for the Objective-C runtime, meaning that it works directly with the classes provided by Apple’s Cocoa and Cocoa Touch frameworks. This extends from low-level classes such as NSString or NSArray to the high-level visual components based around NSView (Mac) and UIView (iOS).

One common way for Mac and (especially) iOS apps to work with UI is to simply create the necessary views and controls that make up an app’s UI from code. But sooner or later, especially when dealing with more complex or sophisticated user interfaces, you will want to use the visual designer. This works on the same principles, whether you are using Xcode/Objective-C or Nougat.

Mac and iOS interfaces are designed in Interface Builder, which as of version 4 is directly integrated into the Xcode IDE, and when working with Nougat, that is where you will work with your interfaces, getting the same experience and the same power and flexibility of UI design that developers using Objective-C get, as well.

There are two file formats used for designing UI on Apple’s platform — the older XIB format and the newer (and iOS-only) storyboard format. The principles for dealing with these files are similar, but for the topic of this article, we’ll focus on XIB files, as those apply to both Mac and iOS development. In a future article, i will go into some more details specific to storyboards.

Background: What are XIB Files?

So what are XIB files? From the point of view of the UI designer, XIB files contain the views or windows that you design in Interface Builder — the controls, their layout and properties, and their connections to your code.

It is important to understand that on a technical level, XIB files are stored object graphs. That means that an XIB file, essentially, is a hierarchical set of objects descriptions. When an XIB file gets loaded at runtime, all the objects defined in the XIB file get instantiated, configured, and connected as described in the XIB.

These objects can be a combination of standard framework classes (such as NSView/UIView, NSButton/UIButton, etc), classes from third party libraries, or even classes defined in your own application code. When the Cocoa runtime loads an XIB, it goes thru the list one by one, looks for the classes with the appropriate names and news up the necessary objects.

Each XIB file also knows about a special object called the “File’s Owner”. This object will not be created when the XIB is loaded. Rather, the object that initiated the loading of the XIB file will take the place of the File’s Owner within the XIB’s object graph — including any connections and references to it. We will see how that is useful and important, soon.

Loading up an XIB

When and how do XIB files (or storyboards) get loaded? There are several possibilities:

 

NSMainNibFile

If your Info.plist contains an NSMainNibFile entry, the Cocoa runtime will automatically load up that XIB as your application starts up. The global NSApplication/UIApplication instance will become File’s Owner of the XIB, and every object in your XIB will be instantiated.

This mode is common for Mac applications, and in fact you can see it in action in our Cocoa Application template(s). You probably noticed that (aside from the startup code in Program.pas) the project contains an AppDelegate class that is usually used as the “launching point” for your application’s own code.

How does this AppDelegate class get instantiated? Easy: If you own the MainMenu.xib file in Xcode (the xib that is specified to be the NSMainNibFile in Info.plist), you see that — among other elements — it contains an AppDelegate item. This is your own AppDelegate class.

initWithNib:*

For simple applications, you can get away with just putting all your stuff into MainMenu.xib, but as applications get more complex, that’s a bad idea, not only because — as indicated above — when an XIB is loaded, all objects referenced in it are created. If your application contains dozens of windows or views, you don’t usually want all of those to be loaded up as your application starts.

Instead, it is common practice to pair individual XIBs for each view or window XIB with a matching ViewController or WindowController class — a practice that you will see in just about all the iOS project templates, and also in the *Controller item templates we provide with Nougat.

How does this work?

Simple: your application will define a custom class, usually descended from UIViewController (or NSViewController/NSWindowController) where you will put all the application logic for that view or window. As far as your app is concerned, this class is your implementation for that particular view (or window — for simplicity reasons i’ll stick to talking about iOS Views for now, but the same concepts apply for OS X views and windows).

In the initializer for your view controller, you will ask the base class to load up the XIB file that backs your view, for example by calling

self := inherited initWithNib('MyViewController') bundle(nil);

This essentially tells the base class to initialize it by loading MyViewController.xib (from the main application bundle) and creating all the objects defined in it.

So all those objects get loaded up, but how do you then get access to them from your code? Simple: remember when i said above that the object loading the XIB becomes the File’s Owner? When you load an XIB using the initWithNib() call, your view controller class becomes the File’s Owner — and any connections you set up in the XIB between the File’s Owner and the other elements in your XIB will be connected to your view controller class.

Connections

Did i say connections? So how does this work?

Easy, really. XIB files know about two basic kinds of connections between objects: Outlets and Actions.

You can think of outlets as references to other objects. If your view controller class has a property of type UIButton, and your XIB file contains a UIButton, that’s a match made in heaven. You can just Ctrl-drag the button onto the File’s Owner (or vice versa) in the XIB to hook them up, and now you have access to the UIButton from your code, because as the XIB gets loaded and the UIButton gets created, it gets hooked up to your property automatically.

Actions, you may have guessed, can be thought of as events. If something happens with the objects in the XIB (such as a button being tapped), they send out events. Just as above, if your view controller exposes a method with the right signature (that is, any method with exactly one parameter of type “id” or a concrete class), you can Ctrl-drag it into your XIB file to hook them up — and when the event triggers, that method is called.

Of course outlets and actions can be hooked up between any two objects inside your XIB, not just with the view controller. For example, you can cause an action on one control to trigger a method on a different control.

Ok, so how does the XIB designer in Xcode know about the methods and properties on your view controller (or other classes)? Magic! As you write your classes, Nougat will automatically* update the XIB and Storyboard files, behind the scenes, with information about all the relevant classes and their properties and methods — that is any property marked “[IBOutlet]” and any method marked “[IBAction]“. As you work on your XIB file in Xcode, it sees this information, and makes the connections available.

If you need to expose a new control to your code or want to hook up a new event, simply add a new property or method to your code, and that’s it.

Let Me See This in Action

For this example, i’ve created a new “UIViewController with XIB” from the template. I have then added the following items to the “MyViewController” class:

property myButton: UIButton;
property myLabel: UILabel;
method buttonTapped(aSender: id);

The following screenshot explores the XIB (and storybook) designer in Xcode:

Figure 1: On the left side of the window, you see a hierarchical view of all the objects in the XIB — this includes all visual objects (in this case just the one UIView for now, but also other objects such as the File’s Owner).

On the right side, the “Utilities View” has the “Identity Inspector” pane activated, showing details about the selected object (the File’s Owner). Note that the XIB designer knows that File’s Owner is a “MyViewController”. It got that information from the template – but this is editable, so you can just type in or select the right class name. Of course it should match the class that is loading this XIB at runtime.

Figure 1

Figure 2: We have dropped a couple of controls onto the view — you can see them both visually and in the hierarchy on the left. The right pane has been switched over to the “Connections Inspector” tab, which shows all the connections available on our File’s Owner. Among them, you see our two properties and the method. There’s also a “view” property (defined by the UIViewController base class), already connected to the root view.

Figure 2

Figure 3: Click and drag from the little circle right of the “myButton” name to the button to make a connection to the UIButton. (You can drag to the control on the design surface or to the “Button — Tap Me!” item in the hierarchy.)

Let go when you are over the button, and the connection is made. If you were to go and build your app now, the myButton property would give you access to the button from code.

Figure 3

Figure 4: You can also drag from the hierarchy view to a control. When you let go, the XIB designer will present a list of all properties that match — in this case the UILabel qualifies both for “myLabel”, and for the “view” property (because UILabel descends from UIView).

Figure 4

Figure 5: Connection actions work the same way. You can Ctrl-drag from the control to the receiver (here the File’s Owner) to connect the default action of that control (in this case, the button tap) to a method. As you can see, the Connections Inspector also shows a complete list of all actions that can originate from the control, so you can — if needed — assign them all to individual methods.

Figure 5

Now all that’s left to do is maybe write an implementation for “buttonTapped” such as this:

method MyViewController.buttonTapped(aSender: id);
begin
  myLabel.text := myButton.titleLabel.text;
end;

to see both actions and outlet access in — pun not intended — action.

Terminology: XIB vs. NIB?

In the text above, i talk about XIB files, but the method names all mention NIBs. What’s up with that?

XIBs are a newer, XML based format that is used for the UI at design time. When you compile your app, the XIB files are converted to binary NIB files for you, and those binary versions of the files are embedded into your app. All the APIs working with these files predate the new format (and, at runtime, only work with the older NIB format), that’s why all the method names refer to NIB, not XIB. When you pass around names, you never need to (or should) specify the file extension anyway, so this is a distinction that you can largely ignore (unless you want to go spelunking into your .app bundle).

What’s “First Responder”?

Similar to File’s Owner, “First Responder” is another placeholder object exposed in the XIB file that has special meaning. The First Responder is not a concrete object, but essentially refers to “the first object that has focus that can handle this”.

By connecting actions to the First Responder, you can have them dynamically be sent to different parts of your application, depending on the state your app is in. A good example is the “Edit|Copy” menu in a Mac application. If a text field has focus, you would expect the Copy command to apply to the content of that text field. If a different control has focus, different content would be copied. By connecting the menu’s action to the First Responder’s “copy:” method, Cocoa will take care of calling “copy()” on whatever control or view has focus — in fact, all you need to do to make Copy/Paste work with your own custom view would be to implement the corresponding methods, and they would get called if your view has focus as the user invoked the menu item (or Cmd-C keyboard shortcut).

Summary

I hope this gave you a quick introduction to XIB files and how they work. A good 95% of the content of this article is not really specific to Nougat; the same concepts and techniques apply to working on XIB files with Objective-C — that’s by design, because Nougat is a true first class citizen on the Cocoa frameworks and Objective-C runtime.

Footnotes

(* in the current beta drop, this update does not happen automatically yet. You can right-click your .XIB or .storyboard file in Solution Explorer and choose the “Sync XIB”/”Sync Storyboard” to trigger an update.)

Avatar of marc

by marc

Using RemObjects SDK and Data Abstract with Oxygene Nougat.

December 25, 2012 in Cocoa, Data Abstract, iOS, Mac, Nougat, Prism, Visual Studio, Xcode

Nougat is, of course, designed to work with any existing Objective-C libraries out there, because it directly consumes and generates code for the Objective-C runtime. As such, it should come as no surprise that Nougat is ready to use RemObjects SDK and Data Abstract for Xcode, out of the box.

That said, with the new Alpha builds of RemObjects SDK and Data Abstract that we shipped on friday (build .1069), we have made a few improvements that make it even easier to get started with RO/DA in Nougat. These are three-fold:

Read-to-Use .fx files

Unlike .NET and Java, Cocoa libraries do not include easy to parse metadata for compilers to consume. Instead, it depends on .h files to define the available APIs — which is fine when consuming the libraries from a C compiler. Because .h files are slow and complicated to parse, Nougat introduces an intermediary format in the form of .fx files. You can think of an .fx file as “pre-compiled headers” file for a given framework or library; a set of metadata that represents all the information expressed in the framework’s .h files, but encoded in a way that it is easy and quick for the Oxygene compiler (and IDE toolchain) to process, when compiling, driving Code Completion etc.

While Nougat comes with the necessary tools to generate .fx files for any of your favorite third party libraries (and of course ships with .fx files for the supported base SDKs), that is an extra step we want to alleviate, so the new build of RODA/Xcode includes .fx file for those libraries out of the box. After installation, you will find the files next to the corresponding binaries in ./Bin.

All you need to do to use the SDK or Data Abstract from Nougat is to go to “Add Reference”, select the .fx file for your platform (i.e. OS X or iOS) to add a reference. That’s it.

libDA.fx Reference

From the .fx, Nougat will automatically know about all the types in the RO/DA library, and will take care of getting the static library and any dependencies linked in.

Static Libraries for OS X

In the past, RODA/Xcode included precompiled binaries in the form of a framework for OS X and static libraries for iOS. Frameworks are easier to deal with in Xcode, because they combine a binary with its accompanying header files, which is why we chose to ship OS X binaries as a framework. iOS does not support the framework format for third party libraries, so the choice there was easy: static libraries are the only option.

For Nougat, the benefits of a framework (on OS X) are diminished, because metadata is provided in the .fx file anyways, so a static library is just as easy to deal with, and has fewer files involved. For that reason, we have added a static library version of RODA/OS X to the product (in addition to the Framework). Xcode developers can choose to use either version, depending on their preferences (the static library has the benefit of being linkable straight into the executable, which is nice if you’re creating command line tools that use RO/DA); Nougat developers will mostly want to use the new static library alongside its .fx file.

CodeGen for Nougat

For pure Data Abstract use, you’re pretty much all set with the above, but if you’re building custom RemObjects SDK services that you want to talk to, there’s one more step missing: Interface code.

Talking to RO services depends on having strongly typed interfaces generated for your local proxy classes and any complex types you are passing back and forth between the client and the server — and until last week, RO/Xcode generated this code in Objective-C only.

That was not a complete showstopper for Nougat. Remember, Nougat can use any Objective-C library, so you could compile those files using Xcode and the use them from Nougat (in fact, that’s what i’ve been doing with for small RODA project i have been working on over the past few weeks). But that’s not ideal, of course.

The new alpha now includes native Nougat CodeGen for your services, so you can generate an Interface .pas file and add it straight to your Nougat project — as it should be.

The new CodeGen is exposed in three places:

  1. Of course the codegen2.exe command line utility has been updated, so if you generate code from the command line, you can use the /lang:nougat option to have interface files written for Nougat.

  2. Service Builder has also been expanded to support Nougat alongside all the other languages (that menu is getting mighty big!):

Service Builder

  1. Finally, we also added Nougat CodeGen to our rodl2objc.app on the Mac (which is now really becoming overdue for a rename ;). While we were at it, we also revamped the UI for this tool a bit to make it (simple as it is) nicer to use, and look at:

rodl2objc

(and as the beta progresses, CodeGen will also be available directly inside the Visual Studio IDE, as well)

So with that you should be all set to build your first great client application for the Mac or iOS, using RemObjects SDK/Data Abstract and Oxygene “Nougat” over the holidays ;)

Let us know how it all works out!

yours,
marc

Avatar of marc

by marc

Oxygene “Nougat” BETA 2 is out!

December 3, 2012 in iOS, Mac, Nougat, Oxygene, Prism, Visual Studio

On Friday, we shipped BETA 2 of Oxygene “Nougat“, the next major platform for our Oxygene language (in case you have missed it or have been living under a rock, Nougat is “Oxygene for Cocoa” and brings your favorite programming language to native Mac and iOS development. You can read more about it here and in my previous blog posts).

Jim also recently spent some time on a great “Oxygene Overview” video that went live today and gives a first peek at Nougat, too.


 

It’s been about 8 weeks since we shipped BETA 1 (and we shipped updated builds to testers more or less weekly since then), and the team has been really busy and made great progress on all fronts. BETA 1 was a very early look at the product — it was still very rough, the “this is what you need to know to get started” list was way long, and many things did not (by design) work yet. But we wanted to let the early adopters get started, and we’ve gotten great feedback for this first part of the beta cycle.

BETA 2, out now with build .1139, is a lot more robust, should provide a fairly decent “out of the box” experience to get started, and — most importantly — sees most core functionality working decently.

BETA 2 supports running and (still limited) debugging of Mac apps (Cocoa and console) and iOS apps on both the Simulator and actual devices. BETA 2 has fully integrated the deployment toolchain, so that with the press of a single key (F5, a.k.a. “Start”), your app gets compiled, linked, packed up, code signed, and uploaded to your device. The compiler has been vastly improved in BETA 2, with lots of bugs fixed and lots of features and improvements all thru-out; the corresponding IDE experience has improved as well, for example with code completion and related editor smarts fully understanding the new “multi-part” method name syntax, everywhere.

Of course we still have miles and miles to go before we reach RTM. As promised from the get-go, we are shooting for a release of “1.0″ (or rather “6.0″, as it may be) in the “first half of 2013″. Now, we strongly plan for that to not mean “on June 30″ (we’re not Apple ;), but we are taking our time to get everything right, and we do still have a good 5-6 months ahead of ourselves in terms of getting Nougat to final.

But, we also know that you are anxious to get started, and a lot of you have been holding off jumping into the dangerous waters with BETA 1. But if you are at all adventurous and inclined to live on the edge a bit, BETA 2 (and its continuing semi-weekly updates) is as good a point to get your feet wet as any.

So what are you waiting for? Assuming you have already ordered your copy of Oxygene, head over to beta.remobjects.com to grab your copy of “Nougat” BETA 2 now! Make sure to check out my “Getting Started” post, as well.

(If you don’t have Visual Studio 2012 installed yet, grab the latest Oxygene for .NET or Java installer from here first, and then install the Nougat beta on top (this will upgrade all three editions to the latest bits)).

Also, don’t forget to let us know what you think — leave your comments here, or join the discussion in our private beta forum at connect.remobjects.com/categories/nougat-beta.

Yours,
marc

Free issue of Blaise Pascal magazine to registered users

November 5, 2012 in Guest Post, Java, Oxygene, Prism

I must have missed this one being announced, but registered users of XE, XE2 and XE3 products can pull down a free copy of Blaise Pascal, the magazine for all things Pascal-based.

Details are on this edn post by Tim DelChiaro and you can pull down the PDF magazine from Code Central.

The free issue, Issue 24, runs to 120 pages and has a number of articles from notable authors (such as Cary Jensen, Bob Swart and Bruno Fierens) on a variety of subjects including FireMonkey 2, Smart Mobile Studio, HTML 5, Delphi XE3 Styles, Delphi XE3 helper types, and interviews with various industry luminaries, including Marco Cantu, Mike Rozlog, marc hoffman and David I.

Also in the issue is my second article on Oxygene for Java: Supporting new android features in old android versions with Oxygene.

Download the magazine – I hope you like the contents!

Windows Store Development with Oxygene

November 1, 2012 in .NET, Metro, Oxygene, Prism, Windows

When Microsoft released the Visual Studio 2012 Shell, support for building Windows Store apps (formerly known as Metro apps) was missing. This certainly frustrates Windows Store Development with Oxygene which ships with the Shell.

Fortunately I’ve found a work-around to this annoying omission. Simply install Visual Studio 2012 Express for Windows 8 (free download) and then install (or re-install) Oxygene for .NET. This activates the support for WinRT templates and the Modern UI designers in the Shell. After that you can use the WinRT and Modern UI designers in the Shell with Oxygene for .NET.

The Visual Studio Shell and the Express Editions share many resources. As long as the Express Edition is installed, the Visual Studio Shell has WinRT and Modern UI support available for use in Oxygene for .NET development. The Express edition does not support Oxygene, so you will need to continue using the Shell.

Update: It was reported that it may be necessary to uninstall the Shell if you have trouble installing the Express Edition. So if you run into trouble you might try that.

Avatar of marc

by marc

What is “Nougat”? — Part 4

October 19, 2012 in iOS, Mac, Nougat, Oxygene, Prism, Uncategorized, Visual Studio, Xcode

In the first three parts of this series, we took a look at the basic concepts and design principles behind Oxygene “Nougat”, and the IDE experience. In this fourth installment, i’d like to give you an overview of the build and deploy process, and a quick peek at debugging.

Building your project is something that happens behind the scenes and most of the time, we don’t think much of it. We press F5 in the IDE, and a few seconds later our app is running. But a lot is going on behind the scenes to get from your source code to the final executable — and a lot more than usual, for building Mac and iOS apps.

Let’s have a look. All that we’ll be seeing here happens, of course, behind the scenes and automatically, without you having to worry about a thing.

It all starts with the Oxygene compiler, which takes your source files and turns them into executable code. For Nougat, that is the same Oxygene compiler you know and love, only instead of emitting a final “.exe” or “.jar” file as it would do for .NET or Java, it generates a file with CPU-native binary code for either x64 or armv7(s), and a “.o”. (In fact, if you’re building an iOS app with armv7 and armv7s support, the latter being new for the iPhone 5, it will generate two such files.)

On the back-end, Oxygene leverages the great LLVM compiler, which generates highly efficient code.

The “.o” is not the final executable, it still has to be linked. So next, our toolchain calls “ld”, which is the linker. This happens via CrossBox, passing the “.o” file over to the Mac, linking it against all the frameworks it needs, and returning the final executable (which is extension-less) back.

At this stage, we’re done if we’re building a Mac console app, that is, a simple executable that you want to run from the command line. Most Mac (and all iOS) apps aren’t simple console apps, so there’s more that needs to be done to get a final, runnable app — and Nougat does that for you, of course.

Mac and iOS apps come as what is called “Bundles” — which are really folders with an .app extension that are treated as individual files by the OS X finder and other parts of the OS. In the Project Properties of your Nougat app, you’ll find a checkbox called “Create .app Bundle” (checked by default in most templates) that enables this functionality:



With the option set, Nougat’s build chain will take the executable generated above, along with any other files your app needs (such as images or other resources) and generates a full .app bundle. It will also automatically generate an Info.plist file describing your app, or take an existing Info.plist file that’s part of your project and adjust/tweak it as necessary.

The Info.plist file, next to the executable, is an important part of the .app bundle that tells the OS how to run our app, what documents it supports, what application icon to use, etc.

If you’re building a Mac app application, you can be done at this point, and the resting .app bundle is fully runnable. However, these days it’s good practice to digitally sign your application (and in fact that’s required for iOS apps, and also for Mac apps if you want to use the Mac App Store).

How do you sign your app? Nothing easier than that. Looking at the Project Properties again, there’s an option called “Code signing certificate name”, along with a drop down that shows you all the (relevant) certificates Nougat found on your Mac that can be used for signing apps (this list will differ between Mac and iOS projects). Simply select the right certificate, and when you build, Nougat will automatically code-sign the final .app bundle for you.



For iOS apps you will usually choose a “iPhone Distribution: XXX” or “iPhone Developer: XXX” certificate issued by Apple, where XXX is your name or your company name. Distribution certificates are used to build apps to ship on the app store or deploy to beta testers or inside your company; Developer certificates are used while you’re testing your apps on your own devices.

For the Mac, you can choose between “3rd Party Mac Developer Application: XXX” certificates for deployment of Mac App Store apps, or you can use Apple’s new “Developer ID Application” certificates, for non-MAS apps.

In either case, all you need to do is select the certificate, and off you go.

iOS applications also need what is called a “provisioning profile”, generated on Apple’s developer portal, to govern how they can be run. As you might have guessed, there’s an option in Project Properties that lets you pick the provisioning profile you want to use from a list, and Nougat takes care of the rest.

The actual code signing, once again, happens on the Mac, marshaled over transparently via CrossBox, so you don’t even notice it’s happening.

There’s a few more things that might have to be done as part of this process (for example .xib and .storyboard files that might be part of your project will get post-processed into a binary format before being included in your .app bundle), but finally, we have a finished .app bundle that’s ready to be used — run, debugged or, hopefully at some stage, be submitted to the App Store.

Running and Debugging also happens seamlessly. In the CrossBox menu we already saw in my previous post, you can select a Mac or a Device (real or virtual) connected to your Mac:



The menu will list any Mac on the network that’s running CrossBox, as well as any remote CrossBox server you might have connected to. Underneath each Mac, you can select the device you are building for and deploying/running/debugging on. For Mac OS X applications that is just the Mac itself, but for iOS, you can choose between the “iOS Simuator”, a generic “iOS Device” (which lets you build for a device seven without having a real one attached), as well as any actual devices connected to your Mac:

For iOS, the selection you make here affects several parts of the build process. First of all, the Mac you select is of course the one that will be used for all tasks that need to be handled Mac side (linking, code signing, etc).

More importantly, by either choosing “iOS Simulator” or a device (whether a real one or the generic “iOS Device”), you are telling Nougat whether to build your project for device hardware (i.e. in most cases armv7 and armv7s binary, and against the real iOS SDK) or for the Simulator (in which case it will generate an i386 binary, linked against a separate Simulator version of the SDK).

Finally, the device choice also influences how your finished application runs. If you selected a real device, Nougat will deploy the .app to that device, and optionally launch it there, to run or be debugged, and if you selected the iOS Simulator, the app will launch in the simulator on the Mac. (Obviously, an app cannot be deployed or run on the generic “iOS Device”, that option is for building the app only.)

Debugging the application is almost unspectacular, in spite of a lot of effort having gone (and continuing to go) into this: Nougat adds a full Mac and iOS debugging engine into Visual Studio, based on the LLDB debugger, allowing you to use virtually all of the capabilities of the Visual Studio debugger that you are used to from .NET (and Java — where we did the same). You’ll be using the debugger as you always have:

Summary

Ok, so this post took you on a quick tour on what happens behind the scenes when you press “Start” to build and run your Mac or iOS project.

In hindsight, there’s a lot happening, but none of it is any black magic. Nougat takes care of all the gory details for you, so you don’t have to worry about provisioning profiles, code signing and the like, but it will document all the steps it takes (and any command line tools it runs) in the MSBuild log, so that there’s no “black box” and you can know what’s going on, if you care.

Reminder: Keep in mind that the Nougat beta is active now (we started last Monday), so if you pre-ordered the Oxygene 5.2 bundle or own a Suite Subscription for Xcode (we’ll have to rename that one, won’t we?), you have access to the beta now. If you didn’t — well, what are you waiting for? Order your copy now!

Stay tuned for more.

Avatar of marc

by marc

What is “Nougat”? — Part 3

October 2, 2012 in iOS, Mac, Nougat, Oxygene, Prism, Visual Studio

In the first two parts of this series, we have taken an initial look at Oxygene “Nougat” from the compiler side. Today, i want to delve deeper into some aspects of the IDE experience for Nougat.



We have gotten a lot of questions about our IDE plans for Nougat over the past few weeks. As you know, right now Oxygene for .NET and for Java both focus on Visual Studio as an IDE, and — at least for the time being — so will Nougat. There are a lot of arguments for and against different IDE choices, but it really boils down to resources: we have a great and solid IDE experience for Oxygene in Visual Studio already that Nougat gets to inherit relatively easy, and there’s only so many things we can do at once. So for “1.0″, the initial Nougat release, we are focusing on the compiler and tool chain, leveraging our existing IDE.

For the future (2013 and beyond), we are looking at additional IDE options — not just for Nougat, but for all three target platforms, however, it’s too early to talk about those ideas yet.

Nougat in Visual Studio

So what does Nougat in Visual Studio look like? Well, pretty familiar ;). If you’ve used any of the other two editions of Oxygene before, you will feel right at home with Nougat. You will start creating new apps using one of the included project templates, of course:


Project Templates

And once you start coding, you get all the great IDE features you know and love — from code completion to inline errors:


Inline Errors and CC

Just as in .NET and Java, Solution Explorer is the central point for managing your project (the only giveaway being the green tint in the project and code file icons).


Solution Explorer

Under the References node in Solution Explorer, you manage the Frameworks (or libraries) that your project links against. Need to reference another framework? Easy, just choose “Add Reference”, and you get a list of all the frameworks provided by the SDK your project is targeting — or you can browse to add other frameworks, for example third party libraries such as Data Abstract.


Project Templates

As discussed in the previous post, Oxygene uses .fx files that provide a sort of “pre-compiled header” cache of which members are exposed by the frameworks, and Nougat (in its current alpha build) ships with ready-to-go support for OS X 10.6 thru 10.8 and iOS 5.1 and iOS 6.0 (but you will be able to seamlessly work with newer SDKs when they come out, w/o needing us to update Nougat with explicit support).

In “Project Properties”, one of the options you will find is the SDK selector. You can select a generic SDK name (such as “iOS” or “OS X”) and Nougat will link against the newest version of that SDK type it finds (the equivalent of selecting “Latest” in Xcode), or you can select a specific Target SDK, say “OS X 10.7″


CrossBox

So now you’ve written your app — what’s next? You’ll want to build and run it, of course. Nothing easier than that. Nougat comes with a helper application codenamed “CrossBox” that you can run on your Mac(s). Nougat’s IDE integration will automatically find any local Mac running CrossBox and let you deploy and run your Mac applications there. Ditto for iOS applications, where CrossBox will let you select the simulator or any attached iOS device and run your app on there — simply by pressing “Start”.


CrossBox

If your Mac is not on the local network (maybe you have one hosted with MacMiniColo who have a very awesome special offer this week), or are renting a Mac via MacInCloud, Nougat won’t find that Mac automatically, but you can of course manually connect to it by specifying its address.

Mac-side, CrossBox provides nice, Mac-native UI to let you know what’s going on, including Notification Center support on Mountain Lion, when your apps start or stop running, etc.


Inline Errors and CC

Summary

Ok, so this has been a summary of the Nougat IDE experience, on Speed. Stay tuned for our next part, where we take a closer look at the build-and-debug process!

Native iOS development for Delphi programmers: Project ‘Nougat’

September 25, 2012 in Guest Post, Java, Oxygene, Prism

If you’ve kept up to date with developments in the world of Delphi, you’ll be aware that Embarcadero have teased us with a multi-step way of targeting iOS devices using the cross-platform FireMonkey framework and then just recently taken it away again (for now…).

It seems almost prescient, then, that RemObjects have just announced Project ‘Nougat’, which is the next incarnation of their Delphi-like Object Pascal based Oxygene compiler.

Oxygene will soon be natively targeting three platforms:

  • .NET: Oxygene for .NET (aka Delphi Prism aka Embarcadero Prism) is the longstanding .NET compiler that took over from Delphi for .NET in Borland/CodeGear/Embarcadero’s RAD Studio suite. It was released in 2005 and supports all the platform features such as LINQ and the Parallel Framework and targets regular .NET, Silverlight, Windows Store (aka Metro), Mono, in other words anything .NET can be targeted from Oxygene for .NET.
  • Java & Android: Oxygene for Java (previously Project ‘Cooper’) was released in 2011 and supports the targeting the Java Virtual Machine and also fully supports the Android toolchain. This means you can target regular Java apps, Java servlets, Java applets, and also build apps for Android phones and tablets. I’ve posted quite a bit already on Android development using Oxygene for Java.
  • OS X and iOS: this is what Project ‘Nougat’ is all about. It is in development, and the beta is expected to start in early October 2012, with release in the first half of 2013. ‘Nougat’ will target:
    • 64-bit OS X apps
    • 32-bit ARM v7 iOS apps
    • 32-bit Intel iOS Simulator apps

    There will be no wrappers involved in the generated apps, so nothing like Mono will be necessary. You will get native apps out of Project ‘Nougat’, coded in Pascal but as native as if you’d used Objective-C.

This is a great move forwards to fill in the gaps in what Oxygene can target and now gives a full spread over the major desktop and mobile platforms in one permutation or another.

If interested in native iOS and OS X targeting using all the regular native APIs as nature intended then be sure to read the series (in progress) of posts by RemObjectsmarc hoffman:

Additionally (and perhaps importantly), if you buy an Oxygene subscription for $499 (that’s the price for a new subscription – it’s $349 for a renewal) you get all three platforms: Oxygene for .NET and Oxygene for Java (and Android) and Project ‘Nougat’ (you’ll get access to the beta and also the shipping product when it comes out in the first half of 2013).