You are browsing the archive for Data Abstract.

Avatar of marc

by marc

Data Abstract, RemObjects SDK and Hydra “Spring 2014” Releases

March 31, 2014 in .NET, Cocoa, Data Abstract, Delphi, Hydra, Java

On Friday, we released the latest updates to our Data Abstract and RemObjects SDK products for all five platforms, as well as for Hydra. Like always, a whole bunch of fixes and improvements across the product lines are gathered together in this release.

For Data Abstract and RemObjects SDK, this is also our last planned release for the 7.0 product version, as we prepare for a major new product cycle — codenamed DA8 — starting with our summer release in May. As such, this update focuses mainly on bug fixes and smaller enhancements (of which there are many).

The new release also includes official support for use with our recently released RemObjects C#, including project templates and IDE improvements to let you build .NET, Cocoa and Java apps with RO/DA using our C# implementation, as well as building managed hosts and plugins for Hydra.

As always, the new update is free for all users with an active subscription, and available on the customer portal. Our free 30-day trial downloads have also been updated to the new version.

If your subscription has elapsed, then now is a great time to renew. Renewing will not only give you access to the new 7.0 update, but also access to the beta versions of DA8 that will become available over the course of April, as well as the first (and future) DA8 or RO8 releases throughout the year.

If your previous subscription ended a while ago, you will be happy to hear that we recently updated our online shop to automatically grant “amnesty renewals”. That means you can be assured that your renewed license will always cover the current product and at least six months of future updates from your renewal date.

If you have or are considering getting a Suite subscription, remember that the Suites for .NET, Cocoa and Java now also include RemObjects C# — so you get been more value at the same great price as before (and you can always up-renew from RO or DA to the Suite, of course).

But enough talk, i’m sure you’re anxious to try out the new bits. We’re happy to have this new set of updates out to you now, and we’re extremely excited about what we have coming for DA8 and RO8 this summer and beyond.

yours,
marc hoffman
Chief Architect

Avatar of Anton

by Anton

Winter has come

December 23, 2013 in .NET, Data Abstract

By the time this blogpost will be published, the Winter 2013 release of Data Abstract will already become available. I feel that I should talk about several important features made available in it, and about a few things that will soon fade in oblivion.

So the new features first.

Private Schema tables access. Local Data Adapters (both dataset-based and DA LINQ ones) are now allowed to access Schema tables that aren’t marked as ‘public’ and thus aren’t accessible by remote clients. There is no need anymore to write additional code to access these tables using local data adapters or from Schema scripts.

Data Abstract for Portable Class Library (aka DA/PCL). Yes, this release contains a (limited) port of Data Abstract to Portable Class Library. You can now build one Class Library and then reuse it in Silverlight, Windows Phone or Windows Store application.

Unfortunately the dreaded Technical Debt monster arose and strikes from the back so the PCL library has some limitations on the desktop .NET Framework. The problem is that the RemoteLinqDataAdapter class is located in differently named assemblies in desktop .NET and in all other platforms (namely RemObjects.DataAbstract.Linq.dll and RemObjects.DataAbstract.dll). Introducing the .Linq assembly back-when was a good (and the only) way to introduce DA LINQ without breaking support of .NET 2.0. And an additional assembly wasn’t an issue until a need to create portable set of assemblies arose.

I can say that we plan to provide improve this to more seamlessly support all four .NET platforms (i.e. Windows Phone, Windows Store (WinRT), Silverlight AND desktop .NET) in the next release of Data Abstract. Stay tuned ;)

Important note: Up to this release, non-desktop Data Abstract assemblies had a platform name suffixes in their names (f.e. RemObjects.DataAbstract.Silverlight.dll or RemObjects.DataAbstract.WinRT.dll). Since this release these suffixes exist no more, so ALL assemblies have the same name.

And now to the stuff now considered obsolete.

Data Abstract provides two binary data adapters: BinDataAdapter and Bin2DataAdapter. The former one, BinDataAdapter data adapter, is now considered obsolete and will go away in the next major releases. We have Bin2DataAdapter data adapter that serves the same purpose, is way more advanced and feature-full and, unlike the BinDataAdapter, is supported by Data Abstract on platforms other than .NET and Delphi. The only reason we still shipped BinDataAdapter this long was backwards compatibility. Yet it is time to finally take a step forward and leave this obsolete data adapter behind. So, in the unlikely case that you are still using this data adapter, you really should to consider to switch to the Bin2DataAdapter data adapter. There’s no downside.

