You are browsing the archive for Cooper.

Avatar of Jim McKeeth

by Jim McKeeth

Top 10 Reasons to use Platform Native APIs

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

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

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

Platform Native APIs are Great

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

The Law of Leaky Abstractions

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

Native Documentation

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

No Bloatware

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

Rapid Release Cycle

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

Support for Platform Deviations

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

Native User Experience

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

Less Points of Failure

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

Maximum Developer Flexibility

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

3rd Party Support

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

Summary

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

19 Comments »

Avatar of Jim McKeeth

by Jim McKeeth

Oxygene for Android Torch App

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

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

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

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

3 Comments »

Avatar of Jim McKeeth

by Jim McKeeth

Oxygene Goes to School

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

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

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

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

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

Comments Off

Avatar of Jim McKeeth

by Jim McKeeth

Android XML IntelliSense

July 9, 2012 in Android, Cooper, Java, Oxygene, Visual Studio

Many of the Android resources, from layouts and styles to animations and even manifests are defined in XML. The XML spec for all of these different resources is a bit dynamic and varies based on things outside the XML document. For these and other reasons there is no official schema provided by Google to define the XML document, as would be needed for Visual Studio to provide IntelliSense for these XML files.

The “June 2012″ release of Oxygene for Java changes all that. We’ve generated 4 schema files that provide IntelliSense for pretty much all the Android XML resources you may encounter. The IntelliSense provides elements and attributes, and in a few cases values for everything from Layouts to Manifests.

Because of the way the XML IntelliSense works in Visual Studio, and because the Android XML doesn’t completely implement the schema as it should, we had to rename the XML files to make them work with the schemas and provide IntelliSense. So to get all the Android IntelliSense goodness, you need to rename your XML layouts to *.layout-xml and every other XML document to *.android-xml. All of the examples and templates are updated with this new naming.

Android Solution Explorer

Since there is no official schema, and the XML specification in the Android documentation is a little vague in places, we are looking for your feedback how better to improve the IntelliSense. An important area you will notice is with user defined widgets in the layouts. Currently, the IntelliSense schemas are static, so if you add a new widget, it won’t show up in the IntelliSense. Let us know if you run into any other situations where the IntelliSense could be a little more intelligent.

Also, to make the IntelliSense even more helpful, we added a range of new item templates to Android projects. They all get put into the correct folder as required by the Android spec. For Drawables, it puts them in the default /res/drawable folder. From there you can move them to a drawable folder for a specific DPI.

Add New Android Templates

Likewise, if you come across any other Android templates that should be included to make your life easier, please let us know.

Comments Off

Avatar of Jim McKeeth

by Jim McKeeth

Summer’s Here!

June 12, 2012 in .NET, Cooper, Delphi, Hydra, JavaScript, Metro, Relativity, ROFX, Visual Studio

Change LogsJust in time for the start of summer, our “Summer 2012″ releases are here! There are significant updates in every single one of our products — three editions of Data Abstract, four editions of RemObjects SDK (the new one being RemObjects SDK for Java), both editions of Oxygene, and Hydra.

Metro

The big theme this time around is our preliminary support for Metro and Windows 8. Since Windows 8 and Visual Studio 11 are in Release Preview right now, our support is preliminary, but rest assured that when they get released we will have finalized support right away. This means you can start developing native Windows 8 Metro apps today, so you are ready! You will find preliminary Metro support in Oxygene for .NET as well as Data Abstract and RemObjects SDK for both .NET and JavaScript.

Free JavaScript Client Libraries

Another big annoucement is that our JavaScript client libraries are now abailable as seperate, free downloads. You can use these to freely add Metro clients to your existing Delphi, .NET or Relativity servers. Check out the video on developing Metro apps with Data Abstract for JavaScript. If Windows 8 Metro isn’t on your radar yet, you can also use the JavaScript client libraries to build browser based client applications, as well as mobile applications with tools like Titanium or PhoneGap.

Schema Modeler 7 Tech Preview

Beyond Metro and JavaScript, you will also find a Tech Preview of our Schema Modeler 7 for Windows. This new Schema Modeler has been designed from the ground up to provide a better and more streamlined schema editing experience. If you are familiar with the reinvented Schema Modeler from the Xcode edition, you will see they have a lot in common.

