You are browsing the archive for marc.

Avatar of marc

by marc

Announcing RemObjects SDK for Java — Available Now!

May 8, 2012 in Android, Java, ROFX

Dear Readers,

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

No Comments »

Avatar of marc

by marc

Introducing “Train” — JavaScript-based build automation

May 2, 2012 in non-tech, RemObjects, Train


Today i’m excited to talk about a new side project that Carlo and i have been working on in our spare time over the past couple of months: Train.

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:


Train Log file

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.

6 Comments »

Avatar of marc

by marc

What, exactly, is “native” development?

April 19, 2012 in Android, iOS, Mac, Metro, non-tech, Oxygene, Platforms, ROFX, Windows, WP7

Some developers, mostly those tied to unmanaged languages such as C++ or Delphi, define nativeness as compiling directly to the byte code expected by the physical CPU. That’s certainly one way to look at it, but we think it’s imprecise, and doesn’t take into account the full picture and the complexity of today’s software systems. Consider this for example: if you compile an application for x86, and then run it on a x64 CPU – is that really “native”? Arguably not.

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.

16 Comments »

Avatar of marc

by marc

This Week on the Wikis

April 18, 2012 in non-tech, ROFX, Wiki

Hi.

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

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

No Comments »

Avatar of marc

by marc

Using Data Abstract for JavaScript in Visual Studio 11

March 19, 2012 in JavaScript, Metro, Month of Metro, ROFX, Visual Studio

As part of our Month of Metro, we’re also integrating Data Abstract (and RemObjects SDK) for JavaScript into Visual Studio, letting you create Metro apps that talk your servers.

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!

 

 

Comments Off

Avatar of marc

by marc

RemObjects SDK and Data Abstract in Visual Studio 11

March 9, 2012 in Metro, Month of Metro, ROFX, Windows

“Native” integration for RemObjects SDK and Data Abstract in Visual Studio 11 is coming along nicely.

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).


RemObjects SDK and Data Abstract in Visual Studio 11

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.


RemObjects SDK Templates

 

 

2 Comments »

Avatar of marc

by marc

“await”

March 8, 2012 in .NET, Metro, Month of Metro, Oxygene, Prism, Visual Studio

Progress is being made on our support for Metro, Visual Studio 11 and .NET 4.5 integration, on many levels. One exciting new language feature in Oxygene for both Metro and the regular .NET 4.5 framework is support for the new “await” keyword that is also coming to C#.

Simply put, “await” lets you use the result of an asynchronous operation (such as the result of many of Metro’s and .NET 4.5 new APIs) or — only in Oxygene — an async future, and have the resulting code be “wrapped around” to run asynchronously, as well.

In Oxygene, when you access a async future‘s value, your code will block right there, and wait for the future to complete before it continues executing — after all you’re using the value, and that value has to come from somewhere.

Using the “await” keyword, your code will look and work much the same as without, except your code will not block. Instead, all parts of the code that depend on the future value (or otherwise precede your accessing it) will be extracted and moved into a separate block of code that runs asynchronously.

This is best seen with a concrete example, so consider the following code:

method MainForm.CountFiles(aStartFolder: String): Int32;
begin
  result := Directory.GetFiles(aStartFolder).Length;
  for each d in Directory.GetDirectories(aStartFolder) do
    result := result+CountFiles(d);
end;
 