Also we have a set of ASP.NET components provided in the RemObjects.DataAbstract.Web.dll. This entire .dll will be removed in the next major release, and has been marked as obsolete. The reason behind this is that the very approach implied by these components is outdated and based on an old model of using ASP.NET. Mixing the UI (ie .aspx code) and data access results in dirty code and errors that can be detected only at runtime, thus resulting in a nightmare while supporting such apps. Believe me, I know. So if you are not using the RemObjects.DataAbstract.Web, then there is no need to worry. If you do then I’d strongly suggest you to either move to the properly layered architecture, where UI has no data access code and/or to take a look at the Data Abstract for JavaScript. It allows to create modern and robust UI and is shipped together with Data Abstract for .NET.

That’s all for now.

Still stay tuned – soon I’ll show you some exciting new features of RemObjects SDK and Data Abstract.

Avatar of marc

by marc

Visual Studio 2013 is here (for some values of “here”)

October 22, 2013 in Data Abstract, Oxygene, Visual Studio

The time has come, and Visual Studio 2013 is officially RTMed and available on MSDN, even though the official launch event is not scheduled until November 13th.

What does Visual Studio 2013 mean for our users?

Oxygene has been ready for Visual Studio 2013 for a while now (and i personally have been using 2013 exclusively ever since i redid my development VMs earlier this year and when VS2013 was still a private CTP we weren’t allowed to talk about). Visual Studio 2013 support for Oxygene made it into our public releases back in August, and our latest September 2013 update is fully ready for the RTM version of Visual Studio 2013. SO if you have an MSDN subscription, you can download your copy now, run the latest Oxygene installer, and you’ll get the full Oxygene experience in the fresh new IDE.

We’ll be rolling out the Visual Studio 2013 Shell with Oxygene in our upcoming (major!) November 2013 release. (We got one more release coming up before, the incremental October 2013 update, but that had been locked down before the RTM was available, and also we’ve been asked to hold of shipping the 2013 Shell until after the official launch event. ;).

Data Abstract and RemObjects SDK also have been made ready for Visual Studio 2013 with the last update we shipped in September. This applies to the .NET editions, Data Abstract for JavaScript and also – if you are using Oxygene – the editions for Java and Cocoa. We’ll be doing more testing with the RTM release, and the next update might include additional tweaks and improvements to round this off.

 

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

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.

Avatar of marc

by marc

2013.2 and Beyond

July 17, 2013 in Data Abstract, non-tech, Oxygene, RemObjects

Hi, everyone.

As we go into the second half of 2013, i wanted to talk a bit more about our plans moving forward, what we have been working on and what we are working on and planning for the foreseeable future.

Oxygene

I can’t believe it’s only been a little over a month since we released Oxygene 6 and Nougat, and so far the feedback we’ve been getting has been just incredible. I am really thrilled to see so many of you diving into Mac and (more so, unsurprisingly) iOS development with Oxygene. Cocoa is a great and exciting platform to be working on, and that will only become more so with the upcoming releases of the groundbreaking new iOS 7, and with OS X Mavericks (both of which i know lots of you have already been using the betas of with Oxygene successfully).

We’re not sitting on our laurels, but moving ahead full steam with development of Oxygene and related technologies, and we have a lot of cool things coming up this and next year.

For starters, we’ve been working on an incremental “July” update for Oxygene 6 to address some bugs and add some minor enhancements here and there. “Gammas” for this release have been out for a while, and we are very close to finalizing the update (think a week or so). July, versioned as 6.0.51 will be a free update for all active subscribers and all Prism XE3.2 users (Embarcadero might have abandoned you on the roadside like a toy they have lost interest in, but we’re not giving up on you!).

Hot on the heels of that will be our August release. Versioned as Oxygene 6.1, this will be a significant update release for Oxygene with a handful of really cool big features and featurettes that i, personally, am very excited about. Of course there is full support for the new Visual Studio 2013 that Microsoft recently announced. There’ll also be ASP.NET MVC 4/4.5 support, and some really cool IDE workflow enhancements, some of which we have been working on for a long while in the background. The first “alpha” of Oxygene 6.1 is available for active subscribers now.

