You are browsing the archive for Data Abstract.

Profile photo of marc

by marc

Introducing DA8, the next major version of Data Abstract and RemObjects SDK

June 27, 2014 in Data Abstract, Relativity

We are incredibly pleased to announce the immediate availability of “DA8″, the next major version of our long-standing Data Abstract and RemObjects SDK products.

What’s New in Data Abstract 8 (and RemObjects SDK 8), Summer 2014?

The Summer 2014 release marks only the first update in our “DA8″ product cycle that brings a revitalization of the Data Abstract and RemObjects SDK frameworks, which now can look back on a proud history of twelve years and five platforms. This release contains a range of major new features that we are very proud of, and that we think will make DA and RO even more useful for your day-to-day work; it also contains a lot of cleanup for our oldest platforms (in twelve years, any library will gather some cruft) and a lot of streamlining, and it sets the base for more features and improvements that we have in the works for DA8 over the near future.

Relativity in the Cloud

One of the big new features for Data Abstract 8 is support for what we like to call “Relativity in the Cloud”. The hosting landscape has changed since DA was first conceived, and, to achieve scalability, more and more businesses are using cloud solutions such as Amazon Web Services or Azure to host their services.

While it has always been possible to run DA server on these services “manually”, we wanted to do more, so for DA8 we have extended Relativity Server to fully embrace the kind of changes and challenges that go hand-in-hand with those deployment scenarios.

For the first release of DA8, we focused on AWS, and Relativity Server now knows about the services provided by AWS that it needs to interact with, all without you writing manual code or setup scripts. You can boot our pre-built machine images to have Relativity Server up and running within seconds, and Relativity Server can automatically configure itself from S3, use databases hosted in RDS, and optionally use DynamoDB for world-scale session management.

It’s never been this easy to get an infinitely scalable middle tier up and running, with just a few clicks and without a single line of code.

You can read more about this here.

We’re working on other cloud services for subsequent updates, with Microsoft Azure being next on our list.

Strongly Typed DataTables in Cocoa

Users of Data Abstract on .NET have long enjoyed working with strongly-typed data tables, where classes are generated based on your schema that let you access the individual fields by proper names. With DA8, we’re bringing this over to Data Abstract for Cocoa, making it even easier than before to write client-side database code.

With just a couple clicks in Schema Modeler for Mac or in the Visual Studio IDE, you have protocol/interface stubs for your tables in the language of your choice — be it Objective-C, Oxygene, RemObjects C# or Swift — that let you work with your data much more naturally. row[@“CustomerName”] simply becomes row.customerName — it’s as easy as that.

Relativity Web Admin

To make administration of Relativity Server even easier, we have added a brand new Web Admin interface that lets you administer your servers right from your browser, without the need for the Admin Tool or Server Explorer for Mac. This works well with Relativity Server in the Cloud, but also with regularly hosted Relativity Server.

Just go to the /admin URL of your Relativity Server, log in with your Admin or Developer login, and you’ll have full access to controlling your server — from changing network settings over configuring logins to managing your domains and Schemas. And you can launch right into Schema Modeler with a single click to start modeling your data layer.

All New “PCTrade 2.0″ Suite of Sample Apps

Data Abstract 8 also includes a brand-new sample database and brand-new suite sample applications that go with it. PCTrade version 2 has been redesigned from the ground up to make it easier to get you started with Data Abstract and try out its features. That’s great whether you’re new to DA or a veteran user learning a new feature.

The new samples are more consistent across platforms, and many samples come in simple command line versions (that let you focus on the core technology) as well as GUI versions (that show you how it integrates with your app). There’s also a new all-encompassing “PCTrade Office” sample that shows you how everything can come together in a more complex and sophisticated project.

You can read more about this here.

PCL Support for .NET

Cross-Platform development is an important topic for many of you, and while Data Abstract comes in distinct native versions for all platforms, many developers choose to use the .NET and Mono framework to target multiple platforms from one managed codebase. Data Abstract 8 comes with full support for building Portable Class Libraries (PCLs) that allow you to build one set of code, in one assembly, and reuse that on all versions of the .NET runtime — from the desktop to Silverlight, Windows Phone and WinRT to cross-platform Xamarin apps.

You can read more about this here in Anton’s blog post.

Improved/New Async APIs for RO/.NET and RO/Delphi

