Avatar of Anton

by Anton

Data Abstract for Beginners Guide

October 11, 2013 in .NET, Data Abstract

Do what I do. Hold tight and pretend it’s a plan!

Introduction

Not long ago we published the RemObjects SDK Beginners Guide. Now we’re taking it one step further and look at the Data Abstract framework.

Most present-day business applications operate with some database data, and most often they are required to run on a variety of mobile devices (from laptops accessing the network over WiFi connections to iPad and Android tablets); now add performance and security concerns and you get an explosive mixture that could take an unpredictable amount of efforts to deal with.

So how can Data Abstract help to minimize these software development risks? Take a look at just some of the features this framework provides:
a) Supports a huge variety of platforms on the client side and .NET (or Mono) on the server side.
b) Provides the ability to create SSL-protected or AES-encrypted communication channels.
c) It is possible to use literally any relational database that has an ADO.NET driver.
d) Data source (database schema or even database server type) can be changed without any changes in the server or client code.
e) Data is sent over the wire in binary-serialized compressed form to keep network traffic at a minimum.
f) The .NET client side provides simple-to-use LINQ interfaces, as well as old-fashioned DataTable-based interfaces to the remote data.
g) With our pre-built Relativity Server you can set up your own middle tier server without writing a line of code.
…and much more.

The article below describes the core Data Abstract facilities and their relationships. It also provides a (very short) jump-in crash course into Data Abstract. In just a few minutes you will be able create your first Data Abstract-based server and client applications.

Overview

Data Abstract is built on top of the RemObjects SDK communication framework. In short, a Data Abstract server application is a RemObjects SDK-based server with database connection management, efficient data exchange protocol and declaratively (i.e. not in the program code) defined mapping between the database schema and the data structure exposed to the client applications. On the client side, Data Abstract provides components to simplify the data access so there is no need to manually compose calls to the server.

So the whole picture looks like this:
Data Abstract Overview

As you can see, the core Data Abstracts components are:

  • The ConnectionManager that manages connections to the underlying database (or databases). It allows to pool database connections if the database’s ADO.NET driver doesn’t provide this feature or when more precise control over the connections pool is needed.
  • The Schema that describes mapping between the underlying database tables and data structures exposed by the server (called data tables). The client application only has access to the data exposed via Schema tables, without direct access to the underlying database tables. Schemas can be edited using the Schema Modeler tool.
    Note that the Schema mapping is not necessarily a 1-to-1 mapping (i.e. the database table is exposed as a Schema table). For example, it is possible to expose the result of an SQL SELECT statement as a Schema table and to handle any data updates applied to this Schema table using stored procedures. This approach allows to filter data on data access, do additional data integrity checks on data updates, etc., completely transparent to the client application. Also, some database tables are not suited to be exposed as Schema tables.
  • The DataService, a predefined RemObjects SDK service that exposes Schema data. In most cases there is no need to add any code to this service’s definition.
  • The DataStreamer component that serializes data request results and and data update requests. DataAbstract provides two data streamers – one that exposes data using the highly effective Binary format and another that uses the JSON format to exchange data. The latter one allows to exchange data with platforms that we don’t provide a Data Abstract client library for (f.e. PHP or Ruby server code).
  • The DataAdapter, a client-side component that encapsulates the server method’s calls.

Sample Application

Let’s create a simple server and client application and see how the Data Abstract components are used in a real Data Abstract-based application. Luckily, Data abstract provides a simple-to-use project wizard, so an application skeleton can be created in literally 10 seconds. Just follow these steps:

  1. Start Visual Studio and create a new solution using the Data Abstract -> Windows Forms Application template.
    New Project
  2. Select the ‘Client and a New Custom Data Abstract Server’ project kind on the Wizard screen to create both server and client Data Abstract applications, so we’ll be able to investigate both server- and client-side code.
  3. Select the Default Connections -> PCTrade-SQLite database connection. This pre-defined connection points to a sample SQLite database created whith the Data Abstract installation.
    Database Connection
  4. Now we need to select the database tables that will be included in the Schema generated for the server application. Leave all tables selected and proceed to the next wizard page.
    Schema Tables
  5. The last Wizard page allows to set up some additional options for the solution. We need to keep things simple, so uncheck the ‘Add Login Service’ and ‘Add support for Business Rules Scripting’ project options.
    Project Options

