What is more native on the latest 64-bit processor: 32-bit x86 code or intermediate code just-in-time compiled to take advantage of the 64-bit architecture and latest SSE instruction set? Not so simple, is it?

Managed code platforms such as Java and .NET have a “native” advantage that no unmanaged (so called “native code”) compilers can match. Because managed platforms distribute their programs in an intermediate format (Intermediate Language [IL] Assemblies for .NET and Byte-code for Java) the Just-In-Time (JIT) compiler is able to compile the program to specifically target the CPU it is running on. This means the program can scale up or down as necessary on each CPU, even a CPU that wasn’t released when you wrote the code.

A misconception is that managed applications are slower than unmanaged applications, or that managed applications are interpreted at runtime. A managed application is JIT compiled into highly optimized machine code immediately on execution.

The alternative for non-managed compilers is to compile to multiple targets and then provide software emulation for CPU instruction sets on older CPUs. The result is a more bloated program that contains emulation code that is rarely used, or a program that is unable to take advantage of the latest CPU optimizations.

Now that managed is the new native, it leaves developers free to focus on what is really important: A Native User Experience.

May 2012 Android Platform Version Distribution

While Ice Cream Sandwich (Android 4 / API 15) is all the rage, it is only installed on around 5% of the devices. Gingerbread (Android 2.3 / API 10) is the current front running with over 60% of the devices. It took over from Froyo (Android 2.2 / API 8) just last year. If you target Froyo or greater, you have the potential to reach a whooping 93.5% of the 300+ million Android devices. A whole lot better than the 5% that Ice Cream Sandwich gives you.

That is why RemObjects SDK for Java and Oxygene for Java support Froyo and newer – to give you access to the greatest possible number of Android devices. This level of support and compatibility is the result of our commitment to provide a native developer experience on each platform we support.

And thanks to the Support Package compatibility libraries your app can take advantage of a lot of the latest Ice Cream Sandwich features even when running on a Froyo or Gingerbread device. That way you can have your dessert and eat it too!

we are delighted to announce the immediate availability of RemObjects SDK for Java, the fourth platform edition of our award-winning remoting framework.

This release roughly marks the 10th anniversary of our initial RemObjects SDK for Delphi back in 2002. At lot has happened in said 10 years; the industry and the computing infrastructure has changed a lot and RemObjects SDK has evolved a lot as well. And we are happy that with the new release of RO/J we now have you covered with native RemObjects SDK client connectivity on just about any computing and development platform out there — including the three big mobile platforms.

Many of you have pre-ordered RemObjects SDK for Java and already had a chance to use the product during its beta cycle. As of today, the first official bits for RemObjects SDK are available to customers, and a free 30-day trial version is also available for download from our website.

What Does RemObjects SDK for Java Bring to the Table?

Just like its sister products, RemObjects SDK for Java is a fresh and completely platform-native reimplementation of our remoting infrastructure, this time for the Java and Dalvik platforms.

RO/J consists of 100% pure Java Runtime code with no external dependencies, and it will run on any system where Java 1.6 or higher or Android Dalvik API level 8 or higher is available.

RO/J has been designed from the ground up to fit well into the Java platform and its API paradigms, and it can be used from a variety of Java development environments, including Eclipse, NetBeans, IntelliJ IDEA — as well as, of course, our own Oxygene for Java in the Visual Studio IDE.

At the same time, RO/J is built on the same architectural principles that you have come to know and love from its sister products — remote services, messages, channels, envelopes and the like — as an existing RO user you will feel right at home.

Why use RemObjects SDK for Java?

The most exciting platform for RO/J, right now, is certainly Android. As one of the three major mobile computing platforms today, the Android operating system is largely based around a variant of the Java runtime called Dalvik. Serious, native Android development is done using Java or Java-Runtime-based languages (such as Oxygene), and with RO/J you now have the ability to leverage your remote services from your Android based applications.

But of course RO/J is also applicable in many other scenarios involving the “traditional” Java runtime: from cross-platform Java-based desktop applications over Applets or use in JavaServer Pages to Java on embedded devices — everywhere you can run Java and have a network connection, you can now communicate with your RO servers.

Find Out More

To find out more about RemObjects SDK for Java, visit the product home page at remobjects.com/ro/java, or watch our introduction videos at RemObjects TV. Or grab your free trial version today, at remobjects.com/trials.

If you are ready to take the plunge, RO/J is available in our secure online store for $399 for new users, and of course it’s available in bundles and as part of our “up-renewal” offer, where you can renew any existing RemObjects SDK subscription and just include the new Java edition in your renewal.

Also, Data Abstract for Java

If you want to go beyond remoting, we also have the Java edition of our Data Abstract database framework coming up. DA/J is currently in early-but-usable beta and available for pre-order. (Pre-orders of course include immediate access to the shipping RemObjects SDK for Java, as well as full beta access).

As you can probably tell, we are very excited about our new Java-based product line, and we hope you are too. Especially on the Android front, Java development is only going to become more relevant in the next few years, and with RemObjects SDK, Data Abstract and our Oxygene for Java, we have you covered on all fronts to create great native Android apps — and much more.