There’s been a big paradigm shift for how network code is written since the original versions of RemObjects SDK for Delphi and for .NET shipped over ten years ago, and more and more developers are using asynchronous call methodologies. The newer platform editions of RemObjects SDK and Data Abstract, starting with RO/Cocoa back in 2008, have already embraced this in their API design, but writing asynchronous code with RO/.NET and RO/Delphi has been difficult on the client side. That is, until now.

Starting with version 8, RemObjects SDK for .NET and for Delphi have brand new APIs that make it easier than ever to write async code. On .NET, these new APIs leverage the new async/await pattern available in C# and Oxygene with .NET 4.0; on Delphi, they work with callbacks, using anonymous methods in newer versions of Delphi, for a model that is similar to block-based APIs on Cocoa.

These changes will make it a lot easier to write responsive client applications, and they also bring the two “more mature” platforms more in line with how client call code already worked in the three newer playrooms, Cocoa, Java and JavaScript.

Cleanup and Freshen-up

New features aside, we’ve also taken the opportunity of this new major release to do some house cleaning. As you know, some of the platform editions of Data Abstract and RemObjects SDK are now over ten years old. They have evolved a lot in that time, and we also had a lot of chances to learn, as we kept adding additional platforms to the mix — rewriting, and to a certain degree re-inventing the product from scratch for each platform. DA8 takes the opportunity to freshen up the older code bases to things we learned from the newer implementations (such as the async support mentioned above), and also to remove and trim some old cruft that had accumulated over time.

As a result, the new editions are leaner, meaner, and ready to move forward for the next ten years of innovation we have planned.

But don’t worry — we have taken special care to make sure that all your existing projects will of course still build ok, and that updating/migrating to the new version is as easy as ever. And of course RO8 and DA8 remain fully wire compatible with older versions, as well.

Bugfixes, Enhancements and More

And of course, as always, in addition to these major new features, the new releases also come with a huge number of other, smaller fixes, improvements and enhancements to make the product even better and more enjoyable too, day to day. This includes improvements to the Schema Modeler and Service Builder tools, updates to the APIs, and enhancements to the IDE integration and experience.

Here at RemObjects, we’re super excited about this new release and about where Data Abstract is going, moving forward. We hope you’ll enjoy it, too!

Profile photo of Anton

by Anton

PCLs, async/await server calls, and more…

June 26, 2014 in .NET, Data Abstract

The new Data Abstract 8 is out. So I’d like to highlight some of its features and the changes they imply.

Xamarin support changes

To start with, the Xamarin iOS and Android platforms are now supported via Data Abstract for the Portable Class Library. This means that there is no more separate Data Abstract for MonoAndroid or MonoTouch builds.

On the bright side, this means that both target platforms now share the same set of features and, due to the PCL support, development of code shared between iOS and Android targets becomes a little easier. There are, however, some caveats you should be aware of:

  • Only DA LINQ data access is supported, DataSet support on the iOS side is not available anymore, so a data access code revamp is needed.
  • Only the simple HTTP client channel is available in Data Abstract for PCL. While this might look restricting, it is still the best choice for apps targeting mobile devices operating with a potentially unstable connection. In such conditions, SuperHTTP has no considerable advantage over the simple HTTP client channel.
  • Only asynchronous server calls are possible. While this is a must in the mobile world due to unpredictable network delays, it can be a real headache when the Begin/End asynchronous calls pattern is used, especially when several remote calls are chained in the same method. Luckily, starting this release, RemObjects SDK for .NET now provides support for async/await remote calls.

async/await remote calls

Old async code with callback methods and BeginOperation/EndOperation calls was hard to develop and maintain. Starting with the Summer 2014 release, RemObjects SDK now allows to call remote servers using code like:

var result = await service.SumAsync(1, 2);

Of course, the target platform also has to support await calls, so this feature is not supported for .NET 3.5 clients. For all other target platforms,_Intf code will contain method declarations like:

public interface ISampleService_Async : RemObjects.SDK.IROService_Async {
    System.IAsyncResult BeginSum(double a, double b, System.AsyncCallback @__Callback, object @__UserData);
    double EndSum(System.IAsyncResult @__AsyncResult);
    System.Threading.Tasks.Task SumAsync(double a, double b);
}

Note the last method declaration. It is the asynchronous server call proxy that can be called using the async/await pattern.

