You are browsing the archive for iOS.

Avatar of marc

by marc

Using RemObjects SDK and Data Abstract with Oxygene Nougat.

December 25, 2012 in Cocoa, Data Abstract, iOS, Mac, Nougat, Oxygene, 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 Elements, iOS, Mac, Nougat, Oxygene, 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

Avatar of marc

by marc

Getting started on truly native Mac and iOS development with Oxygene “Nougat”

November 10, 2012 in Cocoa, Elements, iOS, Mac, Nougat

In preparation for “Nougat Beta 2″, our next milestone coming up in a couple of weeks, i wanted to sit down and write up a quick “getting started” article on how to get going with Mac and iOS development in Nougat, including some aspects applying to Mac and iOS development in general (i.e. whether using Nougat or Xcode) that we should not take for granted for people w/o existing Xcode background to know.

Setting up Shop

While Nougat itself works inside Visual Studio 2012 on Windows (for now), it also interacts with some infrastructure on the Mac side that needs to be set up in order to get going. Nougat provides the CrossBox helper application that bridges this gap and allows Visual Studio to hand off tasks to the Mac as needed (and to communicate with iDevices attached to the Mac for on-device deployment and debugging).

Install “Nougat” using the setup we provide.

After you install Nougat on your Windows PC or VM, you will find a CrossBox.zip file in the install folder. Simply copy this zip file over to your Mac, unzip it and run the contained CrossBox.app. Done. (for now CrossBox.app requires Mono because it is a RemObjects SDK for .NET server).

CrossBox

To do any reasonable work with Mac and iOS development, you will also need a copy of Xcode installed on your Mac. You can get Xcode for free on the Mac App Store (and sometimes you can get newer beta versions at developer.apple.com).

Note that different versions of Xcode come with different versions of the iOS and OS X SDKs. At the time of this writing, the latest version of Xcode is 4.5.2, and it contains iOS 6.0 and OS X 10.8. Nougat lets you build applications for different versions of these SDKs, but you will need the matching version of Xcode. So if you want to build your application against iOS 5.1, you will need the older version of Xcode, 4.4, that comes with iOS 5.1. Similar, if in the future there’s a beta of, say, OS X 10.9, you will need the proper version of Xcode that comes with that beta.

You can have multiple copies of Xcode installed on your Mac, and you can select the active version in two ways:

  1. In Xcode (whatever version), you can invoke Preferences (⌘,) and on the Locations tab you will find a popup where you can select the version to be active for “command line tools” (which is what Nougat will use):

    Selecting an Xcode Version

  2. Via the command line (i.e. in Terminal.app or via ssh), you can run

sudo xcode-select --switch /path/to/Xcode.app

to select which version of Xcode.app is active (you can also call xcode-select with the –print-path option to see which version is currently selected — in fact, that’s what CrossBox does to decide which version it uses).

With that, you’re almost done. For Mac development (or iOS development with the Simulator), you would be all set, but for creating iOS applications that run on your iDevices, or to create Mac apps for the Mac App Store that use iCloud, you need to set up a developer account with Apple, and create and download some profiles and certificates.

Assuming you went ahead and created a developer account (for either iOS or Mac development or both) at developer.apple.com, simply go into Xcode and open the Organizer (choose Window|Organizer from the main menu, or press ⌘⇧2). Select the Devices tab at the top and the Provisioning Profiles item in the source list of the top left.

If you’re already set up in Xcode, you might see some items, if not, the list is most likely empty. Worry not, simply press the Refresh button on the bottom right and Xcode will automatically reach out to developer.apple.com and download or create the necessary certificates and profiles to get you started. When done, your Organizer window should look something like this (but probably with fewer items):

Organizer Window

At the very least, you should see profiles called “iOS Team Provisioning Profile: *” and/or “Mac Team Provisioning Profile: *”, depending on which programs you signed up for.

Not displayed here, matching code signing certificates should also have been created in the Keychain for you, called “iPhone Developer: X” or “Mac Developer: X”, where X is your name.

With this, you’re all set on the Mac side, so let’s switch over to Nougat in Visual Studio on Windows and start your first project. For this topic, i’ll walk you thru an iOS project, as that is the more complex scenario compared to OS X.

Your First iOS App

