You are browsing the archive for Jim McKeeth.

Top 10 Reasons to use Platform Native APIs

March 14, 2013 in .NET, Cocoa, Cooper, non-tech, Nougat, Oxygene, Prism

What are native platform APIs? They are the APIs provided by the platform vendor that define the platform. On Android this is the Android SDK. On iOS it is the Cocoa Touch Frameworks. On Windows and Windows Phone it is WinRT and the .NET Framework. There are undocumented APIs, and even calls that circumvent the platform APIs, but they are not considered part of the platform API.

In addition to the native development tool provided by the platform vendor, there are 3rd party development tools providers (such as ourselves) with their own solutions. The 3rd party tools typically either focus on providing a better solution for the specific platform, or sacrifice native platform support with the objective of cross-platform simplicity. There is no reason to sacrifice platform support, as you will see in these top 10 reasons to program to platform native APIs.

Platform Native APIs are Great

Those who programmed MS-DOS applications or the early Windows API no doubt remember what a pain those APIs (or lack of) were to work with. Back then it was great to have a good abstraction to make the platform easier to work with. Today’s platform native APIs encompass all the productivity enhancements that are found in the the best abstractions. Typically, the productivity enhancements that come from additional abstractions are only in the form of familiarity and developer’s resistance to learning a new API and framework. You know things are getting carried away when there is a Java abstraction for developing Windows Phone 8 applications and a .NET abstraction for building Android applications.

The Law of Leaky Abstractions

All non-trivial abstractions, to some degree, are leaky.” If your tool forces you to use some non-trivial abstraction on top of a platform’s API, at some point it will leak – there will be something that the abstraction cannot do, or somewhere the abstraction behaves differently from platform to platform. If you are serious about developing for any platform, you need to understand the platform’s native API. The more non-trivial the abstraction, the less of the platform it can abstract successfully and the more likely you will need to move to the platform native API. If you are going to need to learn the platform API anyway, you might as well start there. No need to learn both the abstraction and the platform API – that is twice as much work.

Native Documentation

Documentation is a lot of work. Good documentation is even more work. On each platform, the platform vendor provides the documentation of the platform along with all the best practices and examples. For each additional level of abstraction that requires another level of documentation to consult. Chances are that the documentation will eventually refer you to the platform API documentation. Wouldn’t it be nice to just start at the ultimate authority and not have to wade through incomplete and outdated layers of documentation?

No Bloatware

If your abstraction adds additional graphic libraries or run-times, your application suffers with bloat. These abstractions replace the functionality already present in the platfrom and make your app bigger, slower to start-up and less responsive at runtime. Some of these add-ons are worthwhile, but if you need to double (or more) the size of your app just to write “hello world”, then you are probably using the wrong solution.

Rapid Release Cycle

When a platform vendor releases a new API you want to be able to take advantage of those features right away. It may surface new hardware features, or just introduce better ways of doing things. If you are forced to use an abstraction, you need to wait for the 3rd party to update their abstraction. This may be fairly quick, or you may have to wait for their release cycle, which, depending on where they are in development, could mean the release after the next. No matter how fast a vendor has been in the past at updating their abstraction library, a point will come where they are not updated when you need them.

Support for Platform Deviations

If a hardware vendor comes out with their own SDK extensions or variations on a platform, they will provide their support at the level of the platform API. If you are stuck behind an abstraction, you will not have access. The openness of Android is a great example with extensions like Google TV, Epsion Moverio, Ouya, and Google Glass. If you are interested in cutting edge platforms like these, you need a development tool that doesn’t lock you behind an abstraction.

Native User Experience

Each platform has a typical user experience. This comes from the native platform user interface widgets and the way they behave. It also comes from design guidelines provided in the platform documentation. If you are using an abstraction for your user interface, even one that tries to look and act like the native one, it will get in the way of this native user experience. When it comes to user experience, close isn’t close enough. Using the native platform user interface controls is the only way to give your users the experience they expect.

Less Points of Failure