After the Finish button is pressed, the new solution containing the Data Abstract server and client applications will be generated.
You can find a detailed description of both server and client application projects in the corresponding Wiki articles:

For now, let’s examine the core Data Abstract components used in the solution and proceed to actually retrieving data from the server.

Server Application

DataService and DataStreamer

First, we need to take a look at the server’s RODL and the DataService definition.
Service Builder
As you can see, the server’s data service descends from the DataAbstractService defined in the core Data Abstract RODL and doesn’t define any new service methods. This allows us to avoid importing the custom interface file generated for this project, because a pre-generated interface for all service methods is already included in the RemObjects.DataAbstract.dll assembly.
Note that the DataService code file doesn’t actually contain any custom method definitions. All methods used in the Data Abstract client-server communication process are already defined in the base DataAbstractService class. Of course it is possible to add event handlers or even to override method definitions inherited from the base DataAbstractService class, yet this is not needed in the current sample application. However, there are some vital settings that have to be set for the Data Abstract Server to function. In our case, these properties were already set by the New Project Wizard.
Open the DataService implementation in design mode.
First you will see the DataStreamer component. It is tied to the Data Service via its ServiceDataStreamer property.
Data-Abstract-Beginners-Guide-Data-Service-Properties
Also note the AcquireConnection and ServiceSchemaName properties. The first one defines whether the database connection should be acquired using the default Connection Manager when the service is accessed by the client app or if a more advanced connection retrieval process should implemented in the user code (this is not needed for simple Data Abstract servers, but for example Relativity Server uses its own connection management engine). The ServiceSchemaName property points to the project file containing the Schema definition. On application startup, Data Abstract will load this file, deserialize the Schema from it and cache the result.

Connection Manager

The Engine.cs file contains definitions of network-communications-related stuff like Server Channel, Session Manager and Message (see the RemObjects SDK Beginners Guide for more information about these components). Additionally, it contains the Connection Manager that will handle connections with the underlying database.
The Connection Manager will load connection definitions from the .daConnection file on server application startup and will provide connection instances (either from its own internal pool or directly from the driver).
Data-Abstract-Beginners-Guide-Engine

Schema

The last (but not least) server application element is the .daSchema file. It contains the mapping between the underlying database and the data structures actually exposed by the server application.
In the simplest case, the database tables are mapped on a 1-to-1 basis to the Schema tables. This the easiest scenario. At the same time, Data Abstract makes it possible to, for example, define a Schema table that exposes data from a complex SQL query involving joins of several tables as a plain table. Given that the needed SQL statements (either stored procedures or plain SQL statements) are defined to handle insert, update and delete operations, the client application will work with the data as if it was a simple plain table. Furthermore, if in the future the data source structure will be changed (for example if a data table containing the needed data will be introduced to the database schema) it would be possible to point the Schema table to this changed data source without changing a line of code in either the server or the client application.
The .daSchema file can be edited using a tool called Schema Modeler. The Schema Modeler can be started either as a standalone application from the Windows Start menu or by double-clicking the .daSchema file in the Solution Explorer.

Additional Information

You can find more about the generated server application project in the following Wiki article.

Client Application

Overview

The client application doesn’t differ much from an ordinary WinForms (in this case) application. It contains the main form, the regular Program.cs file, as well as a usual set of references.
Client-side Data Abstract stuff is contained in the RemObjects.DataAbstract.dll assembly. Also, the RemObjects SDK client-side set of assemblies (i.e. the RemObject.InternetPack.dll, the RemObjects.SDK.dll and the RemObjects.SDK.ZLib.dll) is required for Data Abstract, because the network communication relies on the RemObjects SDK infrastructure.
Note that the client application doesn’t contain a custom interface file. It is not needed because all interface classes and interfaces needed to communicate with the server are already defined in the RemObjects.DataAbstract.dll assembly. Of course, if the client application needs to call some custom server methods, a custom interface file will be required.
Look at the Data Module project element. It contains pre-configured server communication components.
Data Module