In Visual Studio, select File|New|Project, and browse for the Oxygene Nougat folder. For now, Nougat has a handful of templates, but this number will increase over the beta period and for RTM next year. Right now, let’s pick the “Universal Master/Detail App” to create an app that can run on both iPhone and iPad. This template will use Storyboards for the UI, but we’ll go into those in a future topic.

New Project

Once you press OK, the project will be created and the AppDelegate.pas file will open in Visual Studio. The template already creates a basic runnable application, so let’s ignore the code for this article and focus on building and running the app as is.

As first step, you will want to have a look at the “CrossBox” menu item in the Visual studio toolbar. If you’re freshly starting out, Nougat probably doesn’t know about your Mac running CrossBox yet. There’s two ways to rectify that:

  • Our recommended approach is to install Bonjour on your Windows PC or VM, if you have not already done so (or gotten it as part of, say, iTunes). With Bonjour, Nougat will automatically find local Macs running CrossBox, and you should see them in the CrossBox menu when you click it open. Simply select your Mac and choose Connect.

  • If you don’t want to use Bonjour, or your Mac is remote, no worries: simply choose Add Server… from the CrossBox menu, and you can manually enter the address of your Mac to connect:

    Add Server

No matter which way you picked your Mac, the very first time a connection is established, you will need to authenticate. This is to prevent just any random Nougat user on the local network (or even the internet, if you use CrossBox on a Mac at a remote location) connecting to your Mac and running their apps there. On the Mac side, CrossBox will show a four-digit number in the menu bar, next to the little Oxygene icon (and on Mountain Lion or later, you will also see a Notification Center message pop up). Simply enter that code in Visual Studio on the Windows side and you are set.

You won’t have to do these steps again (unless you get new Mac or a new Windows PC or VM, of course).

Nougat can maintain a list of several Macs running CrossBox, so if you — like me — have a desktop and a laptop running CrossBox, you will see both in the menu, and can choose where to run your apps.

With that setup out of the way, open the CrossBox menu again, and underneath your Mac’s name you should now see the different device options to build for:

CrossBox Meu

  • iOS Simulator: This option, obviously, lets you build your iOS app as i386 executable that can be run in the iPhone or iPad Simulator.

  • iOS Device: This option represents a generic iDevice and allows you to build your app for deployment, even if no real device is found (you can compile, but not deploy or run when this option is selected, obviously).

  • Peter’s iPhone: Any real iDevice you have connected to your Mac will show up here as well.

For now, select your real device name, if you have one, or select iOS Simulator if you don’t.

We could build and (probably) run the application now, but lets have a quick look at some of the project options for Nougat applications before we do. For that, right-click the project node in Solution Explorer and choose Project Properties (or choose Project|Properties from the main menu).

Project Settings

Most of what you see here will be familiar from Oxygene for .NET and Java, but there’s a handful of new options.

First let’s look at the Nougat tab:

Per-config Options

There are two important options here. The first is the Provisioning Profile Name. As you can see, Nougat automatically obtained all the profiles from Xcode on your Mac already.

Every iOS app needs a profile to govern installation on devices, so it is important that you choose one here. By default, the “iOS Team Provisioning Profile: *” is a good choice; as you create other profiles manually on developer.apple.com, you can select them here.

Along with the profile goes a certificate that will be used to sign your application. As mentioned before, Xcode automatically created one for you, and to start with, your best option is to select that. Each profile is tied to a specific certificate, so as you create more profiles for real app deployment, you might or might not choose to create different certificates as well. It is important to select matching pairs of profile and certificate, or device deployment will fail.

You will notice that the settings on this page are “per-configuration”, and as you get ready to ship your app, it will be common to use different profiles and certificates for your Debug vs. your Release builds.

Two other settings on this page might be interesting.

The first is the list of Architectures. Nougat is fully capable of creating what Apple calls “Universal Binaries”, which are executables that contain code for more than one CPU type. When we started out with Nougat early this year, we thought it would be a while until anyone would see this support (since we’re not supporting 32-bit Mac apps), but Apple surprised us by introducing a new CPU type, “armv7s” with the iPhone 5′s A6 processor. So here you can choose what CPU types you want your app to support; in general it makes sense to support both, which is the default. (If you uncheck “armv7″, your application will only run on the iPhone 5 and iPad 4; if you uncheck “armv7s”, your app will run on any modern iOS device, but not fully leverage the A6 or A6X.)