Yours,
marc hoffman
Chief Architect

But let me start with some background.

Here at RemObjects Software, we use a sophisticated (but home grown) continuous integration system spread across several build servers to do automated builds and tests of our products. The build cycle for most of our products is intricate and lengthy, so of course it has to be automated: our “rofx-win” (more on what that one encompasses below) repository alone creates 16 different installers that we deploy, involving dozens of binaries that need to be built and countless additional tasks that need to be performed.

Until recently, we have mostly been using a commercial build automation tool that has served us well for the past almost 10 years, but we started running into its limitations — limitations not by any fault of the tool itself, but limitations imposed by the complexities of our builds.

Some of the problems included:

• It supported builds for Windows only, meaning for out Mac-based products, we had to use a different solution.*

• It provided a great IDE for creating build scripts, but that was also Windows only; i’m responsible for a lot of the build script maintenance here myself (because i’m the kind of anal type you need to be to keep these things clean and tidy ;), and i’m glad for any chance to avoid booting my Windows VM.

• But most importantly, it used a very verbose XML file format where every little adjustment to one part of the script caused thousands of small and inconsequential changes to the XML — changes that made merging a living hell (and we branch like crazy, here). It’s an eye-opening experience when after doing a cumbersome manual merge in Araxis, you get an error telling you that you overlooked a change in line 87,000. Yes, that’s line eight-seven-thousand. Not good.

So, Train

So we set out to create our build script engine to replace this tool, with the following goals in mind:

• We didn’t want to completely reinvent the wheel.

• It had to run on Windows and Mac OS X (and potentially elsewhere, such as Linux, though we don’t run it on that, ourselves).

• Build scripts had to be clean and easy to branch/merge.

• And, ideally, build scrips should be easily maintainable as plain text.

The result of these goals, lots of extensive spec’ing, and even more coding — mostly by Carlo — is Train, our new open source build script engine.

Train is based on JavaScript, and implemented using Oxygene and our already open-source RemObjects Script JavaScript engine. Simply put, Train is a tool that lets you take a JavaScript source file and run it. But Train is so much more: In addition to letting you use the full flexibility of JavaScript in our build script, Train adds:

• An extensive base API for common build tasks, from handling files operations over working with .ini or .xml files to building MSBuild, Delphi or Xcode projects. That API is of course expandable, both using .NET modules or directly in JavaScript.

• Sophisticated handling of variables, including access to environment variables and parameters passed to the build script, and in-string variable resolution.

• Flexible support for nesting and including sub-scripts.

• Great and readable logging, both to the console/stdout while a build is running, and to XML and rich HTML log files.

To give you an example, here are some parts of our “rofx-xcode” build script:

include("$(Train)/ci2.train"); // Shared stuff specific to RemObjects' CI2
 
var versionNumber = ci2_GetVersionNumberFromGlobalIni("ROFX");
var sharedRofxWin = ci2_FindClosestSharedFolder("rofx-win"); // find closest/latest "rofx-win" build to copy stuff from
export("CIVersionNumber", versionNumber);
 
log("sharedRofxWin is in "+sharedRofxWin);
 
//...
 
run("Source/RemObjectsSDK.train");
run("Source/DataAbstract.train");
run("Source/TwinPeaks.train");
 
function buildTrial(_project, _targetBase, _sdk)
{
    xcode.rebuild(_project, { configuration: "Trial", target: _targetBase+" for OS X", sdk: "macosx",          destinationFolder: "./Bin" });
    xcode.rebuild(_project, { configuration: "Trial", target: _targetBase+" for iOS",  sdk: "iphoneos",          destinationFolder: "./Bin/iOS" });
    xcode.rebuild(_project, { configuration: "Trial", target: _targetBase+" for iOS",  sdk: "iphonesimulator", destinationFolder: "./Bin/iOS" });
}
 
buildTrial("Source/RemObjectsSDK/RemObjectsSDK.xcodeproj", "RemObjects SDK");
buildTrial("Source/DataAbstract/DataAbstract.xcodeproj", "Data Abstract");
 
// ...
 
xcode.rebuild("Tools/DASchemaModeler/DASchemaModeler.xcodeproj", { configuration: "Release",  destinationFolder: "./Bin" });
xcode.rebuild("Tools/DASchemaModeler/DASchemaModeler.xcodeproj", { configuration: "AppStore", destinationFolder: "./Bin" });
 
// ...
 
file.copy("Release/*", env["CIReleaseFolder"]);

Among other things, you see this script calls run() on “DataAbstract.train”, which is a subscript that we actually ship with the product, so customers can run it standalone if they want to rebuild DA from source. The console output of “DataAbtract.train” while it is running might look something like this:

Dream:Source mh$ train DataAbstract.train 
RemObjects Train - JavaScript-based build automation
Copyright (c) RemObjects Software, 2012. All rights reserved.
script(da.train) {     
  function buildDAProject(Data Abstract for OS X, macosx) {     
    xcode.rebuild(DataAbstract/DataAbstract.xcodeproj, [object Object]) { }   
    xcode.rebuild(DataAbstract/DataAbstract.xcodeproj, [object Object]) { }   
  } function buildDAProject
  function buildDAProject(Data Abstract for iOS, iphoneos) {     
    xcode.rebuild(DataAbstract/DataAbstract.xcodeproj, [object Object]) { }   
    xcode.rebuild(DataAbstract/DataAbstract.xcodeproj, [object Object]) { ...

As you see, it is nice and concise; you can see the flow of actions and JavaScrip functions the script is running thru, without any excess baggage (such as the extensive info Xcode dumps to the console).

Of course both XML and HTML log files can be generated as well, with the HTML being created from the XML using a standard XSL file included in Train. The output of a failed build might look like this:

Of course you can tweak the XSL, or process the XML log file in your own way, if you like.

The Bigger Picture

With Train, we now have the last part of our continuous integration system under our own control, running our own internal software.

The rest (and much bigger and more complex part) of our build infrastructure, affectionately called “CI2″, is very interesting too, and i plan to write more about it in the future (and we are looking into possibly open-sourcing more parts of that, as well — but currently many things in CI2 are designed pretty specifically around our own needs).

Train fits in well with CI2, but is a completely independent piece of technology, and we hope that by making it available as a true open source project (under the BSD license), it will be helpful to many others looking for a clean and easy way to automate builds (or, really, any task).

Train in Action

At RemObjects, we have 5 main repositories that our build system handles: “rofx-win” (Data Abstract, RemObjects SDK and related tools, for all platforms but Xcode), “rofx-xcode” (you guessed it: Data Abstract and RemObjects SDK for Xcode), “oxygene”, “hydra” and “everwood”.

At the time of this writing, all but “rofx-win” have been converted to use Train — and “rofx-win” simply hasn’t because it’s a huge and complex build script that just takes time to convert/rewrite (and in the process get cleaned up and rethought). But between the other four repositories, Train has already been getting some good and thorough real life use, both on Windows and Mac OS X.

Get Train

There’s two ways to get Train, both from github.com/remobjects/train.

• If you’re feeling adventurous and/or want to get involved in extending and improving Train, clone a copy of our git repository (or fork your on copy — we’re looking forward to your merge requests!) and build it yourself. The clone will include RemObjects Script, so all you need is Oxygene for .NET (the free command line compiler will do).

• Alternatively, you can just grab the pre-build .zip distro with the latest compiled binaries, ready to run on Windows and Mac OS X (via Mono). We’re currently at revision 0.5, the same version running on our build systems.

CPU-native, unmanaged code, is becoming less and less relevant these days, and we believe true nativeness of code, of applications, and — most of all — of the developer experience defines itself by other criteria.

Here at RemObjects, we pride ourselves on providing truly native software development solutions for a variety of platforms. We consider two different and separate levels to determine what we consider “native” development: a native user experience, and a native developer experience.

A Native User Experience

What makes a native user experience? For a long time, there was only one platform for mainstream development: Windows. This has changed, and users are, by and large, choosing their work environment by preference. Even when avoiding to get into the “OS wars”, it cannot be disregarded that each platform out there today has its own distinct user paradigms, and that customers usually choose their computing platform carefully and want their applications to work and behave well on that particular system, adhering to their platform’s paradigms.

Windows users expect applications to behave “the Windows way”, and Mac users want them to work “the Mac way”. Similarly, iOS users want applications for their iPhones and iPads that fit in with that platform’s design philosophy, and Windows Phone (7) applications once again need to adhere to completely different UI paradigms than what Android users expect from their platform of choice.

Obviously, the degree to which applications need to fit in with their surrounding platform varies — most games, for example, usually sport more esoteric and platform-independent UIs (after all, they aim to take you out of your daily routing and immerse you in an entertainment experience), while business and productivity applications usually should adhere to the platform most strictly.

Nativeness also isn’t purely driven by using stock UI controls and themes exactly as prescribed. For example, many of the most famous and most well-respected iPhone applications add subtle textures or nuances to the OS provided controls. But they continue to feel “native”, because they stick to the basic UI paradigms, and the controls — while looking visually refined — look, feel and, most importantly, behave according to the user’s expectations.

This is generally achieved by using what is often referred to as the “native widget sets” of the platforms. Whether it’s a standard Win32 “Button” control or a native Mac NSButton, each widget set provides its own unique look and feel — from the spacing of text within the confines of the surrounding rectangle, over font sizes, styles and gradient strengths and directions, to the intricate details of how the control reacts and animates when it is clicked or touched. These subtle details are ingrained in the user’s mind; the user has subconscious expectations for how the control will feel when used, often down to the timing of animations. What may seem like unnecessary attention to detail becomes crucial to the user’s experience, and the user will feel an “Uncanny Valley” effect, if their expectations are not met.

But nativeness extends beyond just user controls. Most operating systems provide a lot of general infrastructure that users are used to seeing and working with — from the standardized Open/Close or Print dialogs on desktops to OS-provided Email or Tweet sheets on phones.

We believe that in order to create a truly native user experience with your application, your development tools need to let you work with the native widgets and infrastructure of the platform. No matter how much effort is put into “one size fits all” libraries, no cross-platform button will ever truly feel like a standard Windows button, like a standard Mac button, like a standard iOS button. In order to treat your customers to a truly native application, you need to choose a development tool chain that lets you work against the native platform.

Currently, such tool chains include .NET/WPF, Metro/WinRT, Delphi/VCL (for Windows), Objective-C/Xcode (for Mac and iOS), MonoMac and MonoTouch (for Mac and iOS, respectively), Java (for Android) or MonoDroid (also for Android).

It goes without saying that here at RemObjects we try to support developers with all of these tool chain choices. On the compiler side with Oxygene, we don’t have full coverage, but we can provide support for .NET and WinRT, all the Mono variations, as well as native Java/Android with our new Oxygene for Java. With our Data Abstract product suite, we have you covered on literally each and every one of the combinations listed above.

But: we believe that a native user experience, while key, is only half the story for successful app development.

A Native Developer Experience

Back in the day when Win32 was the gold standard of operating system APIs (and before), developer tools needed to provide strong abstraction layers for developers to work against — because the OS APIs themselves were so basic that working against them directly was akin to working in assembly language (or was, in fact, working in assembly).

When tools like the later Turbo Pascals, Visual Basic, or Delphi first came out, development against the core DOS or Win16/Win32 APIs was a chore, so developers welcomed abstraction layers that made coding easier, from basic class libraries to UI abstraction layers such as TurboVision, OWL, the VCL, or MFC.

But platforms have evolved, and with the likes of Microsoft’s .NET and WinRT, Apple’s Cocoa (and Cocoa Touch) or Android’s Java-based Dalvik, OS APIs have long reached a level that is developer friendly, a level that can and should be coded directly against.

Further abstractions on top of these APIs are a distraction, not a help to the developer, as they add an extra layer of unnecessary overhead to both the application and the development experience. And such abstractions have repeatedly shown to be failures, like when VCL.NET tried to reconstruct Delphi’s well-liked class library on top of the (already much more evolved and sophisticated, but orthogonal and thus incompatible) .NET Framework (then at early version 1.1).

Unnecessary abstractions of already good (or great) APIs serve no purpose to the developers using them. On the contrary, they separate developers from the platform, and from each other. For every article, sample or blog post provided by, say, Apple or the Cocoa community that shows how to use a feature of iOS, there has to be the equivalent “and here is how you do it in MonoTouch”, “and here is how you do it in FireMonkey”, “and here is how you do it in …”. The abstraction keeps developers from being able to (re)use the platform vendor’s documentation or samples. Worse, it fragments the developer community on the same platform, keeping programmers from interacting and sharing code — every Cocoa control written in MonoTouch is a Cocoa control that can’t be easily reused by a developer using the native Xcode/Objective-C toolchain (nor by a developer using FireMonkey, or Titanium, or any other abstraction layer).

Abstractions also keep developers from adopting new platform features quickly and easily. When the latest SDKs from the platform vendor come out, developers using the native tool chains usually can start working with the new technologies from day one (or even earlier). The very moment a new Android SDK hits, native Java developers can consume the new APIs. The very day a new iOS version becomes available, Cocoa developers can start getting their fingers dirty with the new goodness. All the while developers stuck behind a non-native abstraction layer need to wait for their tool vendor to abstract the new APIs for them.

Not to mention that non-native development tools will often lock you in and force you to stick with the abstraction layer.

The main selling point and attractiveness of a non-native tool chain usually is “familiarity”, the notion that the abstraction layer will let you get into a new platform without the steep learning curve of, well, learning a new platform.

But that is misleading and frequently turns out not to be the case. The main learning curve on a new platform is usually not the development language, or even the class framework — it is getting to know the platform itself and how to write great applications for that platform (looping us back to our first criterium: the native user experience).

Working with an abstraction layer turns out to actually have the opposite effect than intended, by making it harder to understand the platform vendor’s documentation (which is all tailored towards the platform-native tools, of course) and making it harder to re-use existing code samples found online.

To go back to the example of iOS: having to look at and understand documentation or samples written for Cocoa’s Objective-C APIs might seem difficult, if one is not yet familiar with the paradigms of Objective-C. But what’s actually more difficult is having to look at that same documentation or sample and then having to figure out how it translates to your — say — C#-based abstraction layer.

And no abstraction layer is ever perfect. Eventually, the underlying platform and its APIs will leak through and will have to be dealt with. Any efforts to avoid getting to know and understand the platform before developing on it is misguided and only delays the inevitable. Eventually the abstraction is missing a feature and the developer has to dig down to the base APIs and implement it themselves. Or a bug arrises that needs more debugging than the abstraction layer supports.

As with the native user experience, here at RemObjects Software we have made it our mission to support (and encourage) developers to use platform-native development tools; you’ll notice we’ll even encourage developers to go for the more native tool chain in cases where recommending a less native solution would mean an additional sale for us.

On the compiler front, Oxygene supports platform native development on classic Windows, Metro (Windows 8) and Android, and it is also a great choice for cross-platform servers based on Mono. The one notable omission is iOS and Mac, for which we recommend the excellent Xcode and Objective-C, even though Oxygene can support it via non-native development tool chains such as Mono and MonoTouch or Java.

With the Data Abstract suite, we support native development for all current major platforms: classic Windows (via .NET and Delphi), Windows Phone, Mac and iOS, as well as Android and other Java-based platforms (Data Abstract for Java is currently in beta).

Other Concerns, Such as Code Reuse

We realize of course that other factors play into the decision for the development tool chain. Considerations such as code reuse might rank higher on the list of priorities than a native development experience, and that is ok.

Our philosophy is that, all other things being equal, developers should aim for a toolchain that is native on both accounts: user experience and developer experience. If necessary, a compromise in developer experience can be made — it is after all a compromise that affects only the developer, if pursued correctly. No compromise, in our experience, should ever be made with regard to providing a truly native user experience.

In terms of code reuse between platforms, we at RemObjects Software aim to help, both on the language front (by providing the common Oxygene language as developer-native language for .NET, WinRT and Java/Android, at least) and on the back-end database front, by keeping Data Abstract wire compatible and letting you share a common server infrastructure for all your native client applications.

Read More

You can find out more about our cross-platform, platform-native products, Oxygene and Data Abstract, at remobjects.com/oxygene and remobjects.com/da, respectively.

And you can find an overview matrix of how our products fit into the various native (as well as semi-native and non-native, if you must go there) development chains, at remobjects.com/products/toolchains.

Thank you for reading, and we are looking forward to your feedback and comments.

About a month ago, we started with a major focus shift towards our documentation wiki (at wiki.remobjects.com. Back when we first started the wiki, years ago, it was an innovative step in developer product documentation and provided a level of information and access that few other component and tool vendors offered. A lot of time has passed since, and we felt that a refresh is needed in order to provide even better and more thorough documentation across our products, from Articles over How Tos, and Samples to core Library Reference docs.

This will be a lengthy process, and you won’t see the wiki radically change over night, but instead, all thru the rest of the year, you should see steady progress and steady improvements both to the kind of information we provide and to how it is provided and accessed.

To accompany that, we want to start a (semi-)weekly series here on the blogs where we will keep you informed about what new content (and infrastructure) has been added in the past week (or so). Because we have a bit of a head start, this first post in the series will be a whopper.

Changed, Cleaner Per-Product Sections

The first thing you’ll see when you visit a product page on the wiki is that we’ve restructured each product’s root page (for example DA/.NET into four big categories — indicated by four big icons across the top.

These same 4 sections will greet you for every product, and they are:

Getting Started: Clicking this section will give you a page with a curated, hand-picked selection of articles, how-tos and (external) videos from RemObjects TV, streamlined to get new users (or existing ones) started with the product. For each product, we start with a detailed look at our project wizard(s) and a walk-thru of the project they generate. And we provide a list of How-Tos and articles about common tasks or goals that users will be likely to want to achieve after starting a fresh project.

If you look at these Getting Started pages now, you will still see a lot of red. That is because we purposely started with a blank slate: we did not want exiting content to drive these pages, so instead, we sat down and approached this from the user’s perspective: “What would you want to do next?”, and added the appropriate links. These will now need to be be filled — some by redirecting or reworking existing content, many of them, with fresh content.

Samples: Almost as important as starting a new project is to find your way around the existing sample projects. Each product now has a thorough overview page that covers all the sample applications we ship (for example RemObjects SDK Samples). The different editions of our respective products aren’t islands, and the samples from the different editions often work together or complement each other; that’s why each product has a shared page that covers the samples across all the platforms, where you can see how it all fits together, and, of course, dive into each of the individual samples.

As with the getting started, we have a lot of coverage still ahead of us, but you will see that quite a few samples are already covered.

Articles: For each product, the articles section (e.g. DA/Xcode will provide direct access to all the articles available for that product. We have always had tools in place that helped us manage the wiki and generate pages, and in the past we mostly used that for library documentation (more on that later). We’ve now extended that so that the Articles (and HowTos) sections are completely driven and auto-generated by meta-data in the individual articles. Each article topic in the wiki now contains meta-information on which product, platform(s), categories, classes and concepts it pertains to, allowing us to generate automatic (but designed to be human-readable) index pages. Articles can automatically reference the classes or concepts they refer to, just as the class documentation can automatically get links to articles that touch on a specific class.

We have started this process with a handful of articles — some new, some pre-existing, but reviewed and approved, so the lists will start out small, but over time we’ll be adding more new articles, as well as reviewing existing content and bringing it into the system if it is still up-to-date.

How-Tos: How-Tos essentially follow the same structure as articles, but are shorter topics that focus on individual tasks (“How do do i display my data in an NSTableView?”).

The Getting Started section is, essentially, a selective view into the larger pools of content that are Articles and How-Tos. These two sections show you all content, while Getting Started shows a hand-picked subset.

Library Docs

We’re also working on a brand new infrastructure for library documentation, which we’ll give more focus in a future blog post. In the past, we automatically generated the basic structure of the class reference pages, and then filled them within the wiki. With our new tool chain, the entire class documentation will be maintained externally, and emitted into the wiki automatically — this gives us more opportunities to use this documentation in other ways, too (for example for generating XmlDoc files), in the long run.

More about that, later.

Better Separation of “work in progress”

In the past, work on new pages (or even creation of empty stub pages) was done on the page’s final URL. This meant that when these pages were linked elsewhere, the links would show blue (instead of the red you see for a missing page), but when you clicked them, you got to an incomplete or empty page. That was frustrating. We are changing this now, so that new pages get written in different locations (with a “WIP” prefix in the URL), until they are ready for consummation. This way, we can start adding links to them, but those links will be immediately obvious as not having content yet. Only when the page is ready will it be relocated, and all the links will turn blue.

In some places (such as the automatically generated Articles lists), you will see that we add a blue “(WIP)” behind the red link, so visitors can find the work-in-progress pages, if interested.

New Content

• The first six chapters of our Developing Database Applications for Mac and iOS “work in progress” book have been made available on the wiki, free. These include a detailed overview of Relativity Server and Business Rules Scripting, a rundown of the New Project Wizard in DA/Xcode, two extensive topics on displaying data with UITableView and Core-Plot, as well as our “Why Multi-Tier” primer.

• Extensive Run-thrus of the New Project Wizard for DA/.NET, DA/Delphi and DA/JavaScript have been added just this week (and DA/Xcode is covered with the item above).

• Choosing a Custom Data Abstract Server vs. Relativity Server

• Setting up a Domain in Relativity Server (with Server Explorer for Mac)

• The entire product section for RemObjects SDK of Java, shipping later this month, is new, with Samples coverage and an initial set of articles on using RO/Java with Oxygene for Java and in Java Language IDEs.

Let us know what you think! And stay tuned to this space for continued updates.

Naturally, you can continue to use our tools for Delphi and .NET for desktop application development with Oxygene for .NET, Data Abstract and RemObjects SDK. If you are using Hydra, you can even combine Managed .NET and Unmanaged Delphi for the best of both worlds.  Then, with our latest JavaScript client libraries, we also have you covered in the browser.

The part that everyone is interested in is the new Metro style apps. These are the apps designed for touch on tablets and the desktop, and running in the Metro area of Windows 8. Most importantly, Metro style apps are the only ones available through the Windows Store. We got you covered for Metro, too. The latest betas of our .NET editions work with C#, VB and Oxygene for .NET to build XAML based Metro User Interfaces. Thanks to Windows 8′s new support for JavaScript based Metro apps, you can use our JavaScript client libraries for Data Abstract and RemObjects SDK to build Metro apps based on JavaScript and HTML/CSS too.

We are not in the unmanaged Metro space yet. Currently, the only tools that are supported there are Visual C and C++, which we don’t have libraries for. Hopefully in the future we will see that gap filled in one way or another.

One important thing to point out about the JavaScript client libraries is that they ship with all editions, including our Delphi editions. That means if you currently are building solutions with DA/Delphi or RO/Delphi, you can add JavaScript Metro client applications to your solution, all with the RemObjects licenses you have today. We will soon be offering DA/JavaScript as a free separate download too.

Currently, Metro support is only available in our beta builds (which are available to all users with current subscriptions). Rest assured that we will have final versions of our Metro support by the time Windows 8 ships.

What do you think about his points on the different levels of abstraction? Remember, whatever level you choose we’ve got you covered with Data Abstract and RemObjects SDK for Xcode, .NET or JavaScript.

As an added bonus, if your game is powered by Oxygene, we will provide you with a complementary Oxygene for Java license.

http://www.youtube.com/watch?v=Knw_gjtqi8k

While we of course fully support Metro with Data Abstract for .NET as well, this feature will also be available with Data Abstract for Delphi, so don;t be surprised if the DA/Delphi installer suddenly offers to integrate into Visual Studio ;).

Just as you’d expect, we provide a template for a Data Abstract Metro Application in the File|New project dialog:

which will launch into the familiar New project Wizard that you already know from DA/.NET and DA/Delphi. Of course JavaScript is a client-only technology, so the server options are not available, but you can choose to connect your JavaScript app to either Relativity Server or a custom Data Abstract Server.

As you can see, we’ve also started re-theming the wizard to match Visual Studio 11′s flatter look. I’ll spare you the remaining Wizard steps, as they will be pretty similar to running the wizard for DA/.NET or DA/Delphi.

Once the wizard is completed, you have a ready-to-run JavaScript application, with a couple of pieces of code that you can uncomment to easily download data and show it in a <table>.

For this post, i’ll enable the download of PCTrade‘s “CLients” table in default.js…

adapter.getData(clientsTable, RemObjects.DataAbstract.Util.createRequestInfo(true, 30, "", []), function () {
    new RemObjects.DataAbstract.Views.HtmlTableView(clientsTable, "table-clients");
  }, RemObjects.UTIL.showError);

and uncomment the matching <table> tag in default.html. When we hit “Start”, our Metro app comes up full screen, first showing the default DA/Metro splash screen:

and then populating the <table> with 30 rows of Clients:

Of course the IDE support for JavaScript expands beyond just the template. For example, the RemObjects SDK menu item sports the familiar Import RemObjects SDK Service entry that lets you import the RODL from an existing RO service and generate a JavaScript Interface file right in our project.

We’re very excited about the possibilities of Data Abstract and RemObjects SDK for JavaScript on Metro, especially as it opens up the platform to Data Abstract for Delphi developers without needing DA/.NET. We’ll talk more about this soon, so stay tuned.

Oh, and: The functionality shown here is available in the current beta that we shipped last Friday. Feedback appreciated!

First up is the video on building Windows 8 Metro Apps with Oxygene for .NET and VS11:

http://www.youtube.com/watch?v=IY5xRYpxJa8

Then, there is the podcast with Daniel Arroyo of Flaretag, discussing mostly the open source, cross platform mobile application framework Titanium, as well as Metro and JavaScript in general.

There are more podcasts and videos in the works, so stay tuned.

1. Using DashCode to create an interactive widget
2. Creating an interactive widget without Dashcode
3. Creating a RemObjects SDK client widget
4. Creating a Data Abstract client widget (this article)

In this article we will look at Data Abstract client widgets created without using Dashcode.

Data Abstract PCTrade Workers Image Gallery Widget

For this demo we connect to the PCTrade sample database and display worker images. This creates an image gallery type widget, except the images are pulled live from a remote database on each activation. You can see an example of what this demo will look like on our website. That demo may be updated in the future, but our widget will by default pull from the same database.

Data Abstract JavaScript Library Files

The following parts are needed for any Data Abstract JavaScript client you want to write. The minified versions are available on our sample server, or they ship in the .NET or Delphi versions of Data Abstract (coming soon to the Xcode version).

• RemObjectsSDK.js – The RemObjects SDK JavaScript library used by Data Abstract.
• DataAbstract4_intf.js – The Data Abstract interface class used by RemObjects SDK for Data Abstract.
• DataAbstract.js – The Data Abstract JavaScript library.

These files need to be included in our widget package.

Assembling the Widget Package

As you recall, the minimum requirements for a widget are:

• main.html – The main html file.
• Default.png – The “preview” image that is visible before the widget activates. Also determines widget size and aspect ratio.
• Info.plist – The manifest that describes the widget.

You can create the parts from scratch, or download this package of all the files. We’ll take a closer look at how it all comes together. The core of the functionality is in the main.js. While you could put all that JavaScript in the main.html file, putting it in a separate file makes for better maintainability.

I usually create my default.png files by taking a screen shot of my HTML page running in a browser window. Somethings I’ll edit it after taking the screen shot. Generally you want to have the screen shot be of the first screen the user sees so the transition from image to active widget is smooth.

All these files need to be in the same folder, and the folder needs to be renamed with a .wdgt extension. Remember: If you double-click that folder, it will be deleted and installed in your Dashboard. Use the context menu to show package contents instead.

Inside the main.html File

At the top of the main.html file, in the block, we reference all our scripts. It is important that these scripts are local and included in the package. They will not work from iBooks if they are remote.

<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
 
    <script src="RemObjectsSDK.js" type="text/javascript"></script>
    <script src="DataAbstract.js" type="text/javascript"></script>
    <script src="main.js" type="text/javascript"></script>
    <script src="DataAbstract4_intf.js" type="text/javascript"></script>
 
    <link rel="stylesheet" href="ro.css" type="text/css" />
</head>

The is also really simple.

<body onload="loadData();">
 
    <div id="wrapper">
 
        <h3>Data Abstract for JavaScript</h3>
        <h4>PCTrade workers gallery widget</h4>
        <div id="content">
        <a href="javascript:void(0)" onclick="showPrevious();">prev</a> /
        <a href="javascript:void(0)" onclick="showNext();">next</a>
        <br />
        <img id="photo" src="">
        <p id="name">Name</p>
        </div><!-- #content-->
 
    </div><!-- #wrapper -->
 
</body>

For the Body’s onload event, we assigned a loadData handler. This creates the service and downloads the data. There are two links to handle for moving to the next or previous image, with event handlers assigned, and finally an image and a paragraph with specific IDs assigned to hold the data.

Inside the main.js File

All the JavaScript that makes our widget work is contained in the main.js file. At the very top we declare our workersTable variable that gets defined in the connectToService function.

The createServices function actually contains two other functions. The first is includeScript, which is used to include DataAbstract.js and DataAbstract4_intf.js scripts when the call is made to connectToService, the second function in the createServices function. You’ll recognize this pattern and the includeScript function from the RemObjects SDK widget, and you will want to include them in your widgets.

The code you will customize in your own widgets is in the connectToService function, but most of it will be similar.

    function createServices() {
 
    function includeScript(scriptSrc, callback) {
        var headID = document.getElementsByTagName("head")[0];         
        var newScript = document.createElement('script');
        newScript.type = 'text/javascript';
        newScript.onload = callback;
        newScript.src = scriptSrc;
        headID.appendChild(newScript);
    }
 
    function connectToService() {
        // Use a different server here if you like:
        var Channel = new RemObjects.SDK.HTTPClientChannel("http://www.remobjects.com:8099/JSON");
        // Must be JSONMessage - BinMessage doesn't work in Safari
        var Message = new RemObjects.SDK.JSONMessage(); 
        var Service = new RemObjects.SDK.RemoteService(Channel, Message, "DASampleService");
        var daService = new DataAbstractService(Service);
        var loginService = new RemObjects.SDK.RemoteService(Channel, Message, "LoginService");
        var Adapter = new RemObjects.DataAbstract.RemoteDataAdapter(Service, loginService, RemObjects.DataAbstract.Bin2DataStreamer);
        Adapter.onLoginNeeded = function (aCallback) { 
            this.login("John", "John", function(msg) {
                if (aCallback)
                    aCallback();
            }, RemObjects.UTIL.ShowError);
        }
        workersTable = new RemObjects.DataAbstract.DataTable("workers");
 
        // Get the data
        Adapter.getData([workersTable], RemObjects.DataAbstract.Util.createRequestInfo(true, -1, '', []), function() {
            // This is executed when the data comes back.
            workersTable.first();
            displayImage();
        }, RemObjects.UTIL.showError);
 
    }
    includeScript("DataAbstract.js", function () {
        includeScript("DataAbstract4_intf.js", connectToService())
    });
}

The connectToService function creates the following:

1. Channel –This is the connection to the remote server.
2. Message – The message used as transport. Remember it needs to be JSON since Safari doesn’t like BinMessage.
3. Service – This is the specific RemObjects SDK service on the channel we are using.
4. daService – This is the Data Abstract service that uses the RemObjects SDK service.
5. loginService – This service handles login, if necessary.
6. Adapter – Provides access to the data tables.
7. workersTable – The DataTable that contains the data from the Workers table on the remote server.

In this example, it grabs the entire Workers table, but we could just as easily use DA/SQL here to only grab the parts of the table we are interested in.

The displayImage function simply displays the current image and name in the appropriate HTML elements on the page. It gets these values from the Workers Table.

function displayImage() {
    document.getElementById("photo").src = "data:image/jpeg;base64," + RemObjects.UTIL.toBase64(workersTable.getFieldValue("workerphoto"));   
    document.getElementById("name").innerText = workersTable.getFieldValue("WorkerLastName") + ", " + workersTable.getFieldValue("WorkerFirstName");
}

The showNext and showPrev functions move through the Workers Table and call displayImage to update the display.

function showNext() {
    workersTable.next(); 
    displayImage();
}
 
function showPrevious() {
    workersTable.prev(); 
    displayImage();
}

And that is all the JavaScript specific to this widget.

Deploying to iBooks

If you’ve already put all these files into a folder and renamed the folder with the .wdgt extension, you are ready to include the package in an iBook. Just add an HTML widget to your iBook and drag the widget package into it (or use the Choose… button from the Widget Inspector).

Be sure your iPad has access to the server and port www.remobjects.com:8099 since that is where the data is pulled from.

Summary

Data Abstract’s JavaScript client library brings the power of remote databases to your iBooks interactive widgets.

Things to Remember

1. All the scripts must be included in the widget package.
2. All JavaScript libraries must be referenced from the Main HTML file.
3. Use the includeScript function to include library scripts.
4. Don’t leave any JavaScript alert statements in from debugging. They lock up iBooks.

The IDE integration has been made independent from the .NET product, and now gets offered up for the Delphi (Visual Studio 11 and only on Windows 8 or later) and Java (Visual Studio 2012 and 11) product installers as well; the former to support JavaScript Metro clients, the latter to support Oxygene for Java.

The re-theming is also happening, with menu and toolbar glyphs and project templates getting adjusted to the new colorless Visual Studio 11 theme, as shown in the screenshot below (click to view full size).

As of now, the icons in Solution Explorer are driven by the file type icons registered for Windows Explorer, so it’s still unclear if we can theme those individually for Visual Studio 11 (without also forcing the flat look into VS2010 and Windows Explorer, which would not be good). Something we’re investigating.

Oh, and is that a Data Abstract template for Metro that you’re seeing there? Indeed it is. ;)

The RemObjects SDK template looks have also been updated; once again i’ve decided to keep a light touch of color.

Well, it would appear I was wrong.

I was reading Paul Thurrott’s Windows 8 Consumer Preview: A Call For Common Sense and one point of his really stood out to me: “The desktop is not the OS. It’s an app.”

He goes on to say . . .

The desktop is not the OS. In fact, while this isn’t technically true, conceptually, the desktop is just an app. The Windows 8 OS is comprised of Windows Runtime (WinRT), the Start screen shell and its Metro-style environment.

and . . .

For those many, many businesses that will rollout Windows 8 alongside Windows 7, the existing desktop environment looks and works almost exactly like its predecessor, and has no compatibility or long-term testing issues. That’s the goal for the Windows 8 desktop. All the exciting and new stuff is in Metro.

This really changes things. It means that the Desktop and traditional Windows programming has more in common with Windows XP mode on Windows 7 (running inside a virtual machine). I am not saying, nor have I heard anyone say, that the “Desktop” is running in a virtual machine, but the point is that the Desktop and traditional Windows programming is now officially “legacy”. In Windows 9 (or beyond), the Desktop may actually run in a virtual machine, or at least a sandbox.

Microsoft is replacing the familiar Windows API’s with WinRT, and this changes everything. Despite your opinions on JavaScript or .NET programming, they are now the preferred tools for developing on the Windows platform.