The Client Channel and Message components are used to send data to the server and retrieve its responses.
The Data Streamer, Data Adapter and Remote Service components, however, are Data Abstract-specific. They are configured to work together:

  • Remote Service receives requests from the Data Adapter and sends them to the server using Client Channel and Message.
  • Data Streamer is used by the Data Adapter to serialize and deserialize requests (including data table data and data update requests). Data Abstract supports two types of Data Streamers – binary and JSON-based. The binary Data Streamer (implemented in the Bin2DataStreamer class) is the preferred one to use, because it is faster and its use consumes less network traffic. Please note that Data Streamer types used by the client and server applications should match, otherwise data exchange won’t be possible.
  • Data Adapter is basically the core of the client-side Data Abstract infrastructure. It exposes the APIs needed to retrieve data from the server and to send data update requests without the need to explicitly call Data Streamer to serialize the data, call server methods etc. And again, there are two Data Adapter kinds that differ in the way data is accessed – via LINQ request or using plain System.Data.DataTable instances (either typed or untyped). Both kinds of data adapters can be used with the same server application (or even in the same client application).

Additional Information

You can find more about the generated client application project in the following Wiki article.

Data Access via DA LINQ

Now let’s fetch some data from the server and then post some update data back to it. In the following, I’ll show both the LINQ and the DataTable way of accessing the data. Let’s begin with DA LINQ, as it is the more advanced approach. You can consider DA LINQ as a (very simple) ORM that fetches data from the remote server and converts it into objects.
As you can see, the client application contains a TableDefinitions_… file. This mysterious file contains a set of classes that are code representations of Schema tables. Each public Schema table is mapped to one of the classes contained in this file, including all table fields represented as class properties. This means that this file should be regenerated in case the data structure of the Schema tables exposed by the server is changed. This article describes how to manage the table definition classes. I suggest you to read this article later, as for now we already have the needed set of Table Definition classes.
To emphasize that Data Adapters (and any other Data Abstract or RemObjects SDK component) can be configured in code and designer support is just a way to speed up development, the following code will use a Data Adapter defined in code.
So let’s instantiate the Data Adapter, create some data access and data update methods and tie them to the GUI.

1. Data Adapter definition
Define private field

LinqRemoteDataAdapter fLinqDataAdapter;

Add the following code to the constructor (AFTER the InitializeComponent method call):

this.fLinqDataAdapter = new LinqRemoteDataAdapter();
this.fLinqDataAdapter.DataStreamer = this.dataStreamer;
this.fLinqDataAdapter.RemoteService = this.remoteService;

Now the Data Adapter is instantiated and tied to the Data Streamer and Remote Service instances.
2. Data access
The simplest Data Access method would look like this:

public BindingList<Customers> GetData()
{
  var lServerQuery = from x in this.fLinqDataAdapter.GetTable<Customers>() select x;
  return lServerQuery.ToDABindingList();
}

Note how the data is accessed with a simple LINQ statement on the this.fLinqDataAdapter.GetTable() object. Data Abstract does all the work needed to convert the provided LINQ expression into a form that can be understood by the server application, send the request over the network and retrieve the data. The query used here is very simple. More advanced queries are shown by the DA LINQ Sample, including queries with conditions and queries that fetch only a subset of the target’s table columns.

The mysterious BindingList is a class that simplifies data binding. You can read more about this class in the corresponding wiki article. Of course, the data can be loaded into a simple List<T> as well.

3. Data update
The data update method is very simple:

public void UpdateData()
{
  this.fLinqDataAdapter.ApplyChanges();
}

The Data Adapter tracks changes made to the data into a BindingList, so all changes can be applied using a single line of code. More advanced scenarios are out of the scope of this article. You just need to know that it is possible to make data changes using methods like AddRow, UpdateRow and DeleteRow exposed by remote table instances that can be acquired using the GetTable<T> method of the Data Adapter.

4. GUI
Add 2 buttons and a Data Grid View to the main form of the client application.
Data Abstract Client Main Form
Add the following code to the Click handler of the Get Data button:

this.dataGridView1.DataSource = this.fDataModule.GetData();

Add the following code to the Click handler of the Update Data button:

this.fDataModule.UpdateData();

Run both server and client applications and try to fetch data from the server, update some fields in the data grid and then push the updated data to the server. And that’s it. You have created a network server and client application and added load and save data features to the client application using just a few lines of code.
Data Abstract Client Main Form

Data Access via DataTables

While DA LINQ is the more preferred way of accessing data, Data Abstract also exposes a more old-fashioned data access interface, based on the System.Data.DataTable instances, both strongly typed (corresponding to the server Schema) and untyped ones. This article describes how to manage the strongly typed dataset definitions.

In the following part of the tutorial, we’ll use the untyped dataset, for simplicity reasons.

So let’s again instantiate the Data Adapter, create some data access and data update methods and tie them to the GUI.

1. Data Adapter definition
Define private field

RemoteDataAdapter fDataAdapter;

Add the following code to the constructor (AFTER the InitializeComponent method call):

this.fDataAdapter = new RemoteDataAdapter ();
this.fDataAdapter.DataStreamer = this.dataStreamer;
this.fDataAdapter.RemoteService = this.remoteService;

As you can see, the instantiation of the Data Adapter and its setup are very similar to the LINQ Data Adapter.

2. Data access
In the case of the table-based Data Access, the simplest data access method would look like this:

public System.Data.DataTable GetDataTable()
{
  System.Data.DataSet lDataSet = new System.Data.DataSet();
  this.fDataAdapter.Fill(lDataSet, new String[] { "Customers" }, true);
  return lDataSet.Tables[0];
}

This code fetches only the Customers data table from the server.

3. Data update
The data update method is very simple:

public void UpdateData(System.Data.DataTable table)
{
  this.fDataAdapter.Update(table.DataSet);
}

Note that unlike the LINQ Data Adapter, the Table Data Adapter relies on the .NET DataSet to track data changes.

4. GUI
Change the Click handler of the Get Data button to

this.dataGridView1.DataSource = this.fDataModule.GetDataTable();

Also change the Click handler of the Update Data button to

this.fDataModule.UpdateData((System.Data.DataTable)this.dataGridView1.DataSource);

Run both server and client applications and try to fetch data from the server, update some fields in the data grid and then push the updated data to the server.
As you can see, the table-based access is similar to the DA LINQ-based one, but still differs from it in some details. It is up to you to choose the approach to use, as both of them are valid and fully supported by Data Abstract.

Conclusion

This article only scratches the surface of the Data Abstract framework world. Again (as in the RemObjects SDK Beginners Guide) many features weren’t touched or even mentioned to simplify the article.

Search our Wiki for the questions you are interested in. If for some reason you can’t find the info you need, don’t hesitate to call on our support via RemObjects Connect or drop an email to support@remobjects.com.
I would also be glad to hear your suggestions on what to describe next – Relativity Server, Olympia, or something else?

Avatar of marc

by marc

Come See Brian Long Talk about Android Development with Oxygene at BE-Delphi

October 7, 2013 in Events, non-tech

I’m told that our friend Brian Long will be giving a presentation at BE-Delphi’s annual developer event in Antwerp, Belgium, on November 21.

Brian is a great presenter; we had the pleasure of having him as a guest speaker at DSConf and he has presented on Oxygene for Android and iOS in the past — so if you’re anywhere near Antwerp in November, make sure to check out his talk, and the conference in general.

From Brian’s session summary:

Oxygene is an Object-Pascal based language previously well know in its .NET incarnation as Delphi Prism. Oxygene for Java produces Android apps that run where Android does – in Android’s Dalvik VM. It is for those who have a background in Delphi or a history of Pascal programming from previous times, or anyone who fancies something a bit different from Java, and who wants to use the standard Android APIs in the Android SDK to build lightweight, standard Android applications (or, for that matter, Java applets, servlets, etc.) that can run on any Android device of your choosing.

