You are browsing the archive for Platforms.

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 Scotty

by Scotty

Setting Up For Android Development with Oxygene

January 9, 2014 in Android, Cooper, Oxygene, Uncategorized, Visual Studio

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

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

The Pre-Flight Check

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

Java Pre-Flight Check

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

Java SDK Paths

Java SDK

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

If you have not yet installed the JDK, you can download it from here.

Installing the JDK simply involves downloading the installer and running it, accepting all the defaults.

Install JDK

Once the JDK is installed, click Retest on the Pre-Flight Check dialog. If all has gone well, the dialog should change to report that the Android SDK is missing.

Android SDK

To create Android applications, Oxygene requires the Android SDK to be installed, in addition to the JDK.

If the JDK is installed, but not the Android SDK, the Oxygene pre-flight check will report this.

Android Pre-Flight Check

Download The Android SDK

The Android SDK can be downloaded here.

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

Android SDK Download

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

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

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

Android SDK Installer

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

Android SDK Installer Finished

The SDK Manager

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

Android SDK Manager

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

Android SDK Manager License

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

Android Virtual Devices

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

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

Launch AVD Manager From Visual Studio

The AVD Manager

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

Android Virtual Device Manager

Create an AVD

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

Define a Device

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

AVD Device Selection

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

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

Select an API

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

AVD Target Selection

Device Memory

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

AVD Memory Warning

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

Save The Device

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

Save Setting Dialog

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

AVD in List

Test The Device

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

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

AVD Launch Options

The AVD will then begin to start.

AVD Start Progress

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

AVD In The Emualtor

Testing Your AVD Setup

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

New Android Project

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

New Android Project Running In Emulator

Setting Up An Actual Device

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

Enable USB debugging on your device

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

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

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

Android 4.4 Developer Options

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

Install USB Drivers For the Device

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

Running Your App On The Device

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

Select Android Device

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

You Are Ready To Go

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

Good Luck!

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

Announcing the Oxygene “October 2013″ Update

November 4, 2013 in iOS, Nougat, Oxygene

Dear readers,

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

What’s New

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

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

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

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

How to get Oxygene 6.1.57

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

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

Oxygene for Prism Customers

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

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

More to Come

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

Happy coding!

Avatar of marc

by marc

“Steps” for iPhone 5S — written in Oxygene

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


Steps

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

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

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

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

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

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

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

 

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

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




Originally published on subspacecables.com.

Avatar of Anton

by Anton

Code Deodorant

October 28, 2013 in .NET, Oxygene, Tools, Visual Studio

We all write smelly code from time to time. Reasons are different, from ‘I’ll rewrite this code later, I just need this feature working now somehow’ to ‘Deadline is coming and this pesky bug is still not fixed’ or some mistake from a junior developer, yet the result is always the same. Every large codebase has lines of code that smell and stink. Of course there is an ideal codebase repository somewhere that does not have a single line of dirty code, or odd reinvent-the-wheel solutions, or patterns misuse etc… But, I’m afraid, that is along the lines of a flying unicorn. In the real world, we sometimes have to sacrifice code purity to deadlines or other reasons. In this case the main goal is to keep the unclean code and the technical debt caused by it manageable. Not a simple task, when the project has more than 55k lines of code, like ROFX/.NET (i.e. Data Abstract, RemObjects SDK, Internet Pack and Script for .NET) does.

So we need a tool that analyzes our source code and helps to pinpoint code that is potentially dirty. Such tools are called Static Code Analyzers. There are several of them available for .NET and I’d like to highlight the one I like best. This particular tool is not tied to C# or VB.NET and works perfectly with Oxygene code. It also provides Visual Studio integration (including the upcoming VS 2013), and it can also be run on a build machine as a part of the build process. This awesome tool is called NDepend (http://www.ndepend.com/).

In the following, we will create a simple application and apply NDepend to it. We’ll use Oxygene, as I need to show you how to avoid some sharp edges. While C# support in NDepend is near perfect, there are some (minor) nuisances that need to be avoided for Oxygene projects.

Let’s create an Oxygene for .NET Class Library project and add some code like this:

namespace SampleClassLibrary;

interface

type
  Class1 = public class
  private
    var fUnusedField: Int32;

    method NeverCalledMethod(); empty;
  public
    constructor(); empty;
  end;


  UtilityClass = public class
  public
    class method Foo(); empty;
  end;


 SomeBaseClass = abstract class
  public
    constructor(); empty;

    method AbstractMethod(); abstract;
  end;


implementation
end.

As you can see, there are several things that are not ideal, like unused fields and methods or the public constructor of an abstract class. This is, of course, simplified code, where all such things are clearly visible. At the same time, it is very hard to find all suspicious places in a real-world codebase, where the code was created by dozens of different developers and is spread between several projects containing several hundreds of code files. Of course thorough code review would help, but it is still a question of how much efforts it would require. And the question that remains – even after the code review – is to be sure that everything is clean?.

Enter NDepend.

Attach NDepend to the current solution using the menu item NDepend -> Attach new NDepend project to current VS solution.

Because NDepend doesn’t recognize Oxygene projects out of the box, we need to reference the compiled assemblies instead of the source code project, as we would do for C# or VB.NET projects. Press the ‘Add assemblies in Folder‘ button and select the folder containing the current project’s compiled assemblies. Note that NDepend will automatically preselect the folder containing compiled assemblies for the active project.

Confirm the folder selection. Assemblies will be added to the NDepend project.

Press the ‘Analyze a single .NET assembly‘ button and the project analysis will start. After it completes (a very fast procedure, even for big full Data Abstract for .NET solution), a helper dialog will appear.

Open the NDepend rules explorer (NDepend -> Rule -> View Queries).

As you can see, some entries are marked with a warning sign. These are rules that are potentially violated and were successfully detected by NDepend.

  • The abstract class SomeBaseClass should have a protected constructor instead of a public one.
  • The UtilityClass class should be static.
  • The abstract class SomeBaseClass is potentially dead code (it has assembly-only visibility and isn’t used anywhere it this assembly).
  • The Class1.fUnusedField field is not used anywhere and is thus not needed.

Try NDepend on your project and most likely you’ll find some potentially dangerous code lines.

As you can see, NDepend is mostly language independent, so all tutorials and tips ‘n tricks found at http://www.ndepend.com/ can be used with Oxygene, too.

One last advice: For some rules you won’t be able to navigate to a method or class violating some rule by double-clicking the method’s name.

This happens because in some cases (for navigation purposes) NDepend relies on its built-in language parser (that is limited to C# only) rather than on .PDB information. This custom source code parser is used because .PDB files provide information about source code declarations of concrete methods only, so additional effort is needed to acquire information about source code for namespace and type declarations.

To make it easier to find the problematic method, modify the code validation rule output by adding the full method (or class) name. To do this, just change the “rule output statement” (usually found at the very end of each rule’s query code) from code like this (for the Methods that could have a lower visibility rule):

select new { t, t.Visibility , 
                CouldBeDeclared = t.OptimalVisibility, 
                t.TypesUsingMe }

to this:

select new { t, t.Visibility , 
                CouldBeDeclared = t.OptimalVisibility, 
                t.TypesUsingMe,
                t.FullName }

Now you’ll see the full path (including namespace and class name) of the problematic entry.

P.S.: Don’t be afraid of the NDepend query language. It is a very powerful way to define own or customize existing code validation rules. At the same time, the predefined rules set allows to use the code analyzer without even touching the query language at all (except for the above-mentioned issue).

P.P.S.: Before you say ‘Hey, this thing is way too expensive’, try to estimate how much time it will save you and your team members and how much this time costs.

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

Announcing the Oxygene ‘September 2013′ Update

October 2, 2013 in Cocoa, Java, Oxygene

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

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

iOS 7.0

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

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

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

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

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

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

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

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

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

64-bit

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

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

Java

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

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

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

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

There’s More

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

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

Yours,
marc hoffman
Chief Architect

Avatar of marc

by marc

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

September 30, 2013 in Data Abstract, iOS, Xcode

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

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

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

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

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

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

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

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

Let us know what you think.

Android resources

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

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

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