method MainForm.button1_Click(sender: System.Object; e: System.EventArgs);
begin
  var x := async CountFiles('C:\');
 
  MessageBox.Show('You have '+(await x)+' files.');
end;

Without the use of “await” (or without the use of the “async” keyword, which turns “x” into an async future Int32), this button click event would block, and your entire application would be hung while the program crawls across your harddisk to count files.

The async future, on its own, has the potential of making the the count asynchronous, but the following “MessageBox.Show” would block right away, making the use of the future essentially useless. Complex code could be written to wait for the future and then trigger the message box from a different place in code.

But “await” takes care of all that; it allows you to write code using the “naïve” approach without worrying about application flow. You can concentrate on your application logic, and the complexities of threading (and synchronization of results back to the main thread) are handled for you.

So what happens when you run this? Easy: when you click the button, our async future is created and started, causing the (recursive) call to CountFiles. Once that is up and running, the event handler is done and returns control to your application. Now the future is running in the background, counting files, and probably taking a few minutes to do it, depending on your harddisk size.

Once the future is complete, the message string is assembled and “MessageBox.Show” is called to display it — also on the main thread, synchronized via the application’s message loop.

All this time, your application remains responsive! As a matter of fact, in the example above, i could go ahead and click the button several times, launching a handful of independent file scans (which of course makes little sense in this scenario — a real app could disable the one button, or might let you scan different folders at the same time, getting the path from an edit field) that run in parallel, and will each eventually respond with a message box, one by one.

 

 

Comments Off

Avatar of marc

by marc

Tell me, where have all the colors gone?

March 2, 2012 in Cooper, Month of Metro, Prism, Visual Studio

Our first progress report for the “Month of Metro”.

One of the big changes in Visual Studio eleven is the new color scheme. Or should i say, lack-of-color scheme. Visual Studio 11 employs a new image style throughout the entire IDE for all icons, from project templates over toolbars to the files and other items in Solution Explorer.

Love it or hate it (and most people i talk to, including myself (yes, i talk to myself), haven’t really made it to the “love” side of things yet), but it’s unique and distinctive, and in order to be a proper citizen of Visual Studio 11, we have to embrace it.

I have spent the better part of yesterday working on our template icons and solution explorer icons, and i’m happy to share what we have come up with:

Solution Explorer

 

As you can see, i have tried to take some liberties, and not completely given up on color. In Visual Studio 2010, our project icons for Oxygene have been blue for .NET and yellow for Java, and i have stuck to that, and extended it to the code file icons as well, which show a subtle blue or yellow background shading.

Let us know what you think, but IMHO this retains a little bit of color in your solution, helps keep you distinguish between .NET and Java, if you happen to work with both, and i would say it still fits in nicely with the overal theming om the new Solution Explorer.

For reference, i have also included a C# project in the solution. In contrats to Oxygene, C# is entirely black-on-gray, and TBH i’m not really a fan of the “C#” text/logo as icon for the source code files – what do you think?

 

 

ps: my apologies. when i say “Solution Explorer”, i of course mean “SOLUTION EXPLORER”. ;)

4 Comments »

Avatar of marc

by marc

The Visual Studio 11 Beta is out

March 1, 2012 in Month of Metro, Oxygene, ROFX, Visual Studio

As most of you have probably already heard, the Windows 8 Consumer Preview and the corresponding Visual Studio 11 Beta are out, available for download here and here, respectively.

I’ve spent the past few hours installing everything in fresh VMs, and the good news is that — just like we expected, of course — our current “Spring 2012″ releases integrate with the new beta fine and, from initial testing, all the core functionality seems to me working:


Installing Oxygene on Windows 8

Oxygene projects for .NET and Java open and work fine; the RemObjects SDK and Data Abstract IDE integration is is also working fine:


Everything working in VS11

The main thing that sticks out is that our side of things stil looks “too colorful” (if that’s a thing) compared to the new bland ^H^H^H^H^H gray look that the rest of Visual Studio now employs. A lot of graphics work ahead for me, there (and TBH i’m not so sure that it’ll be a change for the better, but what can we do).

Oh, and as a teaser, you can already see the Oxygene Metro templates in the New Project dialog. Those aren’t available in the public build yet (and if they were, they probably would need some work to be adjusted to the new beta, as the entire Metro build toolchain was a bit of a messy hack in the DP. But more on that, in a later post).

Enjoy!
marc

 

 

Comments Off

Avatar of marc

by marc

Introducing the “Month of Metro”

February 28, 2012 in Metro, Month of Metro, non-tech, Oxygene, ROFX, Visual Studio, Windows

As you’ve probably heard, the first real beta of Visual Studio 11 and a “Consumer Preview” of Windows 8 are coming out tomorrow. We are very excited about VS11 and Metro, and we want to hit the ground running once the beta is available to bring Metro support to our product line.

For that reason, we are starting what we’re calling the “Month of Metro”. For the month of March, we’ll be buckling down and working on Metro support all across our teams and across all our products (where applicable). We’re planning to make weekly beta drops of our progress available to customers via our regular beta channels, and (knock on wood) to ship Metro support in an interim release at the end of March or early April.

Of course, the current releases we shipped this week already do provide basic integration into Visual Studio 11 (based on the current Developer Preview from last year’s //build/ conference); this upcoming work is focused on going beyond the existing functionality, towards new VS11- and Metro-specific features.

So what products does this touch? More than you might think:

Data Abstract and RemObjects SDK for .NET, obviously, will gain full support for creating managed Metro client applications that can talk to your servers.

Data Abstract and RemObjects SDK for JavaScript will support creating JavaScript-based Metro applications, including templates and the whole IDE experience.

Oxygene for .NET (“Emarcadero Prism”) will of course support creating managed Metro applications, WinRT components and anything else needed to make it a full member of the WinRT tool chain.

In addition, Oxygene for Java and RemObjects SDK for Java, while not directly supporting WinRT or Metro, will also benefit from integration into Visual Studio 11, of course. The same is true for Hydra.

Stay tuned to this page over the coming month for frequent updates. You can find all posts relating to the “Month of Metro” by subscribing to the category.

 

Comments Off