(Do note that as of Oxygene 6.1, the product will no longer be accepting Embarcadero Prism serial numbers, as our collaboration period with the great people at Embarcadero has come to an end for good by the time 6.1 ships. If you are a Prism customer with Software Assurance beyond August 2013, please make sure to contact us, we will take care of you.)

Beyond 6.1, i just want to name-drop a few projects/technologies that we are working on, without going into much (or any, really) detail on them, yet.

There’s “Hydrogene” coming up, which we’ve been dropping a few hints about here and there for a while now. Hydrogene is an exciting new sister product for Oxygene that we think will really be a game-changer. We’ll be rolling out Hydrogene to select beta testers soon, and the plan is to ship the “1.0″ product with the Winter (November) release cycle of Oxygene. This is not a promise for a timeline, though, and we won’t ship (or formally announce) Hydrogene until it is ready.

2014 will be a very exciting year for Oxygene and Hydrogene, and we have three related projects that will bring everything together in ways you cannot even imagine yet:

Fire” started as a personal side-project of mine that runs orthogonal to Oxygene (and Hydrogene), and has recently been ‘promoted’ to something we’re officially pursuing as a company project (and which has made great strides since). If and when it ships, hopefully sometime in 2014, it will become a regular part of the Oxygene and Hydrogene products.

There’s also “Marzipan” and “Infrared” (who comes up with these code names, right?), two amazing under-the-hood compiler-level technologies that Carlo’s team has been working on. Thinking about the possibilities with these two techs makes me dizzy, trust me.

Data Abstract and RemObjects SDK

Over on the DA side, we also have big things in the works. We’ve been thinking a lot about the future direction for Data Abstract over the past year or so, and last month we made the decision to stop and switch gears a bit in how we develop and ship DA (and RO). The quarterly releases we have been doing are great for getting new features out on a regular basis, but they also make it harder for the team to sit back and focus on the bigger picture, and on more fundamental changes.

So we’ve decided to take a bit of a break. A break, that is, from shipping significant releases every quarter. As of right now, we’ll be focusing the majority of our R&D effort on the major “next generation” version of RO/DA, which we plan to ship sometime in the first half of 2014.

The umbrella code name for this project is “DA8“, but this is more than just another major version number increase. We are taking a step back and really rethinking DA, and (re-)designing a DA “for the next ten years” (to borrow a phrase). A lot has changed (and is changing) in our industry since we first came up with DA in 2003, and we have a lot of ideas and plans for what we want to do, to not only make DA stay relevant in the changing market, but to make sure that DA remains the leading and best infrastructure for your data access and server development.

Some of these plans are very concrete, some of them are still very vague and in flux. Some of these changes and features we will start talking about (or even have alpha/beta bits of) very soon, while others will remain under wraps a while longer. Some of these will ship with the first DA8 “1.0″ release in early 2014, while others will be longer-out. Once again, we’re starting on a new DA for a new decade of technology.

Of course active subscribers will stay in the loop on DA8 as it develops. We will have a regular stream of pre-release builds for you to let you get an early start on some of the new technologies and changes as they emerge.

We’re also keeping the current “7.0″ code base active in a branch, and we most likely will keep shipping (very light-weight) quarterly updates for August, November and/or February, to fix crucial bugs or support new platform versions — such as Visual Studio 2013 (which we already have a Gamma of RO/DA out for), Xcode 5/iOS 7/Mavericks, or Delphi XE5.

Summary

As you can see, whether you’re using Oxygene or Data Abstract and the SDK (or both!), we have a lot of cool things planned for you for the next twelve months and beyond. Here at RemObjects, we are very excited about all of these projects, and we can hardly wait to show and tell you more.

Yours,

marc hoffman
Chief Architect

Avatar of Anton

by Anton

NetworkServer – an easily configurable RemObjects SDK server component

July 16, 2013 in .NET, Data Abstract

Introduction

In the previous article I’ve described how to create a RemObjects SDK server and set up the needed server components and tie them together.