Everything always works great in the demonstrations, but the more layers of interoperability and wrappers required to make your application run, the more points of failure. When you develop for the platform API directly, you are not handicapping yourself with black boxes or other points of failure for your app. The first time you find yourself debugging into that abstraction layer, you will really wonder if it was worthwhile to shackle yourself with it.

Maximum Developer Flexibility

Platform APIs are huge. In the process of creating a wrapper, choices are made to simplify or eliminate options. These simplifications and eliminations result in less flexibility for the developer. Tying a project to a subset of the features of the platform reduces what you can do with your project. Don’t tie your hands!

3rd Party Support

The majority of 3rd party components and books are going to support the platform’s API. The further you are from that, the less support you are going to have. Want to use a cool 3rd party custom control? Hope they port it to your favorite framework. And what are the odds of a book about the specific features of the platform you want to explore covering it via your specific pair of shackles?

Summary

Cross-platform abstractions are only going to get in your way and tie your hands. Any benefit in getting you up to speed faster will be lost in the long term when you hit the rough edges of the abstraction. That is the reason Oxygene is designed to use the platform native APIs directly. There is no forced or complex abstraction to get in your way of using the platform and making the best app possible.

Where Does Business Logic Belong?

February 25, 2013 in Data Abstract

The question of where business logic belongs is as old as database application development. Early on, with primitive client server development, the business logic existed in the client and the database existed only to persist the data.

Client Server

The advantage of this approach is that it makes the client responsive for input validation, and simplifies the degree of coupling between the client and server. The disadvantage is that if a different client connects to the database, the business logic is no longer enforced. This compromises the integrity of the database. There are other disadvantages to client server development – to learn more, read the white paper on “Why Multi-Tier”.

With the introduction of Multi-Tier database application development, the business logic moved to a Middle-Tier.

MultiTier

This has the immediate advantage of keeping the database secure no mater which client connects, while also simplifying client development. The disadvantage is that the client has to make a round trip to the server to validate user input – a major hit in the user experience department.

What I’ve seen some developers do is duplicate the input validation business logic from the middle-tier into the client. This speeds up input validation, but increases the complexity of client development, and requires that any business logic updates be made in two places – duplication of code is rarely the right answer.

Thankfully Data Abstract has a solution for this thanks to the new Business Rule Scripting support. Not only does it allow you to easily define your server side business logic in JavaScript, but also, select scripts are shared from the server to the client for fast and convenient validation and the best possible user experience.

Data Abstract Business Rules Scripting

This has the advantage of running the validation logic twice – once on the client for fast response, and then again on the middle-tier to protect the database. This is the best of both worlds – you keep your database secure and your client application responsive with no duplication of effort or code to keep synchronized. Data Abstract takes care of all that for you.

Additionally, Data Abstract’s schema technology keeps the client completely decoupled from the database. This keeps the database easier to maintain, and allows your application to easily migrate to a new database when your project requires it.

Both schemas and business rules scripting are supported in all editions of Data Abstract: .NET, Java, Delphi, Xcode and JavaScript. Learn more about Business Rules Scripting on RemObjects TV.

Working with Briefcases

February 12, 2013 in Data Abstract

bagageOne very useful feature of Data Abstract is Briefcase support. The Data Abstract briefcase provides local persistent storage. Simply store the data in a local briefcase file on the client file system, and the data can be reloaded without needing to request it again from the server.

Some common use cases:

  • Use briefcase for saving client data including uncommitted changes between restarts of your application.
  • Store some quite constant dictionary tables into briefcase and load them during application start and thus avoid having to reload the same data from the server.
  • Request only the changed records for some huge table from the server side and then merge the delta with the client table loaded from the local briefcase.
  • Use briefcases if you don’t have a persistent connection to your server and the user needs to be able to work in offline mode. Use Data Abstract’s robust conflict resolution to post the changes later.

In addition, a set of custom, application-specific string properties can be stored alongside the data. This can be useful, for example, for storing the version number of the data format to ensure newer versions of your application can reload the data correctly, if data formats change over time. (It is not recommended though to use this space for general application settings that are not directly related to the data.)