We’re still putting some finishing touches on DASM7 (as we call it internally), before we consider it “done”. This means DASM7 does not replace the old Schema Modeler yet. You can find it in the \Bin folder of your Data Abstract installation and give it a try — or run it with /register once to make it the default.

But Wait, There’s More!

This is just the tip of the iceberg. As always, check the change logs to see what else is new in the “Summer 2012″ release.

So renew your subscriptions with our recently reduced renewal pricing, upgrade to a new platform, or download a 30-day free trial today, and get a jump on summer!

5 Comments »

Avatar of Jim McKeeth

by Jim McKeeth

The Importance of Compatibility

May 10, 2012 in Android, Cooper, Java, Oxygene

When you are choosing a tool or library for Android development it is really important to consider platform compatibility. Some tools only support the latest and greatest version of Android, while the majority of devices are still running Gingerbread. It is always useful to consult the monthly updated Platform Versions Distribution when considering which version of Android to target.

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!

2 Comments »

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

Hydra 4 and Oxygene January 2012 Releases

February 1, 2012 in .NET, Android, ASP.NET, Cooper, Delphi, Hydra, Java, Oxygene, Prism, Visual Studio, Windows, WP7

We’re hitting the ground running for 2012 and finished January with the first two product releases of the year.

Hydra 4

Hydra 4 is a major new release for our .NET/Delphi cross-platform product, and one we’re very excited about. Hydra has been at version 3 for a while now and seen mostly incremental changes, but with version 4 we’re adding three major new features/platforms to the mix:

  • Support for 64-bit Delphi Host Applications and Plugins
  • Support for FireMonkey Host Applications and Plugins
  • Support for hosting Silverlight-based Plugins

Compiling true 64-bit Windows applications has been on the wish-list for Delphi developers for a long time, and Delphi XE2 finally provided the elusive support, and Hydra has been updated to match. This makes it easier to build applications that use large amounts of memory, can interact with .NET plugins in 64-bit space, or simply run more natively on the 64-bit Windows systems that are standard these days.

FireMonkey is Embarcadero’s new framework for creating rich “HD” or 3D graphical user interfaces in Delphi, and it is destined to supersede the VCL sooner or later. Unfortunately, Embarcadero does not let applications mix FireMonkey (FMX) and VCL by default — but that is no reason to jump ship to FireMonkey and discard all your existing VCL code. Hydra adds FireMonkey to its list of platforms supported by plugins and lets you seamlessly mix new FireMonkey UI alongside existing VCL code or even among WinForms and WPF. And FireMonkey host support lets you create new FMX applications and integrate existing VCL (or WinForms and WPF) code and UI into them, as well.

Finally, there’s Silverlight, Microsoft’s platform for rich web controls and (more prominently, as of recent) Windows Phone 7. Silverlight is based on the same concepts as .NET but uses a smaller and a tad more limited runtime — in exchange it can run in Browsers on Windows and Mac, as well as on Microsoft’s new phone platform. With Hydra 4, Silverlight can now also run in your Delphi (or .NET) based host applications, alongside other plugins. This allows you to easily share code and visual elements between your web application and your desktop app, or between your phone and your desktop.

We think Hydra 4 will be an essential tool for the modern Delphi developer — whether to add .NET to your Delphi projects or to add FireMonkey.

Hydra 4 is a free update to all users with an active subscription and available for immediate download. If your subscription expired before January 27, you can renew now for $249 to get access to Hydra 4; the price for new users is $499, including on year of free updates (and we do have more exciting stuff planned for Hydra in 2012!). Of course Hydra 4 is also included in the Suite Subscriptions for both .NET and Delphi.

Oxygene — January 2012 Release

Last November, we shipped a major new release of Oxygene, introducing the brand new Oxygene for Java as second platform for everyone’s favorite modern Object Pascal.

After skipping the holidays, we’re back to our monthly release cycle, and the January 2012 release kicks the year off with a large range of fixes and enhancements for both .NET and Java/Android developers. Altogether, the change log contains over 170 improvements.

The new Oxygene build is a free update for all customers with an active subscription, including all users of Prism XE2 and RAD Studio XE2.