The second option is “Create .IPA”, which instructs Nougat to automatically package up your app into an “.ipa” file that is ready to be uploaded to the App Store or sent to beta testers, for example via testflightapp.com.

Let’s switch over to the Application tab, which contains general project-wide options, some of which are specific to Nougat:

Per-project Options

The first crucial option is the Target SDK, which determines the version of iOS your app is built for. If you simply select “iOS” (or “OS X” for a Mac app), your app will automatically be built with the latest version of the SDK. But you can also select a specific version, for example if you always want to build your app with the older iOS 5.0 SDK, instead of 6.0.

As mentioned before, you will need a matching version of Xcode that contains the SDK you are building against.

Closely related to the Target SDK is the Deployment Target. This setting (optionally) specifies the lowest version of the OS that your app will run on. Different than what you might be used to from Windows, OS X and iOS bind very loosely, so it is entirely possible to build an application against the latest iOS 6.0 SDK and make use of new features from that OS version, and still have the application run on older versions of the OS (provided of course you are careful at runtime to not use features that aren’t available). This option enabled this, and i’ll explore some code techniques for conditionally using newer SDK features in a future article.

If you have an older device that does not run iOS 6 yet, now might be a good time to set the Deployment Target of your project to, say, 5.0.

An option that becomes important when you start creating your own provisioning profiles is the Application ID, as it will have to match the ID specified in the profile you use. The default wildcard profile we saw before will work with any ID, so if you use that, the value here does not matter (much).

There are some more advanced options such as Output type or a custom Entitlements File for code signing that go beyond the scope of this post.

Run!

So, having reviewed these project settings, your app is ready to build and run. Simply press the Start button and Nougat will do the rest; after a few seconds, you should see your app be deployed to the device and start up in the debugger.

Mac Apps

For a Mac app, things work similar, but are less complicated to set up initially.

Once again, choose File|New|Project, this time selecting the Cocoa Application template.

New Project

In the CrossBox menu, you will see only one “device” is available for each CrossBox server, and that is the Mac itself. Select the option on the Mac that you want to build and run your app on (if there’s more than one), and you’re set. As above, simply press Start and your app will build and after a few second it will pop up on your Mac’s desktop

The project settings for Mac apps are similar to those we have seen for iOS. You can pick a provisioning profile (but you only need that if you are using iCloud in a Mac App Store app), and you can (and should, but don’t need to) pick a certificate to sign your app.

Only one architecture is supported for OS X apps right now: 64-bit intel. Nougat does not support 32-bit, because, frankly, that is a thing of the past and a legacy architecture. And despite recent rumors, ARM-based Macs are probably still a few years away ;).

Summary

Hopefully this has given you a quick introduction on how to get set up and get started with Oxygene Nougat to create Mac and iOS apps. The steps outlined here are based on “Beta 2″ which we plan to have out to testers within the next couple of weeks, but most of it should already apply to the current “Beta 1″ drops that are available now.

Of course, details and the workflow might be subject to change and further fine-tuning between now and RTM next year.

How can you get your hands on the beta? Easy: If you already bought your copy of Oxygene, simply head over to beta.remobjects.com and get started now. If you haven’t, well, what are you waiting for: shop.remobjects.com.

Let us know what you think!

Avatar of marc

by marc

What is “Nougat”? — Part 4

October 19, 2012 in Elements, iOS, Mac, Nougat, Oxygene, 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 Elements, iOS, Mac, Nougat, Oxygene, 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!

Avatar of marc

by marc

What is “Nougat”? — Part 2

September 21, 2012 in Elements, iOS, Mac, Nougat

In this second part of our series on the upcoming edition of Oxygene for Cocoa, codenamed “Nougat”, i want to go into some more details about the compiler — the heart and soul of the product — and what we plan for it to deliver.

Target Platforms

As mentioned in Part 1, Nougat is a compiler for the Objective-C runtime, and will generate code on the same level as Apple’s Objective-C compiler (Clang/LLVM) does. As such it will generate (Delphi lovers, rejoice ;) CPU-native executables —a first for Oxygene — for the following three targets:

  • 64-bit Intel Mac OS X Applications
  • 32-bit ARMv7 iOS Applications
  • 32-bit Intel iOS Simulator Applications

Your first question might be “why only 64-bit for OS X”, and the answer is twofold:

One: No-one really, seriously, still creates 32-bit Mac applications. Every Mac sold has been capable of running 64-bit for way over 5 years now.

Two: Much more importantly, with OS X Leopard (that’s 10.5, which shipped, again, five years ago), Apple introduced what is commonly referred to as the “modern” Objective-C runtime. This is a newer, better version of the runtime that Cocoa apps run on, and many advanced features, such as ARC, are only available on that new runtime. This “modern” Objective-C runtime, you guessed it, supports the above three platforms, but it does not support 32-bit Mac OS X.

We could go out of our way to support the older runtime, but the current thinking is Nahh, it won’t be worth the hassle. If nothing else, the lack of ARC would be a major bummer.

Automatic Reference Counting

As you might have guessed from the above, Oxygene supports and fully embraces ARC, the Automatic Reference Counting model Apple introduced at last year’s WWDC. In fact, we’re so sold on ARC that we’re planning to make it non-optional.

For those unfamiliar with the matter, what does ARC mean? ARC means that the compiler automatically keeps track of reference counting for you. Under the hood, Objective-C uses a retain/release model for keeping track of object lifetimes (similar to COM and Delphi Interfaces). When wanting to hold on to an object, it used to be you’d call “retain” on it. Once you were done, you’d call “release” (and there’s the concept of autorelease pools which sweetens this memory management model some more). With ARC, you don’t have to (in fact, you cannot) keep track of retain/release — the compiler handles all of that for you.

The end result is that memory management is pretty much taken care of for you, and the kind of code you write in Nougat will be comparable to what you do in the Garbage Collected .NET and Java environments (although ARC is not garbage collection, but deterministic memory management).

Auto-Boxing

Like most platforms, Objective-C (due to its roots in C) has both simple types — such as integers, booleans, C-style zero-terminated strings — and class-based types that can represent the same kind of data.

Staying in line with its counterparts for .NET and Java, where such a thing is common and expected, “Nougat” will automatically handle boxing and unboxing for numbers, string and arrays.

For example, you can simply write 5, and the compiler will take care of converting that int to and from an NSNumber for you, when boxing is needed. For example, you can write

var x := 5; // "x" will be an Integer.
myDictionary.setValue(x) forKey('five');

or

var y := NSNumber.numberWithInt(5); // silly, i know.
z := y+5; // "y" will be unboxed.

In a similar fashion, string literals and C-style strings and NSString will be interchangeable, with the compiler doing the right thing for you.

References

As a native Cocoa compiler, Nougat will need to let you reference other frameworks and libraries — be it the core operating system frameworks provided by Apple (such as Cocoa, UIKit, MapKit, you name it) or third party (or even your own) frameworks and libraries.

As mentioned in Part 1, Nougat is no bridge, and requires no mappings to be defined. Rather, Nougat directly understands and consumes the exiting Objective-C frameworks — just like you would expect, and just like Oxygene does on its other two platforms.

Now, Objective-C frameworks and libraries don’t have the rich meta data that Oxygene is used to — they are just binaries with compiled code, and C-style header files. Because parsing C (and Objective-C) headers is a time-consuming and inefficient process, Nougat introduces an intermediary format, which we call “.fx Files” that the complier references. .fx files are generated automatically by a tool that comes as part of Nougat, and you can think of them as something like pre-compiled headers — a binary representation of all the definitions found in a framework’s headers.

Nougat will come with pre-created .fx files for the major OS versions we’re supporting (right now the internal alpha drops provide OS X 10.6, 10.7 and 10.8, as well as iOS 5.1 and 6.0), so the compiler (and the IDE) is ready for you to use those frameworks right from the Go. But if there’s a new OS (or beta) coming out that you want to use, it will be as easy as a single click to get that new SDK exposed to Nougat — no need to wait for the NDA to expire and/or us to ship updated support.

How does this look/work from the developer’s point of view? Simple. Just as always, you’ll go to Add Reference to add a new reference to your Oxygene project. The IDE will show you a re-filled list of frameworks in the SDK your current project is targeting (say, OS X 10.8), and all you have to do is, say, pick “CoreLocation” from the list, and you are ready to use the APIs exposed there.