The main advantage of using a briefcase instead of some embedded database (f.e. SQLite.NET) to cache user data or to implement offline mode is that a briefcase stores not only user data but also its state (i.e. deleted, updated or inserted data rows). This greatly simplifies further synchronization with a Data Abstract-based server.

You can learn more about working with offline briefcases:

And more in the official RemObjects Documentation Wiki.

Oxygene for Android Torch App

January 26, 2013 in Android, Cooper, Java, Oxygene

Brian Long made a great video on building an Android Torch App using Oxygene for Android. You can find it as part of RemObjects TV. The app he builds is a nice simple app, which makes the video easy to follow while also covering some concerns you may face in more complicated apps:

  • Permissions
  • Adding a new Activity
  • Using an Intent to move between activities
  • Creating a full screen Activity
  • Adding a Menu
  • Displaying Toast
  • Displaying a Dialog to get a user response

If you are new to Android Development with Oxygene, or maybe haven’t gotten into some of these topics yet then check out the video. You can also download the full source code for the app. Let us know what other Android related topics you would like to seen covered in future videos!

Oxygene Gets Big(Integers)

January 18, 2013 in .NET, Oxygene, Prism

A huge part of cryptography is big numbers. Really big numbers. For example, the SHA-256 cryptographic hash produces a 256-bit thumbprint of any data you give it. Exactly how big is 256-bits?

  • 8 bits = 256
  • 16 bits = 65536
  • 32 bits = 4294967296
  • 64 bits = 1.84467E+19
  • 128 bits = 3.40282E+38
  • 256 bits = 1.15792E+77

So the maximum value for a 256-bit unsigned integer is:

115 792 089 237 316 195 423 570 985 008 687 907 853 269 984 665 640 564 039 457 584 007 913 129 639 936

Unfortunately most programming languages only have 32-bit or at most 64-bit numbers available. So in order to store large numbers like these they require you to make the awkward move to byte arrays or some other complex construct. That isn’t the case with Oxygene.

Oxygene has the BigInteger datatype. BigInteger is an arbitrary length signed integer, so it can be as big as you have memory for, and it can be used like a normal integer.

To include BigInteger support you just need to add a reference to the System.Numerics.dll assembly (part of the .NET 4.0 Framework), add System.Numerics to your uses clause, and you are good to go. Now you can use BigIntegers just like any other data type.

Behind the scenes, BigInteger is actually an object with methods, properties, constructors and operators to make it easier to work with BigIntegers. So instead of using Math.Abs use BigInteger.Abs.

You are probably wondering “What does all of this have to do with cryptography?”. I’m glad you asked. Here is a method to calculate a SHA-256 on a string and return the value as a BigInteger

class method Hash.Sha256(text: String): BigInteger;
begin
  using hash256: SHA256Managed := new SHA256Managed() do begin
    var bytes := Encoding.UTF8.GetBytes(text);
    var hash := hash256.ComputeHash(bytes);
    exit new BigInteger(hash);
  end;
end;

The ComputeHash method on the SHA256Managed object returns a byte array containing the value of the hash. Luckily there is an optional constructor for BigInteger that takes a byte array as a parameter. This creates a BigInteger from the value of the byte array.

Another great place to use BigIntegers is with the cryptographic random number generator. Unlike the random number generator you are used to, the one provided by the RNGCryptoServiceProvider is cryptographically secure – meaning future values cannot be predicted. The RNGCryptoServiceProvider will generate a sequence of bytes of any size, which makes BigIntegers another great fit.

About creating a BigInteger from a byte array: Since a BigInteger is signed, this is just about as likely to result in a negative as a positive number. If you always want a positive number, you can append a zero byte to the end of the byte array, we will do that for our random number routine.

This method will return a BigInteger of the number of bytes specified.

class method Rnd.BigRnd(bytes: Cardinal): BigInteger;
begin
  using rng := new RNGCryptoServiceProvider do begin
    var tokens := new Byte[bytes + 1]; // one extra byte for the sign
    rng.GetBytes(tokens);
    tokens[bytes] := 0; // keep the result positive
    result := new BigInteger(tokens);
  end;
end;