The main purpose of the RemObjects SDK and Data Abstract frameworks is to simplify the development of distributed applications, yet some of the tasks needed to create a server application are the same for each server (f.e. server startup code, network component with server channel, messages, session manager etc).

Last year we introduced the ApplicationServer helper class (a unified base class for RemObjects SDK-based servers), so you can concentrate on the server’s business logic, not on writing the same (most of the time) server application startup code with all these checks like “are other instances of the server already running”, “do we need to start as a Windows Service” etc.

Now it is the time to make one more step forward and take a look at another core server application part that is again implemented in the same way as most of the server applications – the network connectivity part.

Network connectivity components include the server channel, one or more server messages, the session manager, event sinks, the event queue manager, the ZeroConf support component, etc. It is sometimes boring and error-prone to properly set them all up manually, and f.e. changing the server channel type can be a lot harder than it ought to be.

So we decided to implement and implemented a feature called ‘Server Reconfiguration System’. In short, this new feature allows to set the server connectivity parameters via its configuration file:

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="ServerConfiguration" type="RemObjects.SDK.Server.Configuration.ServerConfigurationSection,RemObjects.SDK.Server" />
  </configSections>
  <ServerConfiguration>
    <ServerChannel type="superhttp" port="8101" enableZeroConf="true" />
    <ServerMessages>
      <ServerMessage type="bin" />
      <ServerMessage type="soap" />
    </ServerMessages>
    <SessionManager type="Memory" />
  </ServerConfiguration>
</configuration>

So there is no need anymore to rebuild the server application to change the Server Channel port, its type (i.e. protocol), or even to change the session storage from memory to Olympia Server.
And for sure, the generated components can be accessed via code and customized as needed.

Let's take a look at this new feature in action. As the only difference is how the server network connectivity is configured in step 7, please refer to the RemObjects SDK Beginners Guide for steps 1 - 6.

Server Application

7. Open the code-behind file for the main form (remember that our server app is intentionally primitive, so no properly layered architecture or 'Run As Windows Service' support is available here) and add the following private field:

private RemObjects.SDK.Server.INetworkServer server;

Also modify the form constructor:

public Form1()
{
    InitializeComponent();

    this.server = new RemObjects.SDK.Server.NetworkServer();
    this.server.LoadDefaultConfiguration();
    this.server.Start();
}

Now we have to provide the license information for the server components. To do this, add a file named licenses.licx to the server application project and set its Build Action to Embedded Resource. This file should contain the following text:

RemObjects.SDK.Server.IpTcpServerChannel, RemObjects.SDK.Server
RemObjects.SDK.Server.IpSuperHttpServerChannel, RemObjects.SDK.Server
RemObjects.SDK.Server.IpHttpServerChannel, RemObjects.SDK.Server
RemObjects.SDK.Server.NamedPipeServerChannel, RemObjects.SDK.Server
RemObjects.SDK.Server.LocalServerChannel, RemObjects.SDK.Server
RemObjects.SDK.Server.HttpSysServerChannel, RemObjects.SDK.Server
RemObjects.SDK.Server.HttpSysSuperHttpServerChannel, RemObjects.SDK.Server
RemObjects.SDK.Server.SuperTcpServerChannel, RemObjects.SDK.Server
RemObjects.SDK.Server.EventSinkManager, RemObjects.SDK.Server
RemObjects.SDK.Server.MasterServerSessionManager, RemObjects.SDK.Server
RemObjects.SDK.Server.MemoryMessageQueueManager, RemObjects.SDK.Server
RemObjects.SDK.Server.MemorySessionManager, RemObjects.SDK.Server
RemObjects.SDK.Server.OlympiaMessageQueueManager, RemObjects.SDK.Server
RemObjects.SDK.Server.OlympiaServerSessionManager, RemObjects.SDK.Server

At build time the license compiler will embed the needed license information into the server application based on the class names provided in this file.

The server application can now be started. It will use the default settings (i.e. the Http Server Channel will be listening on port 8099 and Binary Message will be used to communicate with the client applications).

8. Add the Application Configuration File item to the server app project and add the following settings:

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="ServerConfiguration" type="RemObjects.SDK.Server.Configuration.ServerConfigurationSection,RemObjects.SDK.Server" />
  </configSections>
  <ServerConfiguration>
    <ServerChannel type="superhttp" port="8101" enableZeroConf="true" />
    <ServerMessages>
      <ServerMessage type="bin" />
      <ServerMessage type="soap" />
    </ServerMessages>
    <SessionManager type="Memory" />
  </ServerConfiguration>
