You are browsing the archive for Nougat.

Profile photo of marc

by marc

Two Major Announcements Today, here at RemObjects

July 24, 2014 in "Silver", Cooper, Echoes, Elements, Fire, Nougat, Oxygene, RemObjects, RemObjects C#

Today is a day I’ve been looking forward to for a while. Why? Because today we officially announced two major projects that I am really excited about, and one of them is a project I have been working on for a long time that — as of today — is in the hands of thousands of Elements developers.

So First, Fire.

I cannot overstate how excited I am about Fire. I started working on this project almost two years ago, as a side/weekend project. It evolved slowly at first, and then began picking up speed and came to the point where — much sooner than I had expected — it had become usable. Late last fall, Fire was promoted to be an “official company project”, this spring, it went out to less than a handful of very dedicated external testers. And today, while still considered Beta, it’s being made available to every Oxygene and RemObjects C# user as part of their active subscription.

What is Fire? I am glad you asked.

Fire is a Mac native app, and it’s a place to go to cook up great apps. If you want to use less fancy terms, you could also say that Fire is a new IDE for Oxygene and RemObjects C# that runs on Mac OS X.

My reasons for starting work on Fire where two-fold.

One, I’ve been a Mac user for a long time now (since 2007), but I’m always keeping a Windows VM around to do what? To run Visual Studio. I really wanted to break out of that and develop in Oxygene (and more recently RemObjects C#) directly on my Macs. On my laptop, a VM is way too much overhead, so I never bothered installing one; but even on the desktop, it’s annoying to always have your IDE in a “box”.

Two, while I (kinda) like Visual Studio and love Xcode, I’ve had my own ideas about what would make an IDE great, and I wanted to put those in practice. For version 1.0 those mainly revolve around lightweightness and the IDE not getting in my way. Beyond 1.0, I (and all of us) have more radical ideas.

Fire is the fulfillment of both of those dreams. Since early this year, I have been using it exclusively for all my Elements developing tasks and — if you’re a Mac user — I hope you will be as well, starting today.

You can read more about Fire at remobjects.com/fire, and I’ll also be talking about it more, and going into features in more detail, in future blog posts.

Second, Silver

But just one announcement would be boring, right? That’s why we have two. Today, we also took the wraps off another project we have been cooking up — this one not quite so long, but for about a month and a half.

As you probably know, last month at WWDC, Apple announced Swift, their new programming language for Mac and iOS. We started digging into Swift immediately, and really liked what we saw. So much in fact that we thought about what would be involved in bringing Swift into the Elements language family as a third member. And we didn’t just think about it, we put Carlo to work on it immediately as well.

So today we’re pre-announcing “Silver”, which is our project to do just that. “Silver” will bring the Swift language to Android/Java and .NET developers (and it will work on Cocoa too, for completeness sake). In essence, any place where you can use Oxygene or RemObjects C# now, you’ll be able to use Swift as well. And it will of course work in both Visual Studio and Fire.

While “Silver” is already working pretty great internally, we don’t have a public preview quite yet — but we will soon. You can leave your email with us on the “Silver” home page (below), and we’ll keep you in the loop.

You can find more info on “Silver” and sign up at remobjects.com/silver.

Exciting times are ahead. Let us know what you think!

Profile photo of marc

by marc

Using iOS 7.1 SDK with RemObjects C# or Oxygene

March 11, 2014 in Elements, Nougat

As you’ve probably seen, iOS 7.1 is out — and with it, a new SDK. Anxious to use iOS 7.1 with RemObjects C# or Oxygene? No problem. our Importing a New or Beta SDK for Use with Elements for Cocoa article on the wiki explains how to do it:

Launch FXGen by right-clicking CrossBox:

Once you have downloaded/updated to Xcode 5.1 from the App Store, find the Xcode.app in in your /Applications folder and drag it into the app:

Select iOS 7.1 from the dropdown:

Click “Start Import”

FXGen will run a for a short while, and then you have .fx files for the iOS 7.1 SDK you can use. Just copy them to the “C:\Program Files (x86)\RemObjects Software\Elements\Nougat\SDKs” folder in your PC or VM, and you’re off running.

Of course these same steps will also work for importing beta SDKs (which we won’t be able to tell you about, because of NDAs) – for example when Apple starts seeing iOS 8.0 or the next version of OS X later this year. This way, you can start working with the cool new stuff right away — without having to wait for anyone to create wrappers for you.

It goes without saying that now that iOS 7.1 is officially out, our next release (and Friday’s upcoming beta) will include the .fx files for iOS 7.1 out of the box.

Enjoy,
marc

Profile photo of marc

by marc

Announcing the Oxygene “October 2013″ Update

November 4, 2013 in Elements, iOS, Nougat

Dear readers,

we may be a day late and into November with this announcement, but we’d like you to know that the “October 2013″ update for Oxygene has been made available earlier this week.

What’s New

The October update is mostly a bug-fix release, but it also includes a couple of rather significant new features on the Cocoa front.

Most importantly, this release officially introduced 64-bit ARM support for the Apple A7 chip in the new iPhone 5S and the new iPads that came out today. Last month we laid a lot of the groundwork with 64-bit compiler support, but now [you can build](http://wiki.oxygenelanguage.com/en/Architectures_(Cocoa) your apps for your devices in 64-bit mode, as well. Very exciting.

We have also started officially shipping .fx files for the new Mac OS X 10.9 “Mavericks”, and we’ve extended the Cocoa compiler to support the new “instancetype” feature introduced/mainstreamed for Objective-C by the iOS 7 and OS X Mavericks SDK.

And of course there are a good 100 additional fixes and improvements in this update, across all three platforms.

How to get Oxygene 6.1.57

As always, this release is a free update to all active subscribers, and can be downloaded now.

If your subscription has elapsed, now is a great time to renew to get access to the latest release and all the good stuff we have cooking for the near future.

Oxygene for Prism Customers

Remember that Oxygene 6.1 is also the first release that is no longer available from Embarcadero under the Prism brand, and it will not accept Prism XE3.2 serial numbers. But as a reminder: we are committed to honoring SA contracts Embarcadero might have sold you with the promise of Prism coverage (i.e. before April 23, 2013). Please email sales@remobjects.com with your SA details, and we’ll sort you out with ongoing access to Oxygene for .NET for the remainder of your SA period. (You can read more about this here).

Of course, if you do not have SA, or if you want to take advantage of Oxygene on the Cocoa and Java/Android platforms as well, you can always renew or cross-grade to the full Oxygene package at any time.

More to Come

2013 is drawing to a close, but we’re not done yet. We’ve got one whopper of a release planned for the end of this month (and lots of cool stuff are coming in 2014 as well). So make sure stay up to date with your subscription.

Happy coding!

Profile photo of marc

by marc

“Steps” for iPhone 5S — written in Oxygene

October 30, 2013 in Elements, iOS, non-tech, Nougat


Steps

I’m more than thrilled to let you know about “Steps“, my next/new iOS app.

Steps is a small but helpful app, which works exclusively for the new iPhone 5S, because it uses the new M7 chip that Apple has introduced with the 5S to gather motion data and let you know how many steps you are taking each day.

Whether you’re interested in that to keep track of your daily workout, or just want a fun way to explore this cool new feature of your iPhone — Steps is a great way to do it.

On first launch, Steps gathers up to 7 days of previous walking history. That’s right — Steps (or rather, the M7 chip ;) has been hard at work for you even before you bought it! So you have some data to look at immediately.

In addition to showing your daily step count, Steps (new in version 1.1) also aggregates your average daily steps for the past week and month, and it will keep track of what your personal best has been, so far — including encouragement to beat it, when you get close.

Over time, and without you ever having to think about it again, Steps will update to load in more data as you roam about, all the while keeping track of your past history. Eventually, you’ll have months and months of walking data to look at. You don’t need to launch Steps manually for this to happen (although you will want to launch it to have a look once in a while).

And because it uses the new M7 chip, Steps can do all of this without affecting your iPhone’s battery life at all.

 

It goes without saying that Steps is written 100% in Oxygene for Cocoa. And as with all my previous Oxygene iOS projects, full source code is available on GitHub at github.com/dwarfland/Steps.

So, if you have your iPhone 5S yet, make sure to grab your copy of Steps on the App Store, for only 99c. And if you’re a developer, make sure to check out the code, as well!




Originally published on subspacecables.com.

Profile photo of marc

by marc

An update on Oxygene support for iOS 7 and arm64

September 13, 2013 in Elements, iOS, Nougat

Over the past couple of days, unsurprisingly, a lot of people have asked me about our plans for supporting iOS 7 and – more specifically – the arm64 architecture used in the new iPhone 5S.

Of course the news is good.

General support for iOS 7 on armv7 and armv7s (the current CPU platforms in iPhone 5 and older) has been in Oxygene since forever. We don’t ship .fx files for iOS 7 yet (that would have been a violation of Apple’s NDA, as long as iOS 7 was in beta), but Oxygene comes with a tool that lets you generate those files yourself with a single drag and drop for any beta SDK (including iOS 7 and OS X 10.9, a future iOS 7.1, etc). The July release also included additional fixes to make the import for iOS 7 more seamless.

So in general, Oxygene has been ready for iOS 7.0 for a while now, and i know that a lot of you have of course been using the two together, as have i myself for some of our internal apps (and in fact our Beta.app is already in the App Store, ready for iOS 7.0).

Of course, this support only extends to 32-bit iOS – which, to be clear, is fine and good enough to build and submit iOS 7 apps, including those that will run on the new iPhone 5S, today. (You’d want to extensively test your apps on the device before submitting 64-bit versions, anyways.)

So what about 64-bit?

Obviously, we only learned about the new A7 chip being 64bit alongside with the rest of the world outside of One Infinite Loop only yesterday. So work is needed for Oxygene to support the arm64 architecture that drives the CPU in the iPhone 5S.

We’re on that, and we don’t expect it to be a big deal, because Oxygene (a) builds on the open source LLVM backend, which does the bulk of the work for supporting different hardware architectures (and operating systems) and (b) is designed from the ground up for multiple architectures, and for creating universal binaries (that is, executables that contain code for more than one CPU). In fact, you’ve already been building those, if you build for armv7 and armv7s – 64bit just adds a third, albeit more different, architecture.

So mostly, we’re talking minor tool chain adjustments and improvements, as well as extensive testing.

  • The .fx import (mentioned above) has been updated to support arm64 yesterday and is done, pending testing. The .fx files now have three architectures for iOS: armv7/armv7s/arm64 and a dual-architecture for the Simulator: i386/x64. That’s right — there’s a 64-bit Simulator, as well.

  • With these new .fx files, arm64 will automatically show up as platform to build for in the IDE, and the compiler and the rest of the IDE toolchain will automatically pick up 64-bit support for your iOS projects. (There are new Conditional Defines you can use to test for bitness, such as __arm64__ on device and _x86_64__ on Simulator.)

  • The IDE and build chain does some magic with regard to building for the Simulator. In particulate, you never explicitly choose a Simulator SDK or i386 as architecture; instead, you configure your project for the iOS SDK and the ARM architectures you want, and if you build for Simulator, the build chain (and IDE smarts such as Code Completion) automatically switches over to the Simulator SDK, and to i386. The logic here needs to be refined to include _x86_64 if your app is built for arm64, so that you can build 64-bit Simulator apps. The devil is in the details (and it’s kind of funny that the compiler is ready to build 64-bit Simulator apps already, if only the toolchain would ask it to ;)

  • No use building 64-bit Simulator apps if you can’t run them – so we need to expose an option in the IDE to let you choose different Simulator versions (not just iPad vs. iPhone, but also bitness, and while we’re at it, Retina vs. Non-Retina iPad, and iPhone screen size).

  • The actual arm64 compiler backend needs to be tested. It’s been in the LLVM code base for a while, but we have not used it ourselves yet. So we need to test it against our Oxygene front-end and make sure all works well. Of course Oxygene already does x64 support on the Mac side, so we’re fairly confident. (64-bit support in the Simulator is pretty much identical to the existing Mac support; it uses the same x86_64 back-end, but it is, officially, a different platform/operating system combo).

    Rumor also has it Apple has extensions to LLVM that aren’t published on the open source LLVM yet. It remains to be seen, possibly not until we have actual hardware, whether those extensions are crucial to have for compiling working iOS arm64 apps, or whether they are just icing on the cake that is the existing LLVM arm64 support that’s already public.

None of these are hard problems, just stuff that takes a day or two to do well (for example, i thoroughly refactored and abstracted the Train script that drives the .fx import in FXGen, as part of adding arm64 support to make the architecture handling much nicer and more flexible for the future).

When?

We don’t want to make any promises (especially since final/real testing will depend on me getting hold of an iPhone 5S in a timely fashion to have test hardware, and with Apple not doing pre-orders this year, i guess that means i’ll be queuing up at the Apple Store here in Berlin again, next Friday ;), but we’d like to ship official arm64 support in the September update at the end of this month.

We’ll also try to get as much support as possible (untested on real hardware of course) into the next beta drop. At the very least, this will include the full .fx files for 64-bit, and it’s pretty likely to include 64-bit Simulator support, as well.

That said, remember that arm64 is not crucial for building iOS 7 apps. You can (re-)build your apps against iOS 7 now (i have been since mid-June), and submit those as armv7/arm7s. They will run fine on iPhones 5S, too. Once we do have arm64 support fully finalized, you can rebuild them with the extra architecture enabled.

As mentioned before, even if we had arm64 support ready this very second, it’d be pretty foolish to submit your 64-bits to the store before you can test them on real 64-bit hardware. More so, given that your apps will get little benefit from being 64-bit until you had the chance to properly extend and design them to take advantage of the platform. So we think our timeline should work well for you.

Beta Access

Remember: All Oxygene users with active subscriptions have full access to our beta releases, which give you early access to cutting edge stuff such as this. Visit the Beta Access page on our wiki for details, and make sure to install our Beta.app (linked from the same page) to stay in the loop with new builds.

Now, i’m sure you have iOS 7 apps to build and submit to the App Store, so i’ll leave you to it…

Profile photo of marc

by marc

Duck Typing in Action

July 31, 2013 in .NET, Cocoa, Cooper, Elements, Nougat

I came across a really awesome use of Duck Typing yesterday, and i wanted to share this with you, since i think Duck Typing is one of those features in Oxygene that are incredibly powerful, but underrated – probably even unknown to many users.

This is actual code that is live on our website, and it’s driving the downloads lists for licensed products and betas.

Both download pages are driven by the same .ascx, which runs a query to get the products a user has access to, and then compares it to the available downloads (passed in as aFiles), to determine what files to show. The code looks something like this:

method DynamicDownloadList.PrintProductFiles(aFiles: sequence of BetaFile; aBeta: Boolean);
begin
  if aBeta then begin
 
    var lProducts := from p in DataAccess.Linq.GetTable<ByUser_BetaProducts>(...) 
                       order by p.DisplayOrder;
    // loop and print out files
 
  end                                    
  else begin
 
    var lProducts := from p in DataAccess.Linq.GetTable<ByUser_LicensedProducts>(...) 
                       order by p.DisplayOrder;     
    // loop and print out files
 
  end;                                    
 
end;

The code that i’ve abbreviated behind the “//loop and print out files” comment was actually just 5 lines, but it was mostly identical for both beta and final downloads. I still had to duplicate it, because the two LINQ queries, of course, returned sequences of different types. Which is kind of a bummer, if you think about it – these are two queries (actually, Data Tables defined in the DA server that apply quite a bit of complex logic) that return the same kind of data, but due to the way LINQ works, because they are different tables, the resulting objects are of different classes.

So even though both ByUser_BetaProducts and ByUser_LicensedProducts contain fields like ProductID, Name, ImageName, and so on, it’s not really easy to write code that can be shared and work against either version. (To boot, these classes are auto-generated by LINQ, so it’s not like i can just add a common interface to the ancestry list, either.)

Yesterday i set out to expand the logic for the download display a bit (in particular to improve how the unified “Oxygene” download shows for people who own all three platforms), and i found the duplicate code turning too complex to stay duplicated. Sometime it’s fine to copy/paste 3-5 simple lines of code into two places, but this was getting more sophisticated than i liked sharing and maintaining in two places.

Duck Typing to the rescue!

So what i needed to do was write code that could work on two classes that have no common ancestor and no shared interface, but look “similar”. Exactly what Duck Typing was made for!

First, i went ahead and declared the following interface:

type
  IByUserProducts = public soft interface 
    property ProductID: System.Guid read;
    property Name: System.String read;
    property ImageName: System.String read;
    property OptionalMessage: System.String read;
    property DateExpires: nullable System.DateTime read;
  end;

that defined all the members from the query i needed access to.

Next, i adjusted the LINQ code just ever so slightly:

method DynamicDownloadList.PrintProductFiles(aFiles: sequence of BetaFile; aBeta: Boolean);
begin
  if aBeta then begin
 
    var lProducts := from p in DataAccess.Linq.GetTable<ByUser_BetaProducts>(...) 
                       order by p.DisplayOrder 
                       select duck<IByUserProducts>(p, DuckTypingMode.Weak);
    // loop and print out files
 
  end                                    
  else begin
 
    var lProducts := from p in DataAccess.Linq.GetTable<ByUser_LicensedProducts>(...) 
                       order by p.DisplayOrder 
                       select duck<IByUserProducts>(p);
    // loop and print out files
 
  end;                                    
 
end;

The only thing i changed is that at the end of the from clauses i added an extra select operator to change what the LINQ query returns: duck-typing the specialized class returned from DA into the custom IByUserProducts interface i declared.

Now, instead of returning sequences of ByUser_BetaProducts and ByUser_LicensedProducts respectively, both queries return the same type: a sequence of IByUserProducts.

This, in turn, means that i could take all the code from “// loop and print out files” and move it into a separate function, called from both branches.

Presto: shared code!

DuckTypingMode.Weak

If you’re eagle-eyed, you might have noticed that i’m passing DuckTypingMode.Weak to the duck() function in the first branch, but not the second. What does that do?

Simply put, i lied when said that the two queries returned the exact same set of fields. In fact, the query for release products returns a few extra fields, including the expiration date (which i need to gray out newer downloads if a subscription expired – in contrast to beta downloads, where the whole product just disappears).

DuckTypingMode.Weak allows the duck typing to IByUserProducts to succeed, even though the underlying class does in fact not fully qualify for the interface, because it’s missing the DateExpires property. Oxygene will instead inject a stub that will throw an exception if DateExpires were to be called.

But that’s fine. All i need to do in my now shared code is check the aBeta flag, and make sure i don’t actually call DateExpires when i know it’s not there, and i’m all good!

Summary

To summarize, Duck Typing is an awesome way in Oxygene to let you write code against classes that have the same (or similar) API, but don’t have a common ancestry or shared interfaces.

Of course, if you have full control over the class hierarchy yourself, the easiest (and cleanest way) to achieve this is to just define an interface and have the classes implement it. But sometimes, as in this example, the actual classes are out of your hand. Duck Typing lets you get around this nicely and safely.

Soft Interfaces

You might have noticed that i used the soft keyword when defining the interface, above. This was actually not fully necessary, as the duck() function will work with any kind of interface.

Soft interfaces approach duck typing from the opposite end: by defining the interface as “soft”, i don’t actually need the duck() call, as soft interfaces carry with them the information that they may automatically be duck-typed too, with a simple cast. As such, a simple select p as IByUserProducts would do to convert the types.

However, soft interfaces use the default (static) duck-typing mode by default, not the weak duck-typing. So this approach would have worked for the Beta branch of my code, which is why i chose to explicitly call duck() in both cases, for clarity. (Yes, i could/should drop the unnecessary soft keyword then, but i left it in to have an excuse to talk about it here ;).

You can read more about Duck Typing and Soft Interfaces on our wiki.

Profile photo of marc

by marc

Announcing the Oxygene 6 “July 2013″ Update

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


Oxygene "July 2013"

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

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

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

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

What’s Next?

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

Prism

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

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

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

Yours,
marc hoffman
Chief Architect

Profile photo of marc

by marc

Letting Oxygene and RemObjects SDK wake you up in time for WWDC

April 3, 2013 in .NET, Cocoa, Elements, iOS, non-tech, Nougat, WWDC

On Monday, it being a holiday and all, i found myself with a free half hour before dinner and so i decided i’d write a small little application with Oxygene that can both serve as an example for some cool technology interaction, and also does something useful for me: a Client/Server app that monitors the Apple WWDC webpage for changes and notifies me via Push Notifications on my iPhone when the page changes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It’s that simple.

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

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

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

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

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

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

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

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

The success case is more interesting:

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

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

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

Profile photo of marc

by marc

Cocoa/CoreFoundation Bridging Explained

April 2, 2013 in Cocoa, Elements, iOS, Nougat, Xcode

“Bridging” is a new language feature introduced to Objective-C alongside ARC, that i believe is not very widely understood, at least not fully.

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

Questions?

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

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

NSString *s = (NSString *)myCFString;

Instead, you now need to write:

NSString *s = (__bridge NSString *)myCFString;

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

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

“Regular” Bridge Cast

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

Objective-C

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

Oxygene

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

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

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

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

Transfer/Retain Bridge Casts

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

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

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

Objective-C

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

Oxygene

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

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

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

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

Objective-C

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

Oxygene

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

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

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

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

Objective-C

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

Oxygene

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

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

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

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

When to Use What?

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

So How Does this Work Under the Hood?

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

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

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

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

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

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

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

Summary

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

Top 10 Reasons to use Platform Native APIs

March 14, 2013 in .NET, Cocoa, Cooper, Elements, non-tech, Nougat, Oxygene

What are native platform APIs? They are the APIs provided by the platform vendor that define the platform. On Android this is the Android SDK. On iOS it is the Cocoa Touch Frameworks. On Windows and Windows Phone it is WinRT and the .NET Framework. There are undocumented APIs, and even calls that circumvent the platform APIs, but they are not considered part of the platform API.

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

Platform Native APIs are Great

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

The Law of Leaky Abstractions

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

Native Documentation

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

No Bloatware

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

Rapid Release Cycle

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

Support for Platform Deviations

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

Native User Experience

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

Less Points of Failure

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

Maximum Developer Flexibility

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

3rd Party Support

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

Summary

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