Unfortunately, it is not possible to expand the DataAdapter class with …Async methods due to the necessity to support .NET 3.5. Instead, a set of extension methods was introduced that provide nearly the same experience.

These extension methods are defined in the assembly RemObjects.DataAbstract.Async.dll. For platforms that support Extension SDK packages (f.e. Windows Phone) this assembly is included in the Data Abstract packages. On other platforms (f.e. desktop .NET) this assembly has to be referenced explicitly.

Note that to call an extension method, you need to add the namespace this method is declared in to the using (C#)/Imports (VB.NET) or uses (Oxygene) clause.

The following extension methods are provided:

  • IBaseLoginService_Async interface, methods are declared in the RemObjects.DataAbstract namespace.

    • Boolean LoginExAsync(String)
    • LogoutAsync()
  • DataAdapter (including LocalDataAdapter and RemoteDataAdapter), methods are declared in the RemObjects.DataAbstract namespace. All methods are awaitable versions of corresponding synchronous DataAdapter methods.

    • FillAsync(DataSet, Boolean)
    • FillAsync(DataSet, Boolean, Boolean)
    • FillAsync(DataSet, String[], Boolean)
    • FillAsync(DataSet, String[], WhereExpression[], Boolean)
    • FillAsync(DataSet, String[],TableRequestInfo[], Boolean)
    • FillAsync(DataTable, WhereExpression, Boolean)
    • FillAsync(DataTable,TableRequestInfo, Boolean)
    • FillWithDASqlAsync(DataTable, String, DataParameter[])
    • UpdateAsync(DataSet)
    • UpdateAsync(DataSet, String[])
    • UpdateAsync(Delta[], Boolean)
  • LinqDataAdapter (including LocalLinqDataAdapter and RemoteLinqDataAdapter), methods are declared in the RemObjects.DataAbstract.Linq namespace.

    • LoadListAsync<T>(IQueryable<T>) – asynchronously loads data into List<T>
    • LoadBindableListAsync<T>(IQueryable<T>) – asynchronously loads data into BindingList
    • ApplyChangesAsync()

    Asynchronous data loading using one of these methods will look like

    var list = await fDataAdapter.LoadListAsync(
            from x in fDataAdapter.GetTable<Clients>() select x);
    

Windows Phone Applications support

This application type has a somewhat misleading name. Microsoft has renamed the good old Windows Phone apps based on Silverlight to Windows Phone Silverlight applications and introduced new WinRT based phone applications as Windows Phone. We register Data Abstract and RemObjects SDK as Extension SDKs for both these platforms. In case you want to reference Data Abstract assemblies directly, you need to reference assemblies from the WindowsPhone folder for Silverlight based applications and assemblies from the WinRT folder for Windows Phone Store applications. It is strongly recommended to use the ExtensionSDKs’ references instead of direct assembly references to avoid situations where wrong assemblies are referenced and the application just cannot be built.


That’s all for now. See you around and don’t forget to check the Breaking Changes page!

Profile photo of marc

by marc

Xcode 6, iOS 8, Yosemite, Swift, and You

June 4, 2014 in Data Abstract, Elements, RemObjects C#, WWDC

As you’ve probably heard by now, Apple release a whole lot of goodness for developers on Monday. As an Oxygene or RemObjects C# (or even a Data Abstract for Cocoa) developer, you’re probably asking yourself how these changes affect you.

Obviously, there’s a lot of things we cannot talk about yet — in part because it’s been less than two days since the new stuff was announced and we need to do a lot more research — and in part because many of the details are under NDA, and will remain so until Fall.

So, what can we say?

iOS 8 and OS X 10.10 Yosemite SDKs

The new SDKs import fine with the latest Gamma build of Elements that’s available to licensed users, and they will import fine with the imminent June release (based on that Gamma) that is coming later this week.

Why do you need a new build? Two reasons: We expected OS X 10.10 to not import with the previous version, simply because the internal integer versioning system Apple uses for OS X was reaching a conflict at 10.10 and our importer wouldn’t know how to calculate the right version code, until we looked at what Apple decided to do there. So that is broken “by design”. There were also a couple of small oddities in both 10.10 and 8.0 that our importer didn’t handle (basically, some Objective-C construct that was too weird for us to run into it sooner). Those had to be fixed.

In general (and moving forward) we aim for new Beta SDKs to import clean with current/previous Elements builds, w/o requiring action from us, of course.

Xcode 6

With the new SDKs imported, Oxygene and RemObjects C# work, as far as we can tell in our limited testing, fine against the new Xcode 6 command line tools, besides some issues with the Simulator APIs, which have changed pretty significantly in version 6.

If you run into any problems, remember that you can always change the version of Xcode that Elements sees back to Xcode 5.1, using the xcode-select tool, without needing to de-install Xcode 6. So you don’t need to hesitate about installing Xcode 6.

Of course we need to and will do more testing (especially on some of the areas with new features) to get Xcode 6 fully supported by the time it ships.

Swift

Of course the big announcement on Monday was Swift — Apple’s new programming language that’s destined to replace Objective-C in the long (or even short) run. It’s very exciting to see Apple take this step, which frankly I had been expecting – but not quite so soon, and not with such a drastic change in language style (Swift is *very different).

Swift opens up a lot of opportunities, but also challenges. On the one hand it “competes” with our Oxygene and RemObjects C# compilers for the spotlight of “more modern languages on Cocoa”, but on the other, it also opens developers up to the very idea that Cocoa does not have to mean Objective-C.

There’s also a lot of technical work for us to do. Swift does not compile to straight Cocoa objects, but brings its own object layer and APIs that Oxygene an RemObjects C# developers will want to interact with, and there’s work needed there — work that I can’t talk about in more detail, because much of Swift is covered by the Apple NDA until it is released. Of course we are fully committed to making this work, so that you can use code written in Swift as seamlessly from Elements as you can use the code written in Objective-C today.

If you’re a Data Abstract or RemObjects SDK for Cocoa developer, you’ll probably just want to use those libraries from Swift. This should just work out of the box, because Swift and Objective-C already mix and interact seamlessly in Xcode 6. Of course we’ll do a lot of testing on this front, see if maybe RO/DA can use some API revisions to make it work even better with Swift, and we’ll be providing project templates for Swift once Xcode 6 ships.

I will keep you updated as things develop. For now, I’ll let you get back to playing with the new toys!

Yours,
marc

Profile photo of marc

by marc

New Betas!

April 24, 2014 in Data Abstract, Elements, RemObjects C#

Hi everyone.

Over the past weekend, we shipped major new beta builds for, well, just about every single one of our products.

 

On the Elements front (Oxygene and RemObjects C#) we’ve also shipped the first beta for the May 2014 update, which will be a minor bug-fix update, but has a lot of significant improvements nonetheless. Check out the change log for details. (Of course, before that, the April update with version 7.1 is imminent and has been in gamma and locked down for a while; we expect that to ship as RTM this week.)

 

For our ROFX products, including Data Abstract and RemObjects SDK, I know that many of you are looking forward to the major new “DA8” (and RO8) release. Well, last week’s beta is the first publicly available beta off that development branch, and will give you a first peek at what’s coming in DA8. It’s far from feature complete, but there’s a lot of new and exciting stuff already there, from new features to support hosting Relativity in AWS, over better asynchronous APIs for Delphi and .NET (all the other, newer platforms already had pretty nice async APIs to begin with), to our all-new and very extensive PCTrade2 sample suite. From improved DA SQL client support in DA/Delphi, over Amazon DynamoDB Session Manager support, to our new Login Provider infrastructure. But there’s still more to come.

As part of the new DA8, we’ve also been doing a lot of “spring cleaning”, bringing the codebase (especially for the older and more mature products for Delphi and .NET) up wit the times, and removing some old cruft that as accumulated over the years as the frameworks evolved. Please refer to the change logs (available on beta.remobjects.com and in the Beta app), as well as the ROFX Beta forum on Talk for details.

Oh, I should mention that this beta also includes support for the just-released Delphi XE6, and the same goes for the new Hydra 4 gamma build that is available, as well.

We’ll be publishing more regular semi-weekly beta updates for ROFX (much like we always do for Elements) as we prepare for the first “DA8” release to launch officially in May.

We’re very excited about this next release, and the team has been very busy. We hope you’ll like what you’ll see — and please let us know in the comments, in the beta forum, or via email to info@.

Profile photo 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

Profile photo 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.

Profile photo of marc

by marc

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

October 22, 2013 in Data Abstract, Elements, 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.

 

Profile photo 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?

Profile photo 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.

Profile photo of marc

by marc

2013.2 and Beyond

July 17, 2013 in Data Abstract, Elements, non-tech, 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