Take a look at the code and see what sort of uses you can find for really big integers. BigInteger support was introduced a while ago for Oxygene for .NET – yet another feature you probably didn’t know you had.

Cryptography with Oxygene

January 14, 2013 in .NET, Oxygene

One of my favorite development topics is Cryptography, and my favorite language is Oxygene. The Oxygene language has some great features that are well suited to advanced programming tasks like cryptography.

For example, it makes it very easy to work with the AesManaged class in the .NET Framework. When you construct an instance of the AesManaged class, it initializes both the Key and the initialization vector (IV) with new random values. Tuples are a great option for returning both of these values from a single method.

class method OxygeneCrypto1.GenerateKeys: tuple of (AESBlock, AESKey);
begin
  using aes := AesFactory do
    exit(aes.IV, aes.Key);
end;

When calling this method, you just use the syntax (IV, Key) := GenerateKeys; and the two local variables receive the values from the Tuple. This is much better than using out functions or creating a custom object just to hold the two values.

Oxygene’s awesomeness doesn’t stop there. Here is a method to encrypt a string with AES and the provided key. It first compresses the string – this strengthens the encryption and reduces the size of the ciphertext. Input parameters are validated with require statements, and ensure statements are used to verify it worked correctly. Nested using statements manage the life-cycle of all the handles. The result is much more concise code that is clearer and easier to maintain than the alternative in other languages.

class method OxygeneCrypto1.encrypt(plainText: String; Key: AESKey; IV: AESBlock): array of Byte;
require
  assigned(plainText) : 'The method encrypt requires the plainText parameter to be defined.';
  plainText.Length > 0 : 'The method encrypt requires the plainText parameter to be defined.';
  assigned(Key) : 'The method encrypt requires the Key parameter to be defined.';
  assigned(IV) : 'The method encrypt requires the IV parameter to be defined.';
  Key.Length = AESKeyLength : 'Invalid Key Length when calling encrypt.';
  IV.Length = AESBlockLength : 'Invalid IV Length when calling encrypt.';
begin
  using aesAlg := AesFactory(Key, IV) do
  using encryptor: ICryptoTransform := aesAlg.CreateEncryptor(aesAlg.Key, aesAlg.IV) do
  using output := new MemoryStream() do
  using encStrm := new CryptoStream(output, encryptor, CryptoStreamMode.Write) do
  using gzip := new DeflateStream(encStrm, CompressionLevel.Fastest) do
  using writer := new StreamWriter(gzip) do begin
    writer.Write(plainText);
 
    // Close writer to prepare the output
    writer.Close();
 
    exit output.ToArray();
  end; 
ensure
  assigned(result) : 'Undefined result from encrypt.';
  result.Length > 0 : 'Undefined result from encrypt.';
end;

The decryption method is just as clear and concise. Take a look at the example download to see how it all fits together.

I hope to make this a series of posts on different cryptography solutions with the different platforms each flavor of the Oxygene language supports. So let me know if you find Cryptography as interesting as I do. There are so many other topics to cover, too!

Oxygene on the Big Screen

January 4, 2013 in Android, iOS, Java, Mac, Metro, Oxygene, Windows, Windows Phone

Android powered Ouya ConsoleYou already know Oxygene is the best choice for mobile development – Oxygene for Java on Android, Oxygene for .NET for Windows Phone and the Windows RT Surface and the beta “Nougat” already providing great support for iOS development. But what if you want to develop on the big screen? Like that 50 plus inch TV in your front room?

Enter the Ouya, the Android powered game console for your TV. They just released their ODK (Ouya Development Kit), and since it is Android powered, it is perfectly supported by Oxygene for Java right out of the box. Oxygene for Java is a completely native Android development tool – there are no forced abstraction layers or additional run-times to get in your way or require updating when new variations or versions of the platform come out.

Red Ant Games has just announced they are using Oxygene for Java to move their Subject 33 to Ouya and Android mobile devices. Subject 33 is currently an Alpha prototype on Windows. They also have plans to support iOS and Mac with “Nougat”.

Oxygene Goes to School

December 13, 2012 in Android, Cooper, Java, Linux, Oxygene, Uncategorized