We’ll look at Oxygene for Java’s capabilities and features in the context of building and deploying an Android application using OS-native controls. We’ll see how the product works, bump into some enhancements to the evolving Object Pascal language and show that Oxygene for Java is a first class citizen in the world of Android development.

You can find out more about BE-Delphi at be-delphi.com.

Avatar of marc

by marc

Announcing the Oxygene ‘September 2013′ Update

October 2, 2013 in Cocoa, Java, Oxygene

We’re very happy to let you know about the immediate availability of the September 2013 release, the first of two smaller monthly updates we have planned for the Oxygene 6.1 release cycle.

This release, Oxygene 6.1.55.1371, is mostly a bugfix release, but it also contains a handful of significant improvements and new features.

iOS 7.0

On the iOS side, a lot has changed over the past few weeks. Apple has released the final version of iOS 7.0; they have also started shipping two new iPhones, one of them with an all new 64-bit ARM CPU, the A7, and there is also a brand new version of Apple’s IDE — Xcode 5.

While Oxygene has been working well with iOS since it hit beta in June (just a few days after we officially shipped Oxygene for Cocoa), this new release adds official support for iOS 7.0 and Xcode 5. This affects several areas.

First and most importantly, with iOS out from under the NDA, we’re able to ship .fx files for iOS 7.0 in the installer, making it easier (and the default) to build your apps for the 7.0 SDK, without you having to run FXGen yourself to get access to the new SDK.

iOS 7 is not just a new look (although that is a big part of it), but also brings with it a huge amount of new APIs that you can start using in your apps immediately. From TextKit to SpriteKit, from enhancements in UIKit to more options for background operations (such as updating content in your app while it is not running).

There’s a lot for developers to love in iOS 7, and you have full access to it from Oxygene.

What’s more, in last month’s update we shipped significant enhancements to Deployment Target support in Oxygene, which makes it really easy to take advantage of iOS 7, while still supporting older versions of iOS at the same time.

Apple’s new Xcode 5 has changes that affected our process for working with XIB and Storyboards, forcing us to rethink how this is handled – with the end result that we now have a much better and more flexible solution in place. A new menu item in Visual Studio will let you create/update a full Xcode project that will contain all your .XIB and .storyboard files, along with knowledge about other items in your project, including your classes, but also resources such as images.

Once created/updated, you can simply open the project in Xcode and edit your UI files to your heart’s content. Save, and when you go back to Visual Studio and build your app, your changes will get picked up automatically.

We have also made improvements to the iOS Simulator integration. Just as in Xcode 5, Oxygene now lets you choose exactly which type of simulator you want your application to run on — not just iPhone vs. iPad, but also screen size, and whether to use the Retina screen or not. Right from the CrossBox menu:

64-bit

The September 2013 release also includes support for the all new 64-bit iOS Simulator. When building for iOS 7 (or later), you can now select x86_64 as second iOS Simulator architecture to build for, and get your iOS apps ready for the A7 chip.

Support for arm64 for building applications to run as 64-bit on the device is working in our labs and will be available for the next (October 2013) update and in our current beta builds. Unfortunately, it did not make it into the September release due to timing issues – we figured you would probably want us to test extensively on real hardware, before shipping a compiler to you. Real hardware which has only been available for little over a week now, of course.

Java

Three significant improvements have been made on the Java and Android platform, as well.

First, we have implemented support for Java Native Interface (JNI) in the compiler, making it really easy to access non-Java libraries and APIs from your application.

Secondly, we have expanded our syntax for Inline Interfaces to allow them to be descendants of existing abstract or concrete classes. This has been a much-requested feature from Android developers, and will make many Android APIs much easier to consume.

Finally, we have updated the compiler to be compatible with binary format changes coming in Java 8. While Java 8 (currently still in beta and very much in flux) is not an officially supported platform yet, this will allow you to get started experimenting. This is exciting news for those of you living on the cutting edge.

There’s More

These features are rounded off by over 70 additional fixes, enhancements and improvements, all throughout the product, and across all three platforms, .NET, Cocoa and Java.

We’re very excited about this update – and about what we have still planned for the rest of the year – and we hope you will like it, too!

Yours,
marc hoffman
Chief Architect

