Avatar of marc

by marc

Staring into the Fire: Code Completion

September 8, 2014 in Fire

This post is part of a series in which I want to take a closer look at some of the features and functionality in Fire, our new IDE for the Mac. The topic for today is Code Completion.

Code completion, also called IntelliSense in Visual Studio parlance, is a crucial part of writing code these days. Instead of reading docs or knowing types and their members by heart, we rely on Code Completion to let us know and discover what APIs are there for us to use. And gone are the days of trying to save keystrokes by making names easy to type — because CC can help us type complex names, easily.

Of course Fire comes with state-of-the-art Code Completion in its code editor, driven by the same back-end engine that also provides CC data for our languages in Visual Studio. But while the content is the same, Fire takes the CC user interface to the next level, as we have really put a lot of thought into how we can improve the general experience.

In Fire, Code Completion will automatically activate as you type, wherever sensible. So you don’t need to think about it much, and it will automatically be there to help you, should you need it. Of course you can also manually invoke CC at the current cursor location, if so desired. You can either press Escape (which is the Mac default for this), or — if you’re still used to Visual Studio, and maybe switching a lot between the two IDEs — you can use Cmd-Space (after changing the global Spotlight shortcut, which you probably already did to use that combo on your VM, anyways).

CC is fast, but sometimes even the tiniest of interruptions can be annoying, so CC in Fire is completely asynchronous. Even while CC gathers info to show you, you can keep typing, or cursor elsewhere. If you type more of the current identifier, CC will adjust as you type to narrow your search. If you type or move away from the current identifier, CC will close (or never show, if you’re a really fast typer ;).

The CC “Soft Selection”

As Code Completion gets activated, you will notice that Fire will add a soft highlight to the current “token” that it considers relevant. This is a helpful indicator as to what part of your code will be replaced should you accept an item from the CC list.

If you use Visual Studio, you might have (consciously or subconsciously) noticed that sometimes when you select an item from CC, VS will replace the full token you are on, and other times, it inserts the new text in front of the existing text. If you’re like me, on more than one occasion you’ll have been annoyed that it did the opposite of what you wanted or expected. Fire’s visual indicator helps with that. For example, if you start typing at the very front of a token, chances are that you are adding a new token in front and don’t want to replace what’s already there, so CC will not absorb the text behind the cursor:

But if you invoke CC in the middle of an identifier, chances are you want to replace the whole identifier, so Fire’s UI will reflect that:

Not only does the “soft selection” show you what to expect, but Fire is also smart about picking the right “mode” for CC, depending on the context it finds itself in.

Partial CC

Fire’s CC also has a nifty way that helps you type complex names. Take the following example of very common Cocoa code:

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_NORMAL, …)

That is a huge pain to type, even with CC, because each the three identifiers starts with “dispatch_”, and there’s a huge list of those. So you end up either typing most of the names manually or doing a lot of scrolling through the CC list. Not anymore!