Dr. Norman Morrison recently published a wonderful series of Oxygene for Java tutorials on his “Pascal Programming for Schools” site, including some on Android development. He reports that students in his school are already using Oxygene for Java for their educational projects and are very excited about building Android applications as well.

Oxygene is great to use in educational settings. It holds true to the design paradigms of Object Pascal, which make it easily readable and discoverable. It doesn’t stop there though, but extends the language with great new language features frequently found in academic languages, like Tuples, Duck Typing and Aspect Oriented programming. The fact that it supports all common platforms of today is a real plus too.

Dr. Morrison also reports using Oxygene for Java to develop for his ARM-based Raspberry Pi, and includes some examples, too.

Adding Oxygene for Java to their curriculum has really energized both the department and the students while expanding their program!

Windows Store Development with Oxygene

November 1, 2012 in .NET, Metro, Oxygene, Prism, Windows

When Microsoft released the Visual Studio 2012 Shell, support for building Windows Store apps (formerly known as Metro apps) was missing. This certainly frustrates Windows Store Development with Oxygene which ships with the Shell.

Fortunately I’ve found a work-around to this annoying omission. Simply install Visual Studio 2012 Express for Windows 8 (free download) and then install (or re-install) Oxygene for .NET. This activates the support for WinRT templates and the Modern UI designers in the Shell. After that you can use the WinRT and Modern UI designers in the Shell with Oxygene for .NET.

The Visual Studio Shell and the Express Editions share many resources. As long as the Express Edition is installed, the Visual Studio Shell has WinRT and Modern UI support available for use in Oxygene for .NET development. The Express edition does not support Oxygene, so you will need to continue using the Shell.

Update: It was reported that it may be necessary to uninstall the Shell if you have trouble installing the Express Edition. So if you run into trouble you might try that.

What is Gendarme?

October 11, 2012 in .NET, Mono, Oxygene

New in Oxygene 5.2 is Gendarme Code Analysis, which is a deeply integrated, extensible rule-based system to find concerns in .NET (and Mono) applications and libraries. The name comes from the Mono Project’s Gendarme which it is based on. It is modified to integrate nicely with the Oxygene Language and Visual Studio IDE, providing improved and customized rules that make sense to Oxygene developers.

Why Use Gendarme?

One of our goals with Oxygene is to help you write better code. Gendarme helps you detect “concerns” which may represent potential bugs or just code that is less maintainable. For example, concerns include code duplication, potentially undisposed resources, bad practices, or inconsistent naming, to name just a few. Gendarme is also extensible, allowing you to create rules specific to your project or team. All of these concerns are reported during the build process through our “Inline Error” system. This helps you correct the concerns sooner, before they propagate through your project.

How to Use Gendarme?

Gendarme can be enabled or disabled on a per project basis. To enable Gendarme Code Analysis for your project, simply go to Project Properties.

Solution Explorer - Project Properties (Alt+Enter)

Once you are in Project Properties, scroll down to the bottom of the Build options. There is a default ruleset that is provided with Oxygene, but you can also define your own.

Gendarme build options

The default ruleset is an XML file that is installed at "C:\Program Files (x86)\RemObjects Software\Oxygene\bin\Gendarme\rules.xml" by default. Take a look at the ruleset and you will find it is pretty self-explanatory.

The Minimum Severity option allows you to filter defects below the specified severity level: audit, low, medium, high or critical. The Minimum Confidence option prevents false positives by filtering defects below the specified confidence level: low, normal, high or total. You also have the option of specifying custom config and ignore files.

Also in the "C:\Program Files (x86)\RemObjects Software\Oxygene\bin\Gendarme" folder is the command line version of Gendarme. This is a customized version of the one available directly from the Mono Project.

Once enabled, you will see blue “Inline Error” indicators during builds that mark one or more concerns. Clicking on a line provides the Fix-It Panel, where you can ignore an individual concern or all occurrences of the concern for the entire project.

Gendarme concerns in code