For those of you using Oxygene for both .NET and Java, the update (like all future updates) is a combined installer — it will automatically detect if you have both editions of Oxygene and update both.

Get Em While They’re Hot

Head over to our trials download page at remobjects.com/trials now to give Hydra 4 or Oxygene a spin. Or if you’re already a customer, visit the downloads page on your customer portal to get the latest versions.

Oxygene and Hydra go great together by the way. If you’re a Delphi-only developer right now but thinking about adding .NET code to your application, Hydra makes that easy, and Oxygene lets you keep using the familiar Object Pascal language, even for your .NET work.

Comments Off

Avatar of Carlo Kok

by Carlo Kok

Oxygene by Example – Command line parsing

December 23, 2011 in .NET, Cooper, Mono, Oxygene, Prism, Uncategorized, Wiki

This is second article in my blog post series “Oxygene by Example”.

While working with command line arguments in Prism is quite simple, the “Main” method has an array of string that holds the value, it can become quite complex when having to parse options too. When having to work with those, it’s easiest to use the NDesk for Oxygene file. It’s a single file that can be added to any project (no need for a separate dll library). It was originally written in C# by Jonathan Pryor, we ported it to Oxygene so it can be embedded in an Oxygene project too.

The first step is to add NDesk.Options to the uses list, this is where the classes are defined. A general console application entry point looks like:

class method ConsoleApp.Main(arguments: array of String): Integer;
begin
  var lSourceUri: String;
  var lDestinationUri: String;
  var lSomeOption: Boolean;
  var lShowHelp: Boolean;
  var lOptionSet := new OptionSet(); 
  var lFiles: sequence of String;
 
  lOptionSet.Add("s|source=", "{filename or url} of source object", v -> begin lSourceUri := v end );
  lOptionSet.Add("d|destination=", "{filename or url} of destination object", v -> begin lDestinationUri := v end );
  lOptionSet.Add("o|someoption", "some binary option", v -> begin lSomeOption := assigned(v) end );
  lOptionSet.Add("h|?", "show help", v -> begin lShowHelp := assigned(v); end );
  try
    lFiles := lOptionSet.Parse(arguments);
  except
    on  Exception  do
      lShowHelp := true;
  end;
  if  (lShowHelp)  then begin
    lOptionSet.WriteOptionDescriptions(Console.Out);
    exit 1;
  end else  begin
    Console.WriteLine('Options supplied:');
    Console.WriteLine('Source: ' + lSourceUri);
    Console.WriteLine('Destination: ' + lDestinationUri);
    Console.WriteLine('Some option: ' + iif(lSomeOption,'ON','OFF'));
    for each el in lFiles do Console.WriteLine('Argument: '+el);
  end;
  Console.ReadLine();
end;

The OptionSet class is the main class for the options parser, first you have to define the different options by using the “Add” method. The first parameter defines what option it maps to. in “s|source=”, there are two bindings for this option, “s” and “source”, the | just separates them. The “=” is used to denote that the option takes a parameter. “s” is a single letter option, to use it one can use “MyApp -ssourcefile.text”, or “MyApp –source sourcefile.text”, the short options do not have a space, and a single dash, the long options have a space and two dashes.

The second parameter for Add is the description, when writing out the option list it will print this (see below), the last parameter is a delegate that gets called when it’s triggered. This delegate (in the cases above we use anonymous methods) has one parameter with the value passed. From these anonymous methods we set the options we define in the variables above it, that way we can read them later on.

The last step is lOptionSet.Parse(arguments), this will return a list of “rest” parameters, anything that’s not an option (or parameter to an option) will be in this list. It will raise an exception when there’s an error parsing arguments. We set the lShowHelp to true in this case, so we can later write the options to the console with WriteOptionDescriptions.

Using the Ndesk.Options classes makes parsing parameters a lot easier than doing it manually. The OptionSet classes have a lot more features, all of which are documented at the top of the source file Options.pas.

The original version of this article can be found in our wiki.

Comments Off

Avatar of marc

by marc

Announcing the Oxygene 5.0.31 release, and Oxygene for Java

