You are browsing the archive for Cooper.

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.

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

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

The Pre-Flight Check

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

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

Java SDK

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

Download The Android SDK

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

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

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

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

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

The SDK Manager

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

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

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

Android Virtual Devices

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

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

The AVD Manager

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

Create an AVD

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

Define a Device

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

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

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

Select an API

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

Device Memory

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

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

Save The Device

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

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

Test The Device

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

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

The AVD will then begin to start.

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

Testing Your AVD Setup

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

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

Setting Up An Actual Device

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

Enable USB debugging on your device

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

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

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

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

Install USB Drivers For the Device

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

Running Your App On The Device

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

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

You Are Ready To Go

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

The NDK is a toolset that allows you to implement parts of your app using native-code languages such as C and C++. For certain types of apps, this can be helpful so you can reuse existing code libraries written in these languages, but most apps do not need the Android NDK.

Before downloading the NDK, you should understand that the NDK will not benefit most apps. As a developer, you need to balance its benefits against its drawbacks. Notably, using native code on Android generally does not result in a noticable [sic] performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++ [or Pascal].

Typical good candidates for the NDK are self-contained, CPU-intensive operations that don’t allocate much memory, such as signal processing, physics simulation, and so on. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.

At RemObjects, our philosophy has always been to support developers using the official tool chains and frameworks that are recommended by the platform vendor (especially now that in the 21st century these APIs have become so good, object-oriented and easy to work with, out of the box) – whether with our Oxygene compiler or our Data Abstract and RemObjects SDK library products, both of which support Android at the proper and recommended level: Dalvik.

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:

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!

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 callDateExpires 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 ;).

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 ;).

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.

Brian Long made a great video on building an Android Torch App using Oxygene for Android. You can find it as part of RemObjects TV. The app he builds is a nice simple app, which makes the video easy to follow while also covering some concerns you may face in more complicated apps:

Dr. Norman Morrison recently published a wonderful series of Oxygene for Java tutorials on his “Pascal Programming for Schools” site, including some on Android development. He reports that students in his school are already using Oxygene for Java for their educational projects and are very excited about building Android applications as well.

Oxygene is great to use in educational settings. It holds true to the design paradigms of Object Pascal, which make it easily readable and discoverable. It doesn’t stop there though, but extends the language with great new language features frequently found in academic languages, like Tuples, Duck Typing and Aspect Oriented programming. The fact that it supports all common platforms of today is a real plus too.

Dr. Morrison also reports using Oxygene for Java to develop for his ARM-based Raspberry Pi, and includes some examples, too.

Adding Oxygene for Java to their curriculum has really energized both the department and the students while expanding their program!

Many of the Android resources, from layouts and styles to animations and even manifests are defined in XML. The XML spec for all of these different resources is a bit dynamic and varies based on things outside the XML document. For these and other reasons there is no official schema provided by Google to define the XML document, as would be needed for Visual Studio to provide IntelliSense for these XML files.

The “June 2012″ release of Oxygene for Java changes all that. We’ve generated 4 schema files that provide IntelliSense for pretty much all the Android XML resources you may encounter. The IntelliSense provides elements and attributes, and in a few cases values for everything from Layouts to Manifests.

Because of the way the XML IntelliSense works in Visual Studio, and because the Android XML doesn’t completely implement the schema as it should, we had to rename the XML files to make them work with the schemas and provide IntelliSense. So to get all the Android IntelliSense goodness, you need to rename your XML layouts to *.layout-xml and every other XML document to *.android-xml. All of the examples and templates are updated with this new naming.

Since there is no official schema, and the XML specification in the Android documentation is a little vague in places, we are looking for your feedback how better to improve the IntelliSense. An important area you will notice is with user defined widgets in the layouts. Currently, the IntelliSense schemas are static, so if you add a new widget, it won’t show up in the IntelliSense. Let us know if you run into any other situations where the IntelliSense could be a little more intelligent.

Also, to make the IntelliSense even more helpful, we added a range of new item templates to Android projects. They all get put into the correct folder as required by the Android spec. For Drawables, it puts them in the default /res/drawable folder. From there you can move them to a drawable folder for a specific DPI.

Likewise, if you come across any other Android templates that should be included to make your life easier, please let us know.

Metro

The big theme this time around is our preliminary support for Metro and Windows 8. Since Windows 8 and Visual Studio 11 are in Release Preview right now, our support is preliminary, but rest assured that when they get released we will have finalized support right away. This means you can start developing native Windows 8 Metro apps today, so you are ready! You will find preliminary Metro support in Oxygene for .NET as well as Data Abstract and RemObjects SDK for both .NET and JavaScript.

Free JavaScript Client Libraries

Another big annoucement is that our JavaScript client libraries are now abailable as seperate, free downloads. You can use these to freely add Metro clients to your existing Delphi, .NET or Relativity servers. Check out the video on developing Metro apps with Data Abstract for JavaScript. If Windows 8 Metro isn’t on your radar yet, you can also use the JavaScript client libraries to build browser based client applications, as well as mobile applications with tools like Titanium or PhoneGap.

Schema Modeler 7 Tech Preview

Beyond Metro and JavaScript, you will also find a Tech Preview of our Schema Modeler 7 for Windows. This new Schema Modeler has been designed from the ground up to provide a better and more streamlined schema editing experience. If you are familiar with the reinvented Schema Modeler from the Xcode edition, you will see they have a lot in common.

We’re still putting some finishing touches on DASM7 (as we call it internally), before we consider it “done”. This means DASM7 does not replace the old Schema Modeler yet. You can find it in the \Bin folder of your Data Abstract installation and give it a try — or run it with /register once to make it the default.

But Wait, There’s More!

This is just the tip of the iceberg. As always, check the change logs to see what else is new in the “Summer 2012″ release.