</configuration>

Note: To ensure that the .NET application config file handlers will be able to properly load custom config sections, set the Copy Local property of all referenced RemObjects SDK assemblies to true.

After restart the server application will expose its services via the SuperHttp Server Channel listening on port 8101. And this without a single code line changed.

Now it is possible to change the Server Channel protocol (HTTP, SuperHTTP, TCP, SuperTCP), the port it is listening to and other options without the need to rebuild the server application.

A full list of available options will be provided in the corresponding Wiki article.

Conclusion

The introduction of the NetworkServer class and the corresponding infrastructure allows to easily create highly configurable RemObjects SDK server applications.

Avatar of Anton

by Anton

RO/DA for Visual Studio 2013 is here

July 4, 2013 in .NET, Data Abstract, Visual Studio

The Red Queen once said, “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!“.

Several days ago Microsoft released a preview of the Visual Studio’s next version – Visual Studio 2013 Preview (it can be downloaded from the official Visual Studio site). So Data Abstract for .NET and RemObjects SDK for .NET (as well as the other Visual-Studio-based editions) were updated to support the new Visual Studio version, and I can gladly report that New Project Wizard, DA LINQ Wizard and other IDE integration stuff “just works” in the new IDE.

Visual Studio 2013

To let you get started with Visual Studio 2013 yourself, we have made a new Gamma release available on beta.remobjects.com. Note even though this version is technically a pre-release, it is identical to the May 2013 release except for the added VS2013 support, and should be very stable and production safe. We will release a ‘real’ Beta soon with other bug fixes and improvements (and marc lets me know that an Oxygene 6.1 beta with VS2013 support is imminent, as well).

Anton,
Team Lead, DA/.NET

Avatar of marc

by marc

Introducing the RemObjects “Beta” app for iOS and Android

June 26, 2013 in Android, Build System, Data Abstract, iOS, Oxygene, Uncategorized

We’re constantly trying to optimize the workflow for publishing and announcing beta releases. Oxygene has been on a weekly beta cycle for a long while now and we’re trying to get RO/DA onto a more regular (maybe bi-weekly-ish) cycle as well (i’ll be writing more about our upcoming plans for RO/DA over the next year or so, soon), and we want to make the process of publishing new beta builds easy for us, and the process of being notified about new beta builds easy for you.

As part of this, two changes have been made recently.

Firstly, if you have installed any beta build of a product post our May 2013 releases, our Everwood Update Check will now notify you not only of new release versions, but also of new beta builds being available – making it very likely you’ll be find out about new builds within 24 hours of actively using a beta product.

But we wanted to do more, and so we’ve started developing an app to keep the hard-core beta users amongst you even closer in the loop: Welcome to the “Beta” app.

“Beta” is a small app, available for iOS and Android on the respective app stores. The iOS version has been available for a couple of weeks now (i got it approved shortly before WWDC), and the Android version is live as of now. What does “Beta” do? Two things, really.

The most important thing, it will receive and show to you Push Notifications when new beta (or release) builds for your products are available. Are you anxiously awaiting the next Oxygene beta drop each friday afternoon? Your iPhone or your Android will now let you know!

So “Beta” will be useful even if you never ever run the app again, after the first time.

But you can also go into “Beta” at any time, to see the list of current beta and release products available to you, including a shiny “NEW” badge on builds shipped within the past two days. Over time, we might expand beta to show more info (such as to let you know whether a new build is covered by your current subscription or not, look at change logs, and more).

What does “Beta” look like? Here’s the iOS version:

(including a sneak peak at what it will look like on iOS 7), and here’s the Android version:

So where to get the app? You can get “Beta” on the iOS App Store and the Google Play store, respectively. In addition, we’ve also made full source for the app available on GitHub; of course it is written in 100% Oxygene, the client apps and the Push server.



Avatar of marc

by marc

iOS 7 and OS X Mavericks

June 17, 2013 in Cocoa, Data Abstract, iOS, Mac, Oxygene, WWDC, Xcode