November 30, 2011 in .NET, Cooper, Java, Oxygene, Platforms, Prism, RemObjects, Visual Studio

Today we are proud to announce the release and immediate availability of Oxygene 5.0.31, introducing our brand new second platform edition of the Oxygene language: Oxygene for Java.

This release marks the culmination of more than a year of work from the Oxygene team, and is, I believe, one of the most important milestones the product has seen so far.

So, what’s new in 5.0.31?

Oxygene for Java

The main new feature in this release is, of course, our new support for the Java runtime environment. Oxygene for Java is a separate product and not part of the existing “Oxygene for .NET” (a.k.a. Embarcadero Prism) SKU, but it is built on the same code base and, in fact, shares the exact same binaries with its older sibling.

But what is Oxygene for Java, exactly?

Oxygene for Java is the same Oxygene language and IDE experience that you already know and love on the .NET platform – for Java. It is literally the same compiler, and all the language features are the same (there are a few very minor differences owed to the underlying platform, but these are so minor, even I don’t remember what they are ;).

Just like Oxygene for .NET directly consumes the .NET assemblies and the .NET framework (and third party) classes, Oxygene for Java directly consumes java .JAR files and gives you direct access to the standard Java class hierarchy and any first and third party libraries out there. Just like Oxygene for .NET generates 100% native .NET assemblies, Oxygene for Java generates 100% native .JAR files indistinguishable (expect by their awesomeness from all the cool language features you can use on the inside) from those created using the Java Language.

Oxygene for Java shares the same IDE experience as Oxygene for .NET. It integrates with Visual Studio (for now; we’re also looking at integrating (both editions) into more traditional Java IDEs, such as Eclipse), along with all our advanced features such as the Smart Editing capabilities, advanced inline error reporting, etc. and all the standard Visual Studio infrastructure, from project templates to Solution Explorer. If you are familiar with working on .NET projects in Visual Studio, you already know how to work with Oxygene for Java projects, as well.

Oxygene for Java also includes a full-fledged Java debugger integrated into the Visual Studio IDE. Use the Visual Studio debugger infrastructure to launch or attach to Java and Android applications, leverage watches, view stack traces, switch between threads, choose what Java exceptions to break on, step from Oxygene for Java into Java Language code. All your expertise debugging .NET applications in VS will apply right to debugging Oxygene for Java projects.

Finally, Oxygene for Java integrates the full Android deployment tool chain into the Visual Studio IDE. Just press Run, and your project not only gets compiled, it also gets post-processed for Android, packed into an .apk, and sent right to the emulator or your attached Android device, ready to be debugged and tested.

And this is just the beginning. Moving forward Oxygene for Java and Oxygene for .NET will evolve side-by-side, gaining new language features and other enhancements at the same time.

Oxygene for Java is available at remobjects.com/shop now, for only $399. Or get the bundle with Oxygene for .NET, at only $599.

Is that all?

No, of course that’s not all. Oxygene 5.0.31 also includes a large set of fixes and improvements for existing users of the .NET compiler, as well as a handful of minor new features (despite officially being a “bug-fix only” release, on the .NET side:

Experimental Support for the Visual Studio 11 Developer Preview has been added, letting you try out Oxygene in the next version of Microsoft’s IDE. This does not include new features for Metro/WinRT and .NET 4.5 yet (we’re working on those, but are not quite ready to ship them in an official release), but the core Oxygene features should be usable (both .NET and Java).

Oxidizer has been expanded with support for importing and pasting Java Language Code (in both product editions), in addition to the existing options for legacy code Delphi and C#. Although it is most useful for Oxygene for Java users (just like Importing C# is mostly useful for .NET users), this can be helpful when wanting to use generic/algorithmic Java code in an Oxygene project, as well.

Finally, a lot of work has been done to improve IDE Performance throughout the product, and all project templates have been updated to enable the “Warn on case mismatch” turned on by default, as we think that’s a good practice, and more Oxygene users should be exposed to that feature by default.

Enjoy

So, that’s Oxygene 5.0.31. We’re very excited about this release (and about where we will take the Java platform and Oxygene in general over the next year or so), and I hope you are too. We’re only getting started.

I think this is a great time to be an Oxygene developer

Yours,
marc

Comments Off