Selecting either of the Ignore options will add an entry to the CodeAnalysis.ignore file (which gets created if it didn’t already exist) in the Properties folder of your project. This file will be referenced from the project properties page under Ignore File. The format is simple enough; each entry is two lines. The first line is the rule and the second line specifies when to ignore it.

Gendarme Rules

Gendarme returns defects in different categories. Each of the categories are defined in a different rule assembly. The following rule assemblies are used in Gendarme for Oxygene:

  • BadPractice
  • Concurrency
  • Correctness
  • Design (+Generic & LINQ)
  • Exceptions
  • Globalization
  • Interoperability (+COM)
  • Maintainability
  • Naming
  • Performance
  • Portability
  • Security (+CAS)
  • Serialization
  • Smells
  • User Interface (UI)

Here are a few rule examples to show you what Gendarme can do for you right away. There are a lot more in store for you though. (You can read about the full set and see some examples in the Gendarme documentation.)

Gendarme.Rules.BadPractice

These rules check for bad practices that can result in code not behaving the way you expect it to. Frequently these problems will hide bugs, or introduce bugs later on.

CheckNewExceptionWithoutThrowingRule

This rule checks for exception objects which are created but not raised, not returned, and not passed to another method as an argument. This quite often obscures a bug that is easily missed unless you specifically test for the exception.

Bad example:

method MissingRaise(arg: Object);
begin
  if not assigned(arg) then begin
    new ArgumentNullException('arg')
  end;
  DoWork(arg)
end;

Good example:

method WithRaise(arg: Object);
begin
  if not assigned(arg) then begin
    raise new ArgumentNullException('arg')
  end;
  DoWork(arg);
end;

DoNotUseGetInterfaceToCheckAssignabilityRule

This rule checks for calls to Type.GetInterface that look like they query if a type is supported, i.e. the result is only used to compare against nil. The problem is that only assembly qualified names uniquely identify a type, so if you just use the interface name or even just the name and namespace, you may get unexpected results.

Bad example:

if sometype.GetInterface('IConvertible') <> nil then begin
  // then the type can be assigned to IConvertible
  // but what if there is another IConvertible in there ?!?
end;

Good example:

if typeOf(IConvertible).IsAssignableFrom(sometype) then begin
  // then the type can be assigned to IConvertible
  // without a doubt!
end;

EqualsShouldHandleNullArgRule

This rule ensures that Equals(object) methods return false when the object parameter is nil.

Bad example:

method SomeClass.Equals(obj: Object): Boolean;
begin
  // this would throw a NullReferenceException instead of returning false
  exit ToString().Equals(obj.ToString())
end;

Good example:

method SomeClass.Equals(obj: Object): Boolean;
begin
  if not assigned(obj) then begin
    exit false
  end;
  exit ToString().Equals(obj.ToString())
end;

Gendarme.Rules.Performance

These rules report concerns on code that can be improved for better performance.

AvoidRepetitiveCastsRule

This rule fires if multiple casts are done on the same value, for the same type. Casts are expensive, so reducing them by changing the logic or caching the result can help performance.

Bad example:

for each o: Object in list do begin
  // first cast (is)
  if o is ICollection then begin
  // second cast (as) if item implements ICollection
    Process(ICollection(o));
  end;
end;

Good example:

for each o: Object in list do begin
  // a single cast (as) per item
  var c: ICollection := (ICollection(o));
  if c <> nil then begin
    Process(c);
  end;
end;

Gendarme.Rules.Design

These are rules related to design principles.

AvoidVisibleFieldsRule

This rule fires if a type contains externally visible fields. It is safer to use a property instead which allows you to change the implementation without breaking binary compatibility with other assemblies.

Bad example:

  Foo = public class
  public
    var Value: Integer;
  end;

Good example:

  Foo = public class
  public
    property Value: Integer;
  end;

When to use Gendarme?

You can, and should, start using Gendarme on your existing Oxygene for .NET projects right away. You may be surprised at the concerns that exist even in shipping projects, and they may even help you discover and fix problem bugs. To keep the number of reported concerns to a manageable level, turn Gendarme on early in the development cycle, before the concerns propagate too far through your project. So be sure to download the latest Oxygene and put Gendarme code analysis to use today!