In Fire, when you press Tab or underscore (_), CC will automatically advance to the next underscore in the current item (or to the next item with an underscore. So for example, if you just type dis_g_g_q(, CC will smartly navigate you through the list so that you end up with dispatch_get_global_queue(|):

Similarly, Tab also jumps ahead between parts of PascalCased names. So it’s just NSFil<Tab>Ma<Tab> and you have NSFileManager.

The Devil’s in the Details

There are other small details that streamline the CC experience. When CC gets invoked and there’s no current token to soft-select yet (the most common case when you’re starting a new identifier), Fire will show a small “sliver” of a soft selection to the right of the cursor to show you CC is coming:

If you accept CC for a method by typing (, Fire will automatically insert the pair of parenthesis and put the cursor between them — if you accept CC with a different key, for example with space or enter, it will not.

Of course CC also handles multi-part method names in Oxygene, C# and Silver (even if they look like named parameters in the latter) — inserting the full method signature for you, and giving you “jump points” to let you tab from one parameter to the next:

If you ignore CC and “type through”, CC will smartly do the right thing when you come to the end of the identifier. For example, it will adjust the case of what you typed to the proper item in CC. But not if the version you typed would also be valid, as in the case below (which of course only happens in case sensitive languages, i.e. C# and Silver):

When you start typing in the middle of an existing identifier, CC will not drop down automatically. Chances are you’re trying to fix a typo or otherwise know what you’re doing, and our use testing showed that the CC dropdown just gets in the way. (Of course you can still invoke CC manually via Escape for that location — it will then cover the entire identifier.)

Just like these, there are lots of little tweaks and and “special cases” — some even language-specific — that fine-tune CC to behave as you’d want it to and not get in the way. Most of them being cases that you won’t actually notice — except by lack of being annoyed ;).

Summary

This post gave you a quick look at what Code Completion is like in Fire. Code Completion is implemented as part of Fire’s Code Editor, which we have written from scratch to give you the best possible code editing experience. I’ll talk more about the Code Editor in general in a future post.

Stay tuned, check out Fire, and make sure to let us know what you think!

—marc

Avatar of Alex

by Alex

Strong Typed Rows in the DataAbstract for Cocoa

September 1, 2014 in Uncategorized

Challenge

In DataAbstract for Cocoa, you can retrieve the values for a particular table field using the KVC approach, where the field name is passed as a string key:

DADataTableRow *row = [[self table] rowAtIndex:idx];
NSString *name = [row valueForKey:@"ClientName"];

Later, with help of the new indexing syntax for arrays and dictionaries, this code can be rewritten in a more simple manner:

DADataTableRow *row = self.table.rows[idx];
NSString *name = row[@"ClientName"];

But there is one flaw to that approach – the field name is passed as a string constant and thus can’t be checked in design time or selected in the code completion system.
The user still has to work with DADataTabeRow instances, where data is represented by the dictionary, rather than by business objects.

Solution

With the help of some “Magic” in Objective-C, we can now offer another approach for getting values for a particular column in a row.
You can just operate with a particular field in the table row as with a usual property.
This means that you can call any property in a row instance like this:

id fieldValue = [self.dataTable.rows[idx] MyFieldName];

If there is no such field in the table, you will get a proper exception, otherwise you will get its value.

It would also be great though if we could choose available fields using the Code Completion system inside the IDE.
This would simplify the code and allow to avoid various possible mistakes in specifying field names when working with data of the row.

And the answer is yes, we can do that.
All we need to do is to represent the available table fields as properties of a special protocol (interface) that the row can support.

This approach can be used in two ways:
The most simple way is to just generate protocols ad later cast the row instance to the row protocol. For example:

 
// Protocol
 
@protocol DepsTableRow_Protocol <NSObject>
@property (strong) NSString *DepName;
@property (strong) NSNumber *DepId;
@property (strong) NSString *DepPhone;
@end
 
 
// Code for obtaining data 
 
id row = self.dataTable.rows[0];
id<DepsTableRow_Protocol> typedRow = row;
NSNumber *depId = [typedRow DepId];
NSString *depName = [typedRow DepName];
NSString *depPhone = typedRow.DepName;// you also can use dot(.) for accessing field property
 
NSLog(@"%@(%@): Phone:%@:", depName, depId, depPhone);

Another approach is to provide a special row class for the particular table.
This class must be inherited from the base DADataTableRow class, but in addition, it can expose different properties:

//Protocol:
@protocol DepsTableRow_Protocol <NSObject>
@property (strong) NSString *DepName;
@property (strong) NSNumber *DepId;
@property (strong) NSString *DepPhone;
@end
 
// Custom row class 
@interface DepsTableRow : DADataTableRow <DepsTableRow_Protocol>
// you don't need to implement DepsTableRow_Protocol for declaring its properties
@end
 
// Code for obtaining data:
// First we need to register our custom row class for the particular table
// It should be done once per application start 
// The init method of the DataAccess module is usually a good place for doing that
[DADataTable registerRowClass:[DepsTableRow class] forTableName:@"Deps"];
 
// then later each row in the table rows array is the instance of our custom row
DepsTableRow *typedRow = self.dataTable.rows[0];
NSNumber *depId = [typedRow DepId];
NSString *depName = [typedRow DepName];
NSString *depPhone = typedRow.DepName; // You can use a dot(.) to access fields as properties
 
NSLog(@"%@(%@): Phone:%@:", depName, depId, depPhone);

Supporting Strong Typed Rows in Nougat

The same approaches are also available for Nougat projects and Oxygene:

// Protocol
DepsTableRow_Protocol= public interface
    property DepName: strong NSString read write;
    property DepId: strong NSNumber read write;
    property DepPhone: strong NSString read write;
end;
 
// Code for obtaining data 
var row: id := self.dataTable.rows[0];
var typedRow : DepsTableRow_Protocol :=  duck<DepsTableRow_Protocol>(row);
 
var depId := typedRow.DepId;
var depName := typedRow.DepName;
var depPhone := typedRow.DepPhone;
 
NSLog("%@(%@): Phone:%@:", depName, depId, depPhone);

and for RemObjects C# (Hydrogene):

// Protocol
public interface DepsTableRow_Protocol
{
    __strong NSString DepName { get; set; } 
    __strong NSNumber DepId { get; set; }
    __strong NSString DepPhone { get; set; }
}
 
// Code for obtaining data 
id row = self.dataTable.rows[0];
DepsTableRow_Protocol typedRow = duck<DepsTableRow_Protocol>(row);
 
NSNumber depId = typedRow.DepId;
NSString depName = typedRow.DepName;
NSString depPhone = typedRow.DepPhone;
 
NSLog("%@(%@): Phone:%@:", depName, depId, depPhone);

Generating protocols

The one remaining question is how to get those row protocols?

For Nougat projects created in MS Visual Studio, these protocols will be generated automatically by the New Project Wizard.
You can also update/regenerate these protocols any time you want – just run the wizard by clicking Create Table Definition Classes in the Solution Explorer window. TableDefinitions Wizard

For Xcode projects, you can generate the protocols directly from the schema node inside the Relativity Server in the Server Explorer for Cocoa tool. It allows to generate Objective-C, Oxygene and RemObjects C# protocols for Nougat projects. TableDefinitions Generator

Samples

Take a look at the StrongTypedRows (iOS) samples written in Nougat, Oxygene and RemObjects C#. We are providing them with the DataAbstract for Cocoa package.

Thanks for reading!

Avatar of Alex

by Alex

Using DataAbstract and RemObject SDK for Cocoa libraries in Swift

September 1, 2014 in Cocoa, Uncategorized

As you probably already know, Apple recently announced a new programming language called Swift, a new and fresh look at programming for the Mac.
The main and obvious purpose of Swift is to replace Objective-C in the future.

To develop for the Mac, RemObject Software offers two products, DataAbstract for Cocoa and RemObject SDK for Cocoa.
These products are designed using native Apple technologies and are written in Objective-C.
They are available as frameworks and as static libraries.

This brings us to the important question: Can I use existing libraries written in Objective-C in a program written in Swift?

The answer to that question is yes.

In order to access classes from Objective-C libraries from Swift, you need to create a so-called Bridging Header File and name it according to your product module name followed by -Bridging-Header.h.
Then you need to edit this file to expose your Objective-C code to your Swift code.
Just import every Objective-C header you want to expose to Swift. In our case, this will be the root Data Abstract header:

//
//  DAWithSwift-Bridging-Header.h
//
 
#import <DataAbstract/DataAbstract.h>

Then go to the project settings and locate the “Swift Compiler – Code Generation” section at the “Build Settings” tab, where you need to specify the bridge header file for the “Objective-C Bridging Header” build setting.
The path must go directly to the file itself, not to the directory it’s in.
The path should be relative to your project, similar to the way your Info.plist path is specified in Build Settings.
For example:

DAWithSwift/DAWithSwift-Bridging-Header.h

Also, do not forget to set the other build options to allow your application to locate and link it with the RemObjects libraries:

Library Search Path = "/Developer/RemObjects Software/Bin/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)"
Other Linker Flags = -ObjC -all_load -lxml2 -lDataAbstract

And that’s it, now all public Objective-C headers listed in this bridging header file will be visible to Swift.

The Objective-C functionality will be available in any Swift file within that project automatically, without any import statements.
You can now use DA/RO classes with the same Swift syntax that you can use with system classes.

 
//SWIFT
 
// Set up rda and server access
var dataAdapter: DARemoteDataAdapter
let url: NSURL = NSURL(string:"http://localhost:7099/bin")
self.dataAdapter = DARemoteDataAdapter(targetURL:url)
dataAdapter.dataService.serviceName = "DataService"
println("dataAdapter: \(dataAdapter.dataService.channel.targetURL)")

At the moment, most of Swift is covered by the Apple NDA until it is released, but after that we are going to simplify even those steps above.

Thanks for reading!

Avatar of marc

by marc

Staring into the Fire: The Build Process

August 6, 2014 in Fire

This post is part of a series in which I want to take a closer look at some of the features and functionality in Fire, our new IDE for the Mac.

Fire is designed to be light-weight and “get out of your way”, and one of the parts where this shines thru is when you build. Compiling your project is a frequent task in your day.to-day work, and an essential part of any development environment.

You usually start a build by either hitting Cmd-B (to just build) or Cmd-R (to build, and then run), and when you do, the build system goes off to do its thing in the background, but aside from that, nothing much changes. There’s no silly modal dialog telling you the IDE is building, or the like. After all, building is something that happens passively and once a build is fired off, there isn’t much you can do about it (although actually, that’s not quite true, more on that later on), so the IDE might as well just let you keep focusing on your code.

Building

So as Fire goes off to build, focus stays on the code editor (or wherever else it was before you hit Cmd-B), and you can just keep on coding. There’s only a couple of small indicators that a build is running: For one, the jump bar at the top of the window turns blue as the build runs and cycles thru the build tasks in the status area on the right. And if you’re in full screen “focus mode” with the code editor covering your entire screen, that’s all you see.

The application icon in the Dock also turns blue — which is handy if you actually are switching away from Fire while you wait for a build, as you can now see the build status and success/failure with one glance at the Dock or the Cmd-Tab app switcher.

When the build finishes, jump bar and app icon either go back to normal (if all went well), or they turn red (if one or more projects failed to build). That, and an optional notification center message, is your only indication that the build failed — again, nothing happens that pulls you out of the flow, as chances are you just went right on coding wile the build was happening.

Messages

Fire has no dedicated “Error Messages” view that pops up when a build fails. Instead, build messages are integrated with Fire’s regular navigation infrastructure: They fill into the jump bar at the top, for manual selection/browsing, and they also show inline in the text editor. Chances are, new build errors are happening right in the code you are currently working on, so having them show up where you are already looking at — the code window — is the best place for them, and in most cases, you need little else to find out what went wrong.

When you do, your favorite new keyboard shortcut will be Option-Cmd-M (or the Messages|Show First Message) menu, which — as the name indicates — jumps right to the first message generated by the build. If there have been errors, it brings you to the first error that was encountered; if there were none, it brings you to the first warning or hint, if any.

Of course, you can also look at the jump bar, which shows you all build messages under the Build Log node, and select a message from there.

Once you navigated to a message, you can use the Control-Command-Up and Down keyboard shortcuts (or Project|Navigation|Up/Down in the menu) to cycle between messages and jump from one to the other.

If you are the kind of person who does want to get distracted when building, Fire has a few options for you in the Preferences dialog, under Build & Debug: For one, you can choose to have Fire bring forward the build log either when a build starts, or when it fails. This option can be helpful in certain situations (for example when you are “debugging the build”, i.e. when you’re in a development mode where you’re looking at build issues and expect to look at the build log a lot), but I really recommend not turning it on for day-to-day work. You can also optionally have Fire jump to the first error if a build fails (which is how many IDEs behave, such as Delphi and Visual Studio — but again, I recommend against it, for the reasons outlined above).

Another cool thing you can do with build messages is copying code along with its messages to the clipboard. This is really helpful when you want to share a build problem with team-mates for help, or when you want to post questions about a build error somewhere. Simply select the range of code you’re interested in and press Option-Command-C (or Edit|Copy w/ Build Messages from the menu), and Fire will copy the code as you expected — but it’ll add any error messages to the code as well (prefixed by a // comment delimiter, so that the copied code remains valid). Really handy.

Don’t Stop Me Now.

Sometimes you press Cmd-B to start a build, and immediately regret it. This happens to me all the time: I write some code, press “build” to see if it’s any good, and the second I do, I spot that missing semicolon, that typo, or something else that’s silly. In Visual Studio, I’d now sit there and wait for the build to finish, just to go again, and that always has been a huge frustration to me. Not so in Fire.

There’s two things you can do when you started a build that you know will be no good. For one, you can press Cmd-. (or Project|Stop in the menu) and cancel the build. Bam, it’s stopped. More interestingly, if you just fixed that silly typo and want to build again, you can just hit Cmd-B again, and it will automatically cancel the current build and start fresh.

This might seem like a small thing, but I think you’ll find it a game changer in how you build — especially if you’re working on larger projects that take a few seconds to build. For example, a build of Fire takes between 10 and 30 seconds, depending on how large a portion of the project rebuilds, and depending on what kind of Mac you’re on (you really notice just how slow a MacBook Air is, by comparison, when building large projects ;)). Not having to wait that out every time I make a mistake has been a huge productivity boost for me.

What makes this even more helpful is that error messages form the build will come in and show in the editor one by one, as the build encounters them. So even if your build takes, say, 10 seconds, chances are you see your current line of code turn red after just a second or two if you made a mistake. Just fix it, press build again, and off you go.

This is just a small overview of how Fire integrates the build cycle into the IDE, and many of its subtleties are hard to do justice by just describing them. Give Fire a spin for yourself to see how this all works out in action — and make sure to let us know what you think!

Avatar of marc

by marc

Staring into the Fire: Search and Replace

August 4, 2014 in Fire

This post is part of a series in which I want to take a closer look at some of the features and functionality in Fire, our new IDE for the Mac. In this post, I’d like to look at Search and Replace.

Search and Replace is a core feature of any development environment, so of course Fire has sophisticated support for it. The basics work pretty much exactly how you would expect, but Fire goes a bit beyond, so let’s look at the feature in detail.

To start with, as you would expect, you invoke Find/Replace using the standard Cmd-F keyboard shortcut (or via Edit|Find in the menu), which brings up the Find/Replace popup:

Here, you can type a search term and — as you’d expect — you can also choose whether this search term should be treated case sensitive, whether to match whole words/tokens only, or whether to treat the term as a RegEx. As you make your selection here, you will see that it will automatically reflect in the open editor, highlighting every occurrence of the search term in text marker yellow. This will persist even as you dismiss the Find/Replace popover.

What’s more, the search term and settings will automatically synchronize between all files you have open — all across your project, and even across multiple solutions. So as you switch files, or switch to a different document window, you will see your search term is highlighted everywhere. And, like just about all state in Fire, it will also persist across restart of the IDE.

The Find/Replace popover gives you the usual options to Find Next, Find Previous, and of course to replace either one or all occurrences of the search term with a new string.

After you dismiss the Find/Replace popover, these options continue be available via keyboard shortcuts and the Edit|Find menu. Cmd-G will jump to the next occurrence, and Shift-Cmd-G will jump to the previous, both allowing you to cycle round-and-round in the current file. Option-Cmd-G will replace the current/next occurrence of the search term, while Control-Option-Cmd-G will replace all in the entire file.

When replacing, you will notice that the editor also highlights each occurrence of the replace term as well, with a more subtle yellow. This highlighting allows you to easily keep track of what matches your search and what has been replaced already.

If you had enough of your search, you can clear the search term, and make the yellow highlights disappear with it, by pressing Control-Option-Cmd-F (or choosing Clear Search Term from the Edit|Find menu).

But that’s not all. One frequent task while navigating code is navigating between occurrences of the same token, so Fire has a shortcut for that as well. When the cursor is on a word/token, you can press Control-Option-Right or Control-Option-Left to quickly jump to the next (or previous) occurrence of that token. Fire will automatically make the token at the cursor the current search term (so you will see it highlighted all across the file). If not already turned on, Fire will also temporarily enable the “whole words only” option for this search to make sure you only find the exact token (if you want to jump from one use of ‘i‘ to the next, you don’t want to also hit the ‘i’ in ‘begin‘).

When you do a manual search later, the “whole words only” will automatically revert back to its original setting. You’ll find that the Control-Option-Right or Control-Option-Left navigation is something that, once you’re used to it, you can no longer live without

All in all, Fire’s Find and Replace support is well-rounded and — along with Fire’s other navigating mechanisms that I’ll dive into in another post — designed to make it really easy and intuitive to find your way around your code.

Avatar of Anton

by Anton

AES encryption envelope and Xamarin PCL

July 31, 2014 in .NET

Recently I’ve been asked a question about how the AES encryption envelope can be used with a PCL build of Data Abstract, the issue being that PCL doesn’t expose the needed cryptography API. Although I don’t known the reason for this, I am still going to provide a solution.

Before we dive into the technical details, I have to say that relying on AES message encryption alone is not the best option. Once someone steals your password, they will be able to intercept, read and modify any client-server traffic. So keeping passwords safe and not storing them in non-encrypted form is an absolute must. But you should still consider SSL to protect your communication channels.

Let’s go back to AES for now.

For most of the platforms supported by RemObjects SDK “natively”, the AESEncryptionEnvelope can be instantiated in the application and then this instance can be added to the .Envelopes collection of the Message instance created in the PCL communication library (this is the magic of PCL, yes). Unfortunately, there are two quite important platforms that are supported only by the PCL build of RemObjects SDK. So a solution is needed.

Assume we have a very simple PCL library that calls a RemObjects SDK server and that the server has AESEncryptionEnvelope enabled, so we have to enable it on the client side as well. The client is a Xamarin.iOS application (but the Xamarin.Android approach is exactly the same). Below, I’ll be talking about ‘native’ code, by which I mean code that directly references Xamarin libraries, opposed to code that references PCL.

So the solution is dead simple: In the ‘native’ code part, wrap Crypto API into a form that the PCL code part can understand and provide this wrapped instance to the RemObjects SDK message instance. Obviously, the best way to provide something is to wrap it into a form that RemObjects SDK understands. In our case, we’ll derive a class from the abstract class MessageEnvelope. For further reference I’ll provide the code entirely:

using System;
using System.ComponentModel;
using System.IO;
using System.Text;
using RemObjects.SDK.Helpers;
using System.Security.Cryptography;

namespace RemObjects.SDK
{
     public class AesEncryptionEnvelope : MessageEnvelope
     {
          #region Default values
          private const String CATEGORY_ENCRYPTION = "Encryption";
          private const String IV = "@1B2c3D4e5F6g7H8";

          private const Int32 BUFFER_SIZE = 65536;//64k
          private const Int32 BLOCK_SIZE = 128 / 8;
          #endregion

          #region Private fields
          private Byte[] fEncodedPassword;
          #endregion

          public AesEncryptionEnvelope()
               : base()
          {
          }

          public AesEncryptionEnvelope(String password)
               : this()
          {
               this.Password = password;
          }

          #region Properties
          public String Password
          {
               get
               {
                    return this.fPassword;
               }
               set
               {
                    this.fPassword = value;
                    this.EncodePassword();
               }
          }
          private String fPassword;

          public override String DefaultEnvelopeMarker
          {
               get
               {
                    return "AES";
               }
          }
          #endregion

          protected override MemoryStream InternalWrap(Stream source, Byte[] header)
          {
               // Size of the original stream
               Int64 lStreamLength = source.Length - source.Position;
               Byte[] lStreamSizeBuffer = BinHelpers.Int32ToBuffer((Int32)lStreamLength);

               // Create bytes array containing
               // [... original header ...][stream size]
               // This is cheaper than creating MemoryStream and then converting it to Byte[]
               Byte[] lHeader = new Byte[header.Length + 4];
               Array.Copy(header, lHeader, header.Length);
               Array.Copy(lStreamSizeBuffer, 0, lHeader, header.Length, 4);

               return this.InternalEncrypt(source, lHeader);
          }

          protected override MemoryStream InternalUnwrap(Stream source)
          {
               // Read size of the original stream
               Byte[] lBuffer = new Byte[BinHelpers.SIZE_INT32];
               Int32 lBytesRead = source.Read(lBuffer, 0, BinHelpers.SIZE_INT32);

               if (lBytesRead != BinHelpers.SIZE_INT32)
                    BinHelpers.UnexpectedEndOfStream();

               Int32 lStreamSize = BinHelpers.Int32FromBuffer(lBuffer);

               MemoryStream lDecryptedData = new MemoryStream();
               this.InternalDecrypt(source, lDecryptedData);

               if (lDecryptedData.Length < lStreamSize)
                    throw new Exception("Decryption error. Invalid length of the stream.");

               lDecryptedData.SetLength(lStreamSize);

               return lDecryptedData;
          }

          private void EncodePassword()
          {
               if (String.IsNullOrEmpty(this.Password))
               {
                    this.fEncodedPassword = null;
                    return;
               }

               this.fEncodedPassword = new Byte[32];

               Byte[] lPasswordBytes = Encoding.UTF8.GetBytes(this.Password);
               Array.Copy(new SHA1CryptoServiceProvider().ComputeHash(lPasswordBytes), this.fEncodedPassword, 20);
               Array.Copy(new MD5CryptoServiceProvider().ComputeHash(lPasswordBytes), 0, this.fEncodedPassword, 20, 12);
          }

          private CryptoStream GetCryptoStream(Stream baseStream, CryptoStreamMode mode)
          {
               if (this.fEncodedPassword == null)
                    throw new Exception("No password configured for AesEncryptionEnvelope.");

               RijndaelManaged lSymmetricKey = new RijndaelManaged();
               lSymmetricKey.Mode = CipherMode.CBC;
               lSymmetricKey.Padding = PaddingMode.None; // Do padding manually
               lSymmetricKey.Key = this.fEncodedPassword;
               lSymmetricKey.IV = Encoding.UTF8.GetBytes(IV);

               ICryptoTransform lTransform = (mode == CryptoStreamMode.Write) ? lSymmetricKey.CreateEncryptor() : lSymmetricKey.CreateDecryptor();

               return new CryptoStream(baseStream, lTransform, mode);
          }

          private MemoryStream InternalEncrypt(Stream source, Byte[] header)
          {
               MemoryStream lEncryptedData = new MemoryStream(header.Length + (Int32)AesEncryptionEnvelope.GetEstimatedStreamLength(source));
               lEncryptedData.Write(header, 0, header.Length);

               using (CryptoStream cryptoStream = this.GetCryptoStream(lEncryptedData, CryptoStreamMode.Write))
               {
                    StreamHelpers.CopyStreamToStream(source, cryptoStream);

                    // Add tail
                    Int32 lTailLength = ((Int32)(source.Length - lEncryptedData.Length)) + header.Length;
                    if (lTailLength != 0)
                    {
                         lTailLength = AesEncryptionEnvelope.BLOCK_SIZE - lTailLength;
                         Byte[] lTail = new Byte[lTailLength];
                         cryptoStream.Write(lTail, 0, lTailLength);
                    }

                    cryptoStream.FlushFinalBlock();

                    // The original lEncryptedData stream will be enclosed together with the CryptoStream instance
                    // Note that the used constructor doesn't actually copy the data, so memory consumption/performance
                    // is not an issue here
                    MemoryStream lResult = new MemoryStream(lEncryptedData.GetBuffer());

                    // Otherwise the tail contained in the buffer will break the AES decryption on the other side
                    lResult.SetLength(lEncryptedData.Length);

                    return lResult;
               }
          }

          private void InternalDecrypt(Stream source, Stream destination)
          {
               using (CryptoStream cryptoStream = this.GetCryptoStream(source, CryptoStreamMode.Read))
               {
                    StreamHelpers.SetStreamCapacity(destination, source, AesEncryptionEnvelope.GetEstimatedStreamLength(source));
                    StreamHelpers.CopyStreamToStream(cryptoStream, destination);
               }
          }

          private static Int32 GetEstimatedStreamLength(Stream source)
          {
               Int32 lSourceLength = 0;
               try
               {
                    lSourceLength = (Int32)(source.Length - source.Position);
               }
               catch (NotSupportedException)
               {
                    return -1; // Unknown
               }

               Int32 lResult = (lSourceLength / 16) * 16;
               if (lResult < lSourceLength)
                    lResult += 16;

               return lResult;
          }
     }
}

(You'll have to reference the RemObjects SDK assemblies to get this code compiled.)

Then provide an instance of this AesEncryptionEnvelope class to the code part where the communication components are instantiated and add it there to the Envelopes collection:

message.Envelopes.Add(envelopeInstance, true);

And that's it. AES encryption is enabled.

I also want to mention that while theoretically it is possible to implement AES encryption/decryption completely in managed PCL code, there are reasons NOT to do this. Re-implementing part of the base class library leads to code bloating. What's more important is that cryptography APIs implemented by Xamarin platforms might utilize low-level platform methods for better performance and security – something that a PCL managed code-only implementation won't be able to provide by definition.

PS.: The above-mentioned approach can be extended. More powerful (and resources-consuming) cryptography algorithms can be used instead of AES, like asymmetric encryption. Custom envelopes based on them can be used in RemObjects SDK-powered applications – all you need to do is to properly override the abstract methods of the MessageEnvelope class.

Avatar of marc

by marc

Two Major Announcements Today, here at RemObjects

July 24, 2014 in "Silver", Cooper, Echoes, Elements, Fire, Nougat, Oxygene, RemObjects, RemObjects C#

Today is a day I’ve been looking forward to for a while. Why? Because today we officially announced two major projects that I am really excited about, and one of them is a project I have been working on for a long time that — as of today — is in the hands of thousands of Elements developers.

So First, Fire.

I cannot overstate how excited I am about Fire. I started working on this project almost two years ago, as a side/weekend project. It evolved slowly at first, and then began picking up speed and came to the point where — much sooner than I had expected — it had become usable. Late last fall, Fire was promoted to be an “official company project”, this spring, it went out to less than a handful of very dedicated external testers. And today, while still considered Beta, it’s being made available to every Oxygene and RemObjects C# user as part of their active subscription.

What is Fire? I am glad you asked.

Fire is a Mac native app, and it’s a place to go to cook up great apps. If you want to use less fancy terms, you could also say that Fire is a new IDE for Oxygene and RemObjects C# that runs on Mac OS X.

My reasons for starting work on Fire where two-fold.

One, I’ve been a Mac user for a long time now (since 2007), but I’m always keeping a Windows VM around to do what? To run Visual Studio. I really wanted to break out of that and develop in Oxygene (and more recently RemObjects C#) directly on my Macs. On my laptop, a VM is way too much overhead, so I never bothered installing one; but even on the desktop, it’s annoying to always have your IDE in a “box”.

Two, while I (kinda) like Visual Studio and love Xcode, I’ve had my own ideas about what would make an IDE great, and I wanted to put those in practice. For version 1.0 those mainly revolve around lightweightness and the IDE not getting in my way. Beyond 1.0, I (and all of us) have more radical ideas.

Fire is the fulfillment of both of those dreams. Since early this year, I have been using it exclusively for all my Elements developing tasks and — if you’re a Mac user — I hope you will be as well, starting today.

You can read more about Fire at remobjects.com/fire, and I’ll also be talking about it more, and going into features in more detail, in future blog posts.

Second, Silver

But just one announcement would be boring, right? That’s why we have two. Today, we also took the wraps off another project we have been cooking up — this one not quite so long, but for about a month and a half.

As you probably know, last month at WWDC, Apple announced Swift, their new programming language for Mac and iOS. We started digging into Swift immediately, and really liked what we saw. So much in fact that we thought about what would be involved in bringing Swift into the Elements language family as a third member. And we didn’t just think about it, we put Carlo to work on it immediately as well.

So today we’re pre-announcing “Silver”, which is our project to do just that. “Silver” will bring the Swift language to Android/Java and .NET developers (and it will work on Cocoa too, for completeness sake). In essence, any place where you can use Oxygene or RemObjects C# now, you’ll be able to use Swift as well. And it will of course work in both Visual Studio and Fire.

While “Silver” is already working pretty great internally, we don’t have a public preview quite yet — but we will soon. You can leave your email with us on the “Silver” home page (below), and we’ll keep you in the loop.

You can find more info on “Silver” and sign up at remobjects.com/silver.

Exciting times are ahead. Let us know what you think!

Avatar 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!

Avatar 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!

Avatar of marc

by marc

Announcing the Elements “June 2014″ Update

June 19, 2014 in Elements, RemObjects C#

We are pleased to announce the new “June 2014” update to Oxygene and RemObjects C#.

“June 2014” is a small interim update for our Elements compiler that focuses mainly on improvements and bug fixes, but nonetheless brings — alongside over one hundred fixes — a handful of very significant new features and enhancements:

  • We’ve made major improvements to the WinRT and Windows Phone tool chains that will help you build apps for Microsoft’s modern app platforms. This includes support for new toolchain changes that come in Visual Studio 2013 Update 2 (which is a rather significant new release of VS, despite the incremental sounding name).

  • We’ve improved the Cocoa toolchain in significant ways, such as the ability for Elements to automatically pick your default Profile and Certificate when opening and building new iOS projects, and an improved UI that handles the case where you updated Xcode and need newer versions of the iOS or OS X SDKs — including the option to automatically download support for new SDKs, where available.

  • The new release has also been tested with the iOS 8.0 and OS X 10.10 Yosemite beta SDKs to make sure you’ll be able to import these SDKs and start working with the new features right away. (Unfortunately, we cannot ship pre-imported .fx files for these SDKs until they are out of beta and not under NDA anymore).

  • Cross Platform Compatibility Warnings have been improved for this release, with new warnings added and improved handling of these warnings inside conditionally compiled code, irrelevant warnings will, for example, now be suppressed in parts of the code that is clearly intended for a single platform based on $IFDEFs.

  • The code editor smarts have been improved, with automatic parenthesis and bracket completion, making it yet a bit more quicker to type your code on a day-by-day basis.

  • Finally, the June release of Elements integrates with our new Help Viewer app (currently available as separate download from the beta portal) to show you context sensitive help at the press of a button — not just from our Elements Wiki but also from the core platform docs off all our supported platforms — including the .NET Framework, the OS X and iOS SDKs, as well as the Java and Android SDKs.

And as always, this lists just the tip of the iceberg. Check out our full change log for details and more changes.

Also as always, the new release is a free update to all customers with an active subscription. If your subscription has lapsed, you can renew for $499 (single language) or $699 (to renew to both Oxygene and RemObjects C#).

New user licenses are available at $699 for both Oxygene or RemObjects C#, or $999 for both.

Happy Coding!