As you have probably heard by now, last week Apple announced iOS 7 and OS X Mavericks, new major versions of both its flag-ship operating systems. I had the privilege of being on site in San Francisco and attending WWDC in person, but the keynote with the core announcements is available for public viewing by anyone, and the remaining ~100 sessions of the conference are also available for free to all registered developers (major kudos to Apple for that, and more importantly, for making these videos available so fast, in most cases on the same day as the actual presentations!).

iOS 7 is a major new release and – most observers agree – a game changer. It’s a whole new UI paradigm for the OS, and will be a very exciting release for both users and developers; there are a whole bunch of new technologies that will let you create even better iOS apps, and will make the whole iOS experience even better for the user — in the core OS or with your apps.

Due to the massive UI overhaul, most iOS apps will need a serious rethinking for iOS 7 to stay relevant – which means extra work for developers, but also extra opportunities. From what i can tell (and am allowed to tell), switching an application over to the core iOS 7 “look” will be simple, but really making an app feel at home on iOS7 will require a lot of thought — no way around it.

I have already started moving two of our (internal) apps to iOS 7 while on site in San Francisco, simply because after (foolhardily) upgrading my main phone to the new OS, i could no longer stand looking at the old UI ;). One app is “done” and was relatively straight-forward – mainly a matter of rebuilding with the iOS 7 SDK, and making a few adjustments here and there to better embrace the new style; the other will be more work.

OS X Mavericks (if you don’t like the name, you are not alone. Virtually everybody i talked to or heard talk about it found it “weird”) is a smaller upgrade, by comparison, but also a significant release with a ton of exciting technologies for developers – two that were highlighted in the keynote include the new Maps API and cool new energy-saving APIs and technologies. (And if you’re not excited by being able to make your apps more power-efficient, then you have no business developing Mac apps! ;).)

Of course the big question you’re all asking is how Oxygene for Cocoa is working with the new iOS 7 and OS X Mavericks. The good (and slightly unexciting, because expected) news is: it works just fine. We’ve long had an article on the Wiki that discusses the (simple) steps for hooking up Oxygene with new beta SDKs, and Oxygene is working fine with iOS 7 and with Mavericks (although i do recommend grabbing the latest beta drop of Oxygene, as we already made some tweaks and improvements there).

All the new APIs (IIRC Apple mentioned a number of 1500 new APIs being available) will work with Oxygene out of the box – no need to wait for anyone to create any wrappers or headers for you, and re-building your Oxygene apps with the iOS 7 SDK will give you the new iOS 7 look right away (but not save you from re-examining how to really embrace iOS 7 best with your app, of course).

There are also a few new non-API features that we’ll be embracing with Oxygene as well, but unfortunately those are (afaict) all under NDA, so i cannot talk about them yet. But suffice to say over the next few months we will of course be doing a lot of testing with Oxygene and the new APIs and SDKs to keep Oxygene up to date with the SDKs and the Xcode 5 tool chain.

Of course we’ll also be testing Data Abstract and RemObjects SDK for Cocoa with the new SDKs, and (where applicable) expanding them with support for new APIs. In my testing so far, they work great (both the apps i mentioned above are DA-based, and run fine on iOS 7, for example).

Support

Talking about new iOS and OS X SDKs is always a tightrope walk, as there’s a lot of information that’s under NDA (but available to all registered Apple developers – so do make sure you check out the beta builds and all the videos from WWDC). But Oxygene, as well as RO/DA for Cocoa, are already working great with the new operating systems, and we’ll be working hard to expand those parts that do need explicit support and work to fully embrace the new OSs.

If you have any specific questions regarding support for or issues with the new SDKs, there’s two places to get help: for one, we’ll be monitoring and participating in Apple’s beta forums, so you can post questions about Oxygene there (maybe add “(Oxygene)” to the subject so we can find them easier). And you can also always directly email support.

We cannot discuss the iOS 7 or OS X Mavericks Beta SDKs on Connect; you could be violating your NDA by posting details there, and we’d be doing the same by answering. So be careful.

Summary

I’m very excited about both iOS 7 and Mavericks (and i assume i’ll eventually get over the name, too), and so should you. I’m looking forward to seeing what you’ll build on the new OSs with Oxygene and Data Abstract.