Objective-C itself does not use or know namespaces. For Nougat, types and other external definitions will automatically be partitioned into namespaces based on the frameworks they come from. So, for example, your code files might have uses UIKit, CoreGraphics; in their uses clause, and your code will automatically have all identifiers from those frameworks in scope. If you want to use a class that’s not in scope, you can always prefix it with the namespace, just as you’d expect, i.e.

CoreLocation.CLLocationmanager.startUpdatingLocation();

Part 3

Testing and deploying applications in Nougat. . .

Avatar of marc

by marc

“Native platform development is going to be the approach”

September 12, 2012 in Android, iOS, non-tech

Mark Zuckerberg about the new native Facbeook app (via Appleinsider, The Verge):

“Native [platform development] is going to be the approach that we go with for iOS and Android”. “We’re betting completely on it.”

Smart thinking, and much in line with our own philosophy on the matter.

He goes on:

“The biggest mistake we made as a company was betting too much on HTML5 instead of native [platforms],” and, “We burnt two years.”

Avatar of marc

by marc

What is “Nougat”? — Part 1

September 12, 2012 in Elements, iOS, Mac, Nougat

When we launched our new Oxygene website and Oxygene 5.2 last week, we also gave a sneak peek at an upcoming new edition/platform for Oxygene, codenamed “Nougat“.

This is the first in a series of posts about “Nougat”, in which i want to go into a few more details about our plans and the technologies behind Nougat, so you can get a feel for what to expect from the product, as we wait for the first beta to be made available.

So what, exactly, is Nougat?

Nougat is a third independent target for the Oxygene language and compiler, targeting the Apple Cocoa and Cocoa Touch development platforms.

More strictly speaking, Nougat is Oxygene for the Objective-C Runtime.

What does that mean?

Similar to Java, the term Objective-C has overloaded meanings. Of course there is Objective-C, the language, which is what most people think of when they hear the name. It’s the language that Apple’s Xcode IDE uses to let developers create native applications for both of its platforms: (Mac) OS X and iOS.

But underneath the language (and to a large degree influencing how Objective-C as a language works) lies the Objective-C Runtime (OCR, for short). That runtime (oversimplified, a set of C APIs) defines how objects look in memory, manages run-time type information, handles the passing of messages (a.k.a. method calls) to objects, and so on.

The way i like to think about it, the Objective-C runtime puts Cocoa someplace in the middle of “managed” platforms (such as .NET and Java) and “unmanaged” development architectures such as Delphi or C++. So when talking about this, i often call Objective-C “half managed”.