Welcoming the new RemObjects Software Developer Evangelist!

October 1, 2013 in non-tech

RemObjects is very pleased to welcome Steve Scott (aka “Scotty”) to the post of Developer Evangelist for the company!

ScottyScotty brings a wide range of skills to the table, as his CV shows:

Steve Scott  has  been a  developer for 26 years. He started as a developer in 1987, when he was writing accounting software using COBOL on a Convergent Unix machine using vi as his code editor. Since then he has worked on mainframes, minis, 16bit and 32bit Windows (C++, Paradox and Delphi), .NET (C# and Visual Basic), OS X and iOS (Objective-C and Cocoa). During his career he claims to have worked on more hardware and learnt (and forgotten) more languages and IDEs than any sane man should have to.

During the late 1990s he was an active member of the Delphi community spending some time as the technical lead of the UK Borland User Group (UKBug), as well as being the technical lead for the popular DCon conferences and a regular speaker at BorCon.

As the 21st century took hold, he made the move to .NET and became a respected speaker at many .NET conferences around the world.

In 2007 he jumped ship and headed into the world of Apple to work on Mac and iOS software. In this new world he became the founder of the iDeveloper Blog, host of the iDeveloper Podcast and creator of NSConference.

Scotty will be focusing on improving the user-facing side of the company – work on bringing our products to the attention of more developers world-wide, improving accessibility and discoverability for new users, and working with the teams on enhancing the over-all user experience. You can also expect some more RemObjects TV and Radio in the near future, as well.

Outside of his responsibilities at RemObjects, Scotty will continue to be an asset to the developer community at large, thru his other projects such as the iDeveloper site and podcast, and NSConference.

Avatar of marc

by marc

Data Abstract and RemObjects SDK for Cocoa on iOS 7 and the 64-bit A7

September 30, 2013 in Data Abstract, iOS, Xcode

Hi. I wanted to give you a quick update on the status of Data Abstract and RemObjects SDK with regards to both the new iOS 7.0 and – more interestingly – the new 64-bit iOS on the iPhone 5S.

Over the past couple of weeks, we have been debating whether we should make a small interim update to RO/DA for Cocoa available to “officially” support the two new platforms/technologies, and we have decided against such an update, for the following reasons:

We’ve (of course) been testing the RemObjects SDK and Data Abstract code base with iOS 7.0 since the first beta, and with 64-bit since the iOS 7 GM and the iPhone 5S is out. The current code base as shipped in the Fall release about a month ago is working perfectly with iOS 7, and no changes are needed.

It is also working fine on 64-bit (ignoring some minor warnings), as expected – after all, the same code base has been running on 64-bit Mac OS X since forever. Still, it would be nice to ship an update release that contains a universal binary pre-compiled for arm64 out of the box, but there’s one downside to that:

Right now, if we switched RO/DA to build for arm64 by default, that would mean we’d also need to set the minimum deployment target to iOS 7 – which in turn means the binary we’d ship would not allow you to build applications that still target iOS 6 (or lower), something we know many of you still do.

On the flip side, for those of you who would like to build your RO/DA based apps for 64-bit, it is a simple job to rebuild RO/DA yourself: Simply open the project in Xcode, change the architecture to ARCHS_STANDARD_INCLUDING_64_BIT (and clear the deployment target, of course), and hit rebuild. (We’re also making a pre-release build available today that does have 64-bit enabled (at the cost of losing deployment target options, as indicated.)

Apple is promising to sort out the deployment target situation “next month” to allow arm64 to co-exist with older deployment targets, and we figured it would be best to hold out for that — especially given how easy it is for you to manually rebuild for 64-bit now, if you need it.

I will keep you posted as this develops – and once again, us holding back on shipping the update does not mean that the current code base you have now is not perfectly fine for arm64 use already.

Let us know what you think.

Android resources

September 20, 2013 in Guest Post, Java, Oxygene, Prism

For those Pascal programmers looking at building Android applications, be it with Delphi XE5 or with Oxygene for Java (I work with both!), here are a few Android-related resources that may come in useful:

  • Google’s Android Device Manager – if you mislay your Android device this allows you to locate it on a map (if it’s got a data/WiFi connection) and also ring it (presumably if it’s a telephone – I haven’t checked whether this option does anything on a tablet). Clearly this is similar to Apple’s Find My iPhone functionality.
    [Update: Jim confirms that tablets will happily ring too]
  • Using remote Android emulators – because Android emulators emulate the device CPU they can be hideously slow, and basically unusable in a VM. If your dev tool runs in a VM then it can be useful to communicate to an Android emulator (technically called an Android Virtual Device or AVD) either on the host machine or another machine on your network. This is a useful technique entirely independent of your chosen development tool as it revolves around how your local adb.exe communicates with the emulator. This post by Jim McKeeth runs through how to set this up using SSH. You can also find a write-up in the Delphi online documentation.
  • If you are using Oxygene for your Android development you may want to look at setting up your AVD to use an x86 CPU, potentially taking advantage of Intel Virtualization Technology via Intel HAXM (Hardware Accelerated Execution Manager) to provide VM acceleration. Delphi developers cannot take advantage of this because Delphi targets the ARMv7 CPU.
  • App testing across many devices. The Android emulator has long been held up as pretty much the only way of testing your app across the range of form factors that different devices can offer. Now it’s not the only option though, as Apkudo for Developers offers developers a free online app-testing platform where your app will be tested on over 260 different Android devices. Just upload your app to the queue and a report will be sent back when the tests have been run.
  • Since Android’s Ice Cream Sandwich release introduced the Roboto font as the default, you may want a copy to install on your machines. You can download it from the link in the blue box here (or this is the direct d/l link).
  • Google’s sample icons pack can be downloaded with this link.
  • For anyone who does presenting it can be very useful to have a means of showing on your computer screen what your device is doing. There are various VNC-based solutions for this out there, but Jim McKeeth has built a simple solution using repeated screen-captures called Android Screen View. You can download the source code for it here or pull down a build here.
  • The Android dashboards show you the percentage of devices sharing various characteristics as obtained from the Google Play store. All the devices in question will be running Android 2.2 (FroYo) and above.
    This device breakdown can be useful to decide what OS and form factor to ensure you support.
    On the dashboards you can see the breakdown of:
    • Android OS versions
    • Screen sizes and densities
    • OpenGL version
  • If you have a nose that needs to be poked inside everything, consider pulling down the Android source code. Information on how is available here.
Avatar of marc

by marc

An update on Oxygene support for iOS 7 and arm64

September 13, 2013 in iOS, Nougat, Oxygene

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…

Avatar of marc

by marc

Announcing Oxygene 6.1

September 9, 2013 in .NET, Cocoa, Java, Oxygene

We’re thrilled to announce the immediate availability of Oxygene 6.1, the next feature release for Oxygene after the introduction of Oxygene for Cocoa earlier this year.

Like most of our monthly updates, this “August 2013″ release contains a vast number of fixes, improvements and enhancements all across the board, and for all three platforms. It also provides a small handful of new major features that we are really excited about and think will make a great difference in your day-to-day work using Oxygene.

First off, 6.1 marks the introduction of our Refactoring engine for Oxygene. We’re starting out small, with one very useful refactoring: the ability to safely rename identifiers solution-wide. But this also lays the groundwork for more refactorings to be added in the near future.

We have also vastly expanded the Go To Definition feature of the IDE to work for external references. This makes it easier than ever to have a peak at the declaration of the classes you are using, from .NET classes such as System.String to Cocoa ones such as UITableView. Just right-click, choose Go To Definition, and Oxygene will bring up the class declaration – in full Pascal syntax, of course – ready for you to review, or to copy method headers from.

Cocoa developers will love to hear that we added even better support for Deployment Targets to the compiler, with improved weak linking, and optional warnings when your code uses classes that may not be available in the lowest deployment target SDK you selected for your project. This goes way beyond what Xcode offers, and – especially with iOS 7 coming up now – will make your life supporting apps on new and older OS versions so much easier.

Of course that’s not all. There’s also support for optional interface methods in Cocoa, unsigned integer types on Java, and much more. You can find the full list of changes on our What’s New and Change Logs pages.

How to get Oxygene 6.1

As always, Oxygene 6.1 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

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

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 has been a great year for Oxygene so far, but we’re not done yet. We’ve got more amazing things planned for the rest of the year, and beyond. So make sure to stay up to date with your subscription.

Happy coding!

marc hoffman,
Chief Architect
RemObjects Software

Avatar of marc

by marc

Embarcadero Prism to Oxygene License Migration

August 15, 2013 in non-tech, Oxygene, Prism

form Prism to Oxygene

Dear Embarcadero Prism Customers,

we want to thank you once again for choosing Oxygene for your .NET development needs in form of Embarcadero Prism.

As you might have already heard, our collaboration and reseller agreement with Embarcadero is coming to an end, and starting with our next upcoming release Oxygene for .NET will be available exclusively from us at RemObjects.

We can assure you that the product itself is alive and well, and with or without Embarcadero we are looking towards a bright future for Oxygene – on .NET and on the other platforms supported by the Oxygene language.

The end of our agreement with Embarcadero, however, means that starting with the upcoming Oxygene 6.1 release the product will stop accepting Embarcadero “Sanctuary” serial numbers, and we’ll be switching all customers over to our own unintrusive, no-nonsense licensing system.

Embarcadero Software Assurance

We do realize that many of you have purchased Software Assurance with Embarcadero in good faith that it would continue to include Prism.

Because we believe in treating our customers fairly, we have decided to fully honor any SA contracts between you and Embarcadero that have been purchased or renewed before April 22, 2013 (the date when Embarcadero announced its discontinuation of Prism) on our own dime, and you will continue to receive free updates for the remaining period of your SA from us.

In order to get you set up on our side, we kindly ask you to do two things:

  1. If you have not already done so, please make sure to register your latest XE3.2 serial numbers with us at remobjects.com/oxygene/registerserial. We will use these registrations to keep track of customers with (potentially) active SA.
  2. Please send us an email to sales@remobjects.com with details about your current SA contract, including when it was bought or renewed and when it expires. Based on this information, we’ll set you up with the appropriate Oxygene for .NET licenses in our system.

If you have active Software Assurance for RAD Studio XE3 or Prism XE3, and you have not received an XE3.2 serial number, please reach out to your contacts at Embarcadero (and feel free to include sales@remobjects.com in CC for your communication, so we can also follow up on our end) to ask them for your XE3.2 key.

We do apologize that we need to ask you for these manual steps, but unfortunately we receive no information or details about Prism users and their SA contracts from Embarcadero, so the only way we have to move you into our system you is by you contacting us.

Renewals, and/or moving to the full Oxygene Package

If you do not have Software Assurance, or your SA ends before August 23, 2013, we have attractive renewal options explicitly for Prism customers that will let you upgrade/renew to our full Oxygene package — with Oxygene for Cocoa, Oxygene for Java and of course Oxygene for .NET..

We have emailed everyone who registered their Prism serial number with us with the details for this today.

If you have not registered your serial yet, but are going to do so, we will email you once we received your registration. If you have any questions, or for some reason cannot register your serial number (maybe because you’re on Prism XE or later, which we don’t accept serials for), please just email sales@remobjects.com with your details, and we will sort you out as best as we can.

Exciting Things Ahead

We’re very excited about the things we have planned for Oxygene (and Hydrogene) moving forward. The imminent 6.1 release contains some very cool features that many of you have been asking for, including initial support for Refactoring (that we’ll build upon further going forward) and other IDE and language enhancements. And we have more exciting and more groundbreaking things planned for the rest of the year and for 2014.

We hope that you will continue to put your faith in us and in Oxygene, even without Embarcadero. Prism, and the Oxygene Language, always have been 100% driven by us at RemObjects, and it will keep getting better and better.

We’re looking forward to having you along for the ride as we move ahead further.

Yours,

marc hoffman
Chief Software Architect
RemObjects Software

Avatar of marc

by marc

Android and “True Native” Compilers

August 12, 2013 in Android, Cooper, Oxygene

Here’s what Google has to say about using their NDK:

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.