“Nougat” brings the Oxygene language to this Objective-C runtime, in that it compiles Oxygene language code into objects that natively live in this runtime, and seamlessly interact with other objects in the same runtime. It is not a “bridge” (such as MonoTouch, RubyCocoa, or the (now deprecated) Java/Cocoa Bridge, but a fully native second language — in no way second to the Objective-C language itself — that runs on this runtime.

This is important for several reasons:

You’re creating true Objective-C objects

The classes your define in your Nougat application will compile down to true OCR objects. The runtime will see these objects and interact with these objects in the same way that it does with objects created by an Objective-C developer in Xcode. In fact, the runtime cannot even tell them apart.

When you, say, define

type
  RootViewController = class(UITableViewController)

then this “RootViewController” class you are defining will be a true descendant of UITableViewController — with no bridging magic inbetween. If the table view sends a cellForRowAtIndexPath: message to get data to display, the runtime will dispatch that call directly to the cellForRowAtIndexPath() method that you hopefully implemented.

You’re interacting with true Objective-C objects

Just like your classes are true Objective-C classes, all the classes and object instances you interact with will be true Objective-C classes, as well. If you hold a string object, that’s a true NSString instance, and if you are calling

myString:hasPrefix('foo')

you are simply sending the object the hasPrefix: message, just as an Objective-C developer would be with [myString hasPrefix:@"foo"]. (Note that Objective-C’s message sending is nil-safe, and thus corresponds to Oxygene’s colon operator, while a call such as myString.hasPrefix('foo') would throw an exception on nil calls, as you would expect from Oxygene code.)

No awkward manual mappings

Just to be completely clear, there is no manually defined “mapping” between APIs defined in Cocoa and the APIs Oxygene sees (or vice versa), as there is in most Cocoa bridge solutions. There’s no magic table in Oxygene that tells the compiler how to match a call to hasPrefix('foo') to the right method on the NSString.

The Oxygene compiler, instead, simply has full direct knowledge of the Objective-C APIs and does those calls directly — just as Objective-C itself would: it takes the name, packs it up in a selector, and calls the OCR’s objc_mmsg_send() function.

In fact, if you have a variable of type dynamic (or, aliased to that type, id), Oxygene will let you make just about any known method call on that object, just like Objective-C does.

Beautiful Cocoa-style method calls

This also means that Oxygene has full support for Objective-C’s more verbose method naming convention — something that is crucial, really, as a developer would want to interact with the Cocoa APIs as they have been designed and intended (for better or for worse — i personally find Cocoa beautiful).

I purposely picked a simple and uncontroversial example with hasPrefix: above, but what Cocoa APIs are known for are of course the infamous “muti-part” method names, where the method name reads like a sentence with the individual parameters interspersed in between. Consider for example stringByPaddingToLength:withString:startingAtIndex:. How would you call this in Oxygene?

Most bride-based solutions go for one of two options: they would either provide an (often overloaded) method named after just the first part, e.g. stringByPaddingToLength(20, " ", 5) or they would concat the entire name into one big chunk of text, such as stringByPaddingToLengthWithStringStartingAtIndex(20, " ", 5).

For one, yuck. For another, this would require manually crafted mapping tables, which Oxygene does not use — as explained above, Oxygene just handles the Cocoa APIs, any Cocoa APIs, straight up.

So how do you call this method in Oxygene? Simple:

myString.stringByPaddingToLength(20) withString(' ') startingAtIndex(5);

Simple, elegant, and it preserves the “readable as a sentence” aesthetics of the underlying API. What’s more, the syntax seamlessly works with any method an OCR object might declare.

The same goes, of course, for declaring methods in your own classes — both when implementing things such as delegates, but also when designing your own class APIs in Cocoa style:

method stringByPaddingToLength(aLength: Integer) withString(aString: String) startingAtIndex(aStartIndex: Integer);

What’s Next?

With this first post, we have only just begun to scratch the surface of “Nougat”. Stay tuned for more in this series over the next few weeks.

Oh, and be sure to buy or renew your copy of Oxygene now to be among the first to get access to Nougat when the beta hits early next month.

And let us know what you think in the comments below!

See also part 2 . . .

Avatar of marc

by marc

The new Oxygene website (Oh, and some exciting new Oxygene announcements, too)

September 6, 2012 in Elements, iOS, Mac, Metro, Nougat, Platforms, Visual Studio, Windows

Yesterday, we launched the major revamp of our “Oxygene” product homepage, available at remobjects.com/oxygene, along with announcing the 5.2 release, a significant update to the product.

Let’s have a quick tour of the new content.

What’s New in 5.2

First, and most importantly, there’s the updated What’s New page, updated to list the new features in 5.2 and providing back access to previous release notes as well.

5.2 introduces some significant (and dare i say ground-breaking) improvements to error handling, with better fix-it support, auto-fix-its for select (safe to fix) issues and — my personal favorite – the new Treat Fixable Errors as Warnings, which can be an enormous timesaver if you just wanna code and test some quick changes. Of course there’s much more to 5.2 — such as our new IDE-integrated Gendarme Code Analysis, support for language-native tuples, Visual Studio 2012, Metro, and more.

Nougat

Next to 5.2, the second biggest announcement has been the first peek at “Nougat“. Nougat is the codename for a new (third) platform for Oxygene, namely Cocoa and the Objective-C runtime for creating truly native Mac and iOS apps. Right now it is just a teaser — we’ll be releasing more details about “Nougat” here on the blogs over the next few weeks.

The good news is that “Nougat” is already part of our new Oxygene shop SKU — so anyone buying (or renewing) Oxygene now will be among the first people to see the Nougat beta (roughly within the next month) and get the final product when it ships in 2013.

We’re very excited.

The Language

The new website also contains a sizable new section focusing on the Oxygene Language and its Object Pascal heritage. We have five pages detailing the most exciting language features. We also have an overview of Oxygene evolved over the years (even i rediscovered cool features i had forgotten about, as i wrote this page ;), and Jim has written an excellent history of the Pascal Language since the 1960s, including a cool diagram that shows how it all fits together:

History of Pascal

The Platforms

Finally, there’s a new section that looks at Oxygene from the perspective of target platforms. With the introduction of Nougat, Oxygene now literally covers every single major target platform that matters today — from desktop and mobile to the server. The Platforms page serves as a central point to discover all the possibilities Oxygene opens up, and for most platforms, links to a dedicated “platform hub” page with details, links and videos about using Oxygene for the platform.

Jim has also created an excellent new WPF Development with Oxygene video to go along with the “Windows Desktop” platform, which, oddly, was underrepresented in the video department.

We expect this section to grow and expand over time, with more potential targets added, and the information for each target getting more comprehensive.

One More Thing: Sugar

Hidden away on the page about the three supported core Frameworks, you’ll find another sneak peek at something we are working on: an open source cross-platform base library for Oxygene, built on the awesome Mapped Types feature introduced in Oxygene 5.1.

Having a cross-platform language such as Oxygene is great, and one of Oxygene’s strong points is that it targets the platform-native APIs on each platform. The downside is that even the base types — simple stuff such as Strings or Dictionaries — can vary widely between platforms, making it tough to share code of any reasonable complexity.

The goal of “Sugar”, which is the codename of this project, is to create a toll-free mapping library that will allow Oxygene developers to write common code that will compile for all three platforms and work with the platform’s base types using a shared API.

This is even cooler than it sounds ;)

The Shop

Before we forget: of course the new Oxygene 5.2 is available now at $499 for new users — that includes all three platforms. Users coming from Prism XE2 (or our own Oxygene for Java) can renew for $349 — which also includes all three platforms.

We also have cross-grade pricing for users of Delphi. If you currently use Delphi, you can cross-grade to the full Oxygene package (again, you guessed it, all three platforms) for $399.

Let us know what you think!

Over the past month or so, we have put a lot of work into the new website. Let us know what you think, like, dislike, or are missing.

Of course even more work and sweat has gone into Oxygene 5.2 (in my humble opinion our most solid release yet, and i am very proud of what the team has delivered), and work already continues to go into the upcoming September and October interim releases, and towards “Nougat”

If you haven’t yet, try Oxygene — we have a free 30-day trial version for the .NET and Java editions. We hope you like what you see, and please do let us know what you think!

yours,
marc

Avatar of marc

by marc

Comparing Data Abstract and Core Data (with and without iCloud)

August 6, 2012 in Data Abstract, iOS, Relativity, Xcode

People often ask us what the difference between Core Data and Data Abstract is, and why they should choose one over the other.

The answer to that second question frequently is “it depends”, because while on first glance Core Data and Data Abstract might seem like technologies that solve the same problem (“database access”), they are actually quite different technologies, and designed with very different goals.

Core Data is, in essence, a local data access technology and ORM. It is designed around the concept that your application has a certain data model, expressed as a suite of objects, and wants to persist that data between runs (or to save runtime memory footprint), locally. As such, Core Data is largely a front-end for SQLite (although it supports other storage options) that abstracts the developer from dealing with the actual database storage, table structure, and SQL queries, and exposes data as regular in-memory objects that magically persist.

Don’t get us wrong, that is an awesome feature for many scenarios, and Core Data is a great solution in that space.

Data Abstract on the other hand is designed around the concept of data stored on a “big” server somewhere on the network, off your iDevice or Mac, or “in the cloud”, and that the database on this server (or these servers) contains data that is shared between many users of the application (which of course does not mean that each user cannot have their own private set of data).

These servers could be anything, from an existing database in a large Oracle cluster that already provides the backbone for an enterprise, to a fresh database you just designed solely for your iOS app. The target application could be anything from — say — a view into said enterprise’s customer relations system, over an iOS front-end to your web site, to the client app for the next Social Network you are building.

To achieve this, Data Abstract is build around the so-called Multi-Tier concept, where the client applications you build using Data Abstract talk to a “middle tier” server that enforces data consistency and access restrictions.

 

The central difference between Core Data and Data Abstract is that the former is focused around simplifying how an app can persist its application state locally, while the latter is designed around accessing, presenting and working with data that exists elsewhere, usually (but not necessarily) in a context that is much larger than an individual application and an individual user.

So Core Data and Data Abstract aren’t really that much in competition, but target pretty different scenarios. In most cases where Core Data is a good solution, Data Abstract would be overkill or even useless, and in the cases where you need what Data Abstract provides, Core Data won’t do much good.

But What About Core Data in iCloud?

On first glimpse, it might seem as if the new Core Data Syncing via iCloud expands Core Data onto Data Abstract’s turf. And to a certain degree that is true; iCloud certainly expands what you can do with Core Data, but there are still some pretty severe limitations.

When Steve Jobs took the stage at WWDC in 2011 to announce iCloud, he gave the reason why iCloud was going to be better than previous syncing technologies: Rather than syncing information between devices he said that with iCloud the “truth, is in the cloud”, and each device — iOS or Mac — syncs against a well-known set of data in that single location.

That is the right way to do it, and that is how iCloud works in general, but: it is not how Core Data syncing via iCloud works, unfortunately.

At the time of this writing, Core Data syncing via iCloud consists of each client storing change logs in the cloud and these diffs getting transferred between devices. In other words, iCloud syncs Core Data between devices, without a single truth “in the cloud”. As Drew McCormack has outlined in his excellent series of articles on the topic, this comes with a myriad of problems, caveats and corner cases to look out for.

This is, of course, in sharp contrast to how data access with a multi-tier solution such as Data Abstract is handled. Data Abstract’s model (or any other database-centric multi-tier architecture) does put the truth in the cloud, just as Steve Jobs suggested it should be.

Another crucial limitation of Core Data is that any data it stores in iCloud is still an island: it can only be accessed by the applications that created it, and is isolated per user. That is fine for many scenarios (e.g. in cases where you’re 100% focused on in-app presentation), but imposes some serious limitations, such as:

  • not being able to provide a web-based front-end to user’s data outside of their iOS apps.
  • not being able to provide access to the user’s data on iOS/Mac on the one side, and client applications on other platforms (be it Android, Windows, or even just non-App Store Mac) on the other.
  • not being able to offer options for users to share data among themselves, or share data publicly.

Also, the fact that data is self-contained within each user’s store means that as the application developer, you have no access to it, for example to investigate if users are reporting problems. On the one hand, this is a win for user privacy, as users only need to trust Apple with their data, not you as the App Vendor, but on the other, it severely limits what apps can do and how you as an app developer can trouble-shoot or assist users when they have problems with their data.

So, Which Option Should You Choose?

Indicators that Core Data is the right solution would be:

  • You have a fairly straightforward data model and not more data than can easily it on the device.
  • Your data is internal to the application, and you never want to use it outside of the app (aside from, say, letting the user explicitly export it).
  • Your entire data is tied to a single user and you have no need to share (part of) the data between different users of your app.

Indicators that you might want to use Data Abstract include:

  • You are building a front end to already existing data managed in a database (e.g. an app for your Enterprise database).
  • Your app’s data is part of a larger data infrastructure shared (in parts) by all or some users of your app.
  • Your app’s data should be accessible (in parts) outside of the application itself, for example via a web site.
  • Your app’s data should be available on platforms not covered by iCloud, for example Windows or Android clients.
  • Users of your app should be able to share (parts of) their data, whether explicitly or implicitly.
  • Your application contains shared data common to many or all users.
  • You want or need full control and access to the data and how it is stored.

The one advantage of Core Data, of course, is that it works “out of the box” with just the user’s devices, and (optionally) iCloud, and you do not need to worry about setting and maintaining any database and server yourself.

If your application can live within these constraints, that can be a significant saving in both cost and management effort. But in most cases, you either need the extra flexibility of hosting the data yourself, or you don’t — and if you do, Core Data and iCloud give you absolutely no wiggle room and hosting your own data will be the only solution.

Data Abstract makes that easy and cost efficient too, and with our free Relativity Server that can be hosted on just about any co-located server and on many cloud services, such as Amazon EC2, you can be up and running with your own hosted middle-tier quickly.

Interested?

If this got you interested, please check out some of our other resources on Data Abstract for Xcode (and for our other platforms) to see what DA can do for you and how to get started.

In particular, i recommend reading the first available chapters of our “Data Abstract for Xcode Book” and to check out the videos on RemObjects TV, especially Introduction to Data Abstract for Xcode narrated by yours truly and Relativity Server Overview.

And of course we have a free 30-day trial versions of Data Abstract for all platforms.

We hope you will find Data Abstract useful — and don’t hesitate to contact me directly or our support team if you have any questions.

— marc