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.

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

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.

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:

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

Here at RemObjects, I field the majority of so called “sales related” emails (that is, emails that aren’t technical support requests handled by our excellent support team and the product developers) myself — and as this century gets older, I see more and more requests asking what tools and toolchains to pick for different platforms. “Can I develop for both Windows Phone 7 and Android with Oxygene and share code?” — “Which version of Data Abstract is best for targeting iOS?” — “Should I use Oxygene for .NET with MonoDroid or Oxygene for Java for my Android app?”.

There are a lot of great development tool chains for the different platforms out there — be they Xcode/Cocoa, Visual Studio/.NET, Delphi, JavaScript — and sometimes the decision does not seem easy, because here at RemObjects we provide editions of most of our products for various development platforms, and often more than one choice can be applied to a specific platform need.

To help make heads and tails of this, we created a small graphical overview chart on our website that gives insight into which language/framework/product combinations we support on any given platform and — more importantly IMHO — which combination we recommend.*

[*And that recommendation might not always be what you think — for example, I often get looked at weirdly when I recommend Xcode over our own Oxygene (plus Mono) for Mac development. But development tools, even versatile ones such as Oxygene, or Delphi, or Visual Studio, are not and should not be Jacks of all Trades, and thus no single tool, no matter how great (and we happen to think Oxygene is pretty great ;) can be the best choice for all scenarios. We acknowledge and honor that.]

You can find this overview matrix — which will be ever-expanding as time goes by and the development world around us changes — at remobjects.com/products/toolchains; i’m also including a static screenshot of it, below.

May it help you to choose the best set of tools for your needs!

adbWireless

adbWireless one is solely aimed at developers, and I was introduced to it by Jim McKeeth’s blog post on using it in conjunction with Oxygene for Java.

Once you enable the app with the big red button on the main screen you can have adb on your computer hook up to your device across the Wi-fi network, rather than via the more typical USB cable connection. This is done using the adb connect <IP_address> command, where the IP address has a port specification and is supplied by adbWireless after the button is pressed.

After making this wireless adb connection, you can work normally from the computer, deploying, running and debugging against the device. This works from any Android development tool, such as Eclipse or Oxygene for Java.

One rather large caveat, however, is that adbWireless only works on a rooted device. Rooting your device to gain root access is not risk-free (so on your own head be it!) and not always achievable.

In my case I recently tried to root my HTC Desire, but failed to do so (fortunately without bricking it). This was not due to a lack of information on how to proceed – indeed the Desire is (relatively) old now, being introduced in February 2010. However the avenue I took to root it (unrevoked – a very straightforward, automated, hands-free approach) had not been updated to cope with the most recent firmware update that was applied to the telephone not long ago. I’ll have to try again when unrevoked is next updated.

I very much like the idea of adbWireless, but currently I’m not in a position to try it out….

AirDroid

AirDroid is a general way of controlling your phone, using its services and accessing its data from a web page loaded on a machine on the same Wi-Fi network.

When you start AirDroid it shows you a simple IP-based local network URL that you can enter in a web browser on your computer, and a password to log in with.

Navigating to the URL in a desktop browser shows the web site pushed out by AirDroid, offering many options including:

• browsing, playing and setting your ring/notification/alarm tones
• browsing your photos, including options to download, set as wallpaper or delete)
• browse your SMS conversations, compose and send SMS messages
• browse/edit/delete your contacts
• browse all details of your call log
• browse installed apps, export apps and install new apps
• browse details of storage
• and more besides…

The app itself also allows you to analyse/control various aspects of your device, including running tasks (and the obligatory task killer) memory usage:

I’ve already found this app very useful. On my old phone I had a couple of apps that I’d refused to update with newer versions as I had seen the newer versions crippled the (free) apps and removed functionality from what I had installed. Additionally there was an app that had since been removed from the Android Market. With AirDroid I simply exported the apps in question from the old phone web site, then used the web site of the new phone to install them – problem solved!

Here’s the AirDroid web page showing storage analysis on a new phone that has been in active use for a few days:

Note that AirDroid works on any Android device, regardless of whether it has been rooted or not.

Also note that AirDroid is currently in beta and so you do occasionally get little hiccups, but in general it is an impressive piece of work.

In that previous post I mentioned:

Sometimes a small change in the application, like updating the package name or altering the signing process (i.e. changing the package’s signature), will mean an application can’t be re-installed over a previous version.

Just to add more detail, I realised there is a classic case of this type of issue. In building up either Android samples or proper applications in Oxygene for Java, I often copy the project between machines, switching between a couple of laptops and a VM on a desktop machine. In the case of simple projects this machine switch is either done using a shared network drive or using my DropBox folder.

The point is that as soon as I switch to another machine and start building a regular Android application I can no longer install it from the development environment. This is because Oxygene wants to re-install the application (so that any app data, such as SQLite databases) are preserved between increments of the application. That’s nice of Oxygene, but it’s hitting an issue with this goal.

Here’s the problem. As I mentioned in another article, without a dedicated certificate, the Android SDK tools invoked by Oxygene will use the default Android debug key to sign the application. The Android debug key is created on a given machine the first time the SDK tools are used to build an application. From machine to machine each Android debug key will be different, so when you go to re-install the same application compiled on a different machine Android will notice the inconsistencies in debug certificates and reject the re-installation attempt.

You have no choice but to drop to the command-line and use adb to uninstall the application. After this, the application should install and run just fine.

Of course you get the same problem when using a dedicated certificate and you re-create it for whatever reason, or if on a given machine the Android debug certificate expires and gets recreated by the SDK tools (this happens every year, as the debug certificate is created with a validity period of 365 days).

Oxygene for .NET v5 was released as part of Embarcadero’s RAD Studio XE2 in September 2011 and Oxygene for Java was initially released in September 2011.

Both products feature a completely re-written Oxygene compiler, no longer written in C#, but written in Oxygene itself, both the .NET and Java versions sharing the same code base. The integration into Visual Studio was also entirely re-architected and re-implemented to support better future extensibility.

The January 2012 release of Oxygene cleans up a whole bunch of teething problems inevitable in a complete re-write of a product and also inevitable, in the case of Oxygene for Java, in a product targeting a whole new platform. It also introduces new features and covers a number of user requests. The change log details the plethora of updates, improvements and fixes.

If you already have Oxygene in one of its various guises and have an active subscription, then you can pull down the update from the RemObjects downloads page. The update will work out which Oxygene edition (or editions) you have and update accordingly.

If you want to try Oxygene, either for .NET, Java or both platforms, pop along and get the updated trial version.

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.

This new area on the Android developer’s site gives the low down on how to design Android applications and looks at the various controls, common aspects of Android UIs, style, and much more. It’s been put together to help people get a handle on how to work with the new Ice Cream Sandwich (Android 4.0) release.

It makes useful and interesting reading!

When building Android apps with any development tool, be it Oxygene for Java, C# and Mono for Android or Java and Eclipse, there are a lot of different tools trying to work together to produce the results you want. In the case of Oxygene for Java we have Microsoft’s Visual Studio, RemObjects’ Oxygene for Java compiler, Google’s Android SDK tools and Oracle’s Java tools. All different tools, of various versions from different software companies. Sometimes tools from different vendors don’t play well together.

For most of the problems I mention above i find the commonest cause is that the Android Debug Bridge (adb) daemon has gone ‘stale’. You can try a quick remedy by bringing up a command prompt and running these commands:

adb kill-server
adb start-server

Then try what you were trying before and see if that improves matters. Note that you’ll need the Android SDK’s platform-tools directory on your path to run the command without fully-qualifying the call to adb.exe.

If that doesn’t fix the problem then you should resort to the Android logs to see if there are any clues, for example, in the case of an application not installing on a device or emulator.

You can see the logs either by using:

adb –d logcat

or by running DDMS from the Android SDK and selecting the appropriate device.

During the attempt to install your app there will be log messages showing the progress and when the failure occurs you should see some sort of error message and maybe a call stack to assist working out what’s wrong.

Additionally, if you install your app from the command-line (as opposed to your IDE) you will often see an error code printed, which you can look for advice on with an Internet search. The error code is the name of a static field from the PackageManager class, albeit one that won’t be listed in the Android SDK documentation You can, however, find them in the Android source.

A command-line install looks like this

adb –d install –r mypackage.apk

The –r switch requests a reinstall, which preserves app data such as databases. If that is not important, skip the –r from the command.

For example, if you messed up the details of a certificate the app was signed with, you might get this:

Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]

or perhaps this:

Failure [INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES]

Searching the Internet will tell you that during the package manager’s verification process it couldn’t verify your package was suitably signed – perhaps because the certificate was in error, or maybe because you are using JDK 7 and haven’t worked out how to work with it’s set of new default values that affect harmonious Android development (I’ve written about this issue as it cropped up in this article).

Sometimes a small change in the application, like updating the package name or altering the signing process (i.e. changing the package’s signature), will mean an application can’t be re-installed over a previous version.

Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE]

You can easily deal with this by forcibly uninstalling the prior version, again using adb. If your app’s package is called org.me.myapp and is on a physical device, you’d use:

adb –d uninstall org.me.myapp

Change the -d switch to a -e if using an emulator instead.

I’ve been quite surprised how many times rather annoying issues have been deftly resolved by simply restarting the adb daemon, or uninstalling an old version of an app that was ‘getting in the way’ of a new version being installable.

One other point to mention before ending is that DDMS is a great log viewing tool, but it acts as a debugger. If you have it running and then try to launch an application for debugging from Oxygene for Java, you won’t get very far as DDMS will already have set itself up as the primary debugger. To debug, you must first close DDMS, which isn’t a great loss – the Oxygene debugger does have a logcat window that shows the same logging information as DDMS does.

So I thought it best to write all my findings up in a detailed article on the matter from the viewpoint of an Oxygene for Java developer – it turned out to be much longer than I was expecting! You can find the article on my web site as Using the Google MapView in Android with Oxygene for Java.

I hope you find it useful – it represents quite a long time spent researching and fiddling and testing things out!

In Java this is done using some syntactic sugar that gets the compiler to implement the interface in an anonymous helper class. When working with the Oxygene language we also need this syntactic sugar to avoid degenerating into a mess of unwieldy code, hence the introduction of inline interface implementation.

There are various ways of using inline interface implementation and a couple of other options for implementing events, so I’ve written up a short article illustrating the primary options available for those using Oxygene for Java called Android event handling & inline interface implementation with Oxygene for Java. If interested in following up on this, you can find the article here on my web site.

The idea was to have a web-resident database sat behind a web service that could be queried with various different search criteria to get resources around a specified location. Nail Soup were happily building the web service, a web front end and also the iPhone app, and they asked me to build the equivalent Android application. Since at the time it was very close to the release of Oxygene for Java I chose that as the development tool for the job.

The app was completed and published for the target release date of 19th December 2011 and the iPhone and Android versions are in the Apple App Store and the Android Market respectively, though they are only visible to people in the UK since they are providing UK-specific resources.

Amber Homeless Helper is the first published app built with Oxygene for Java and was fun to do. It’s not the most complex application, primarily being a search tool with some additional information and the ability to contact Amber and donate to the charity, as well as look at previous archived search results but involved a number of technically interesting aspects of Android development. Additionally it acted as a good test of the initial 1.0 release of Oxygene for Java finding a couple of rough edges that were quickly addressed by the developers at RemObjects.

This post is intended to give an overview of what areas of Android programming were involved in getting the Amber Homeless Helper to its finished state, operating as the design dictated.

On start-up you can immediately see a couple of things about the app, even if we ignore the splash screen (shown at the top of this blog post). Firstly, it uses a tab widget to allow the five main screens (aka activities) to be selected. This is quite straightforward to set up in the main activity layout and main activity class.

Secondly, it departs from the typical default Android colour schemes of white on black (or black on white) and uses colours more associated with Amber Foundation. This required using a custom application theme in a theme.xml file and some custom styles in a styles.xml file applied. In fact, just to check I could achieve it (and this wasn’t in the specification) I built in the custom colour scheme in a manner that allowed me to turn it on and off by selecting or deselecting the custom theme.

It turned out this was mostly very straightforward. The slightly sticky part involved the tabs. In the colourful version of the app these are custom-drawn to allow the gradient backgrounds to be achieved and to round off the tab corners. In the original version of the app they are the stock tab widget. So some conditions were added into the main activity to differentiate between a custom theme or the default theme, which itself was identified using the value of a custom attribute (defined in an attrs.xml file) used in one of the styles. Other than that the theming is automatic.

Another thing evident on start-up is the application icon being inserted into the status bar. This is a nice little touch achieved by calling:

requestWindowFeature(Window.FEATURE_LEFT_ICON);

before loading up the activity layout and then afterwards calling:

FeatureDrawableResource[Window.FEATURE_LEFT_ICON] := R.drawable.amber_app_icon;

Clicking the information buttons on the home page brings up typical Android dialog style views, achieved by applying the Theme.Dialog theme to the activity that displays the explanatory text.

The Search page is the main focus of the application. It’s where most of the functionality is invoked from and set up for.

The available service categories are not hard-coded. On first run they are sucked in from the web-resident database via a web service call and stored in a local SQLite database. When the app starts up a custom Application object starts the ball rolling by checking if the categories in the remote database are more up to date than what we have locally. If so, it queries the database to get the new categories and records when they were updated.

By this time the user may already have gone to the search screen so to communicate the new information over the custom Application object broadcasts a custom Intent. The search page has a broadcast receiver registered in case such an Intent comes along so it can update the service category list onscreen.

The web service is SOAP-based so I used kSOAP2 to communicate with it. This was straightforward: just a case of referencing the kSOAP2 .jar file and then calling the relevant methods. Additionally, to ensure the UI experience wasn’t affected by the Internet communication all web service calls were set up to operate asynchronously in secondary threads.

When searching for resources in the app you can either enter a location and search within a specified radius, or use your current location. To support searching on the current location there’s code running in the background trying to identify where you are as soon as the Search page shows up, using either the coarse network cell-based location and/or GPS-based location identification. It continues to search, in an attempt to refine the location or keep track of where you are if you are moving, until you leave the Search page – as soon as the Search page is switched from in one way or another this location detection is disabled.

When you initiate a search with one of the search buttons your search criteria are collected: category, radius, location and optional additional advanced criteria. These are sent off to the web service to get some results.

The search results are available in two forms: a map and a list.

The red pins indicate matches on the sought categories, and the purple pins show other resources that may additionally be useful.

The map is implemented using Google’s MapView control. However this control is not part of the Android SDK – it’s part of an add-on library that you need to pull down with the Android SDK Manager. You also need to add it to your project, specify you’re using it in your Android manifest file and take other steps to have it work at all. It requires you to have an API key, which you get from a Google web page after plugging in the MD5 fingerprint of the certificate used to sign your application.

Even if you don’t explicitly provide a certificate to sign your app with, it will still be signed using a debug certificate created when you first build with the SDK. But if your goal is to publish to the Android Market you may as well create a specific certificate, sign the app with that and use it to create the map API key. This API key needs to be given to the MapView control, either specified as an attribute in the layout file or passed as a constructor parameter.

If this all sounds rather convoluted and complicated that would be because it is rather convoluted and complicated. It’s a shame Google wanted to keep the map controls out of the open Android OS, but I’ll write more later on the technical specifics of using these map controls with Oxygene for Java.

The problems with maps don’t end there. When programming for iPhone and iPad with iOS the map control there has lots of pre-packaged functionality, including support for adding markers to the map that can be clicked on, yielding a nice balloon box with a title and text in and so forth. On Android we don’t get such niceties all ‘in the box.’ Apparently the iOS functionality was put together back in the days when Google and Apple were close allies and good working partners, before the days of Android. So iOS benefitted from the Google expertise, but for some apparently inexplicable reason, Google didn’t ensure their own map offerings for the Android platform matched in capability and richness.

The Amber app does achieve this popup balloon effect, however:

But it requires some work to do. Indeed a little search turned up an implementation of these map balloon views already done for Android users, so I made use of that work.

The map also has the search radius displayed as a circle on the map, so that involves another map overlay which I coded up and added to the map view.

Tapping the balloon view opens another activity that displays the full details of the selected service:

Buttons on this page will dial the service provider telephone number and open its web site. Buttons on the Donate and Contact pages support donation through SMS and communicating with Amber via email. While it is quite feasible to have the Amber app actually send an SMS or display a web page or send an email or dial a telephone number, there are also good reasons why the app chooses to not directly do this. Instead it makes use of the inbuilt SMS app, web browser, email app and telephone dialler.

These jobs were delegated for a couple of reasons. Firstly any Android system already has all the required functionality in pre-supplied applications and it’s very common to mix and match bits of the Android system into an application to avoid reinventing the wheel. But perhaps more importantly if the app was coded to, for example, directly send an SMS using the SmsManager class then it would need SEND_SMS added to the app’s list of required permissions.

If the app was coded to directly dial a number it would need CALL_PHONE added to the permissions list. When someone looked at the app on the Android market they would see the app requires these permissions and might choose to wonder how legitimately the application behaved with regards to text messages and phone calls and maybe choose to not install it. Delegating to the inbuilt apps, which get launched with the basic information filled in, removes those permission requirements and still ensures the user is in control as they can discard the SMS before it is sent, or close the telephone dialler before the call is made.

The other tabbed page not mentioned so far is the Archive page. This displays the list of previous searches made, whose results have been stored locally in the SQLite database. When an archived search is chosen the app checks to see if Internet connectivity exists. If it does then the results are displayed on the map page, otherwise the results list page is displayed. Archived searches can be deleted either individually or en masse through a separate screen (invoked through a menu item).

All in all, the majority of the work in the app deals with reading and writing various bits of data from and to the database, and making the asynchronous calls to the web service. Various proxy objects are used to represent the search results and the list of found services that are returned to make things more manageable.

Since Amber Homeless Helper’s release it has got some press coverage:

• The Guardian’s Social pages on 20th December, 2011:
  
• The Wiltshire Times on 23rd December, 2011:
  
• The West Sussex County Times on 30th December, 2011:
  
• This is Surrey Today on 30th December, 2011:
  

The app took a couple of weeks to build (albeit with my previous experience of the Android SDK and how Android applications work in general) and we spent a couple more weeks  testing it out and tweaking things and fixing bits, but it was a pleasingly short development cycle. I’ve found that Oxygene for Java makes an ideal tool for the Delphi developer to jump into the Android development world.

You can find the Amber Homeless Helper, if you’re UK-based in the Apple App Store here and in the Android Market here.

You can find the article on my web site at http://blong.com/Articles/OxygeneForJavaIntro/OxygeneForAndroid.htm.

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.

Anyone familiar with Delphi Prism, which is RemObjects’ .NET compiler (also known as Oxygene for .NET) will know it is a high-performance compiler with some lovely enhancements to Object Pascal and support for all features of its target platform, .NET.

Oxygene for Java is the same compiler, the same language, but targeting the Java platform. This allows you to build:

• cross-platform applications running on the Java Virtual Machine (as per the trivial Mandelbrot example I blogged about before)
• Java applets (some applets I built in Oxygene based on some online examples can be seen at this test page)
• Tomcat servlets, as discussed by Sebastian Gingter in this blog post
• probably most interestingly, Android apps. Oxygene for Java supports a full tool chain for taking Java compiled classes and making them digestible to Android’s Dalvik Virtual machine
• pretty much any other Java-based utility

In the middle of November I popped over to Antwerp, Belgium to deliver the launch presentation for Oxygene for Java at Be Delphi 2011. There are some pictures from the day’s sessions here, including a couple from my presentation that have the tell-tale Oxygene logo on the screen.

Be Delphi was a great inaugural day-long conference from a new Belgium-based Delphi community.

Since that launch presentation (and after a couple of other small jobs) I’ve spent a couple of weeks working on an Android project for a client, writing it in Oxygene for Java. More on that in another post.

I’m hoping to be making plenty of noise about this product over coming months in various forms, but until the next post, just note that Oxygene for Java is now available at the RemObjects store.

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

The new release is available for all Oxygene users from the Licensed Downloads Page on our customer portal. It will also be available directly from Embarcadero, soon. As mentioned before, if you bought Prism XE2 from a different reseller, directly from Embarcadero, or received it as part of RAD Studio XE2, you can go ahead and register your serial number with us, two get access to the download, betas, and more.

Build 5.0.29.931 marks the third release of Oxygene 5.0.29, and is the last update before we consolidate the code bases and ship Oxygene for Java, (Code-named “Cooper”), at the end of next month.

Oxygene Betas

In addition to the new “master” release, we also shipped new beta builds of “Cooper” (Oxygene for Java) and “Echoes” (Oxygene for . NET), based on the common code base that we are preparing to ship next month. The Betas for Cooper and Echoes will be synced moving forward, both for the initial release and afterwards, as the two editions of the Oxygene language will advance together, now.

You can find out more about these beta programs on our new RemObjects Connect support forums, in particular at connect.remobjects.com/categories/cooper-beta and connect.remobjects.com/categories/echoes-beta (login needed). Anyone with a “Cooper” pre-order or a license of Prism XE2 registered with us has access to the betas, and we encourage you to check them out!

ROFX Betas

To round things off, we also shipped new beta builds of our Data Abstract and RemObjects SDK products, for all three platforms; highlights include enhancements to the JavaScript client (shipping next month) and domain import/export in Relativity Server.

Find out more about that at connect.remobjects.com/categories/rofx-beta.

As with Oxygene again, any customer with an active subscription has access to the ROFX betas.

RemObjects SDK for Java

Finally, we’re also putting the finishing touches on the first beta drop for RemObjects SDK for Java, code-named “White Lodge”,and expect the beta to become available next week. If you talked to us about beta access before, expect to see email form us soon with details; of course you can also always pre-order our Java editions, for example when renewing your existing products – as many have already done. All pre-orders of course include full beta access.

As you can see, the year is far from over, and there’s still lots of good stuff ahead. See you on the beta forums!

marc

This blog post aims at giving you a quick overview into what’s there and how to use it.

RemObjects SDK and Data Abstract for JavaScript is essentially the fourth client platform for RO/DA that we have implemented, and constitutes a fully native JavaScript implementation of our RO/DA client library – with everything you need to talk to RO or DA servers directly from JavaScript-based clients. The main focus right now is on web clients (i.e. clients running locally in a browser), but RODA/JS should also be usable from any other JavaScript based platform, such as Windows 8′s Metro, cough WebOS cough, and the like.

RODA/JS is not a separate product; rather, it ships in the box with all three of our existing server platforms: RODA/.NET, RODA/Delphi and Relativity Server.

In most cases, you will want to add the ability to expose a scripting client right from inside the regular RO/DA server you are building, and we have created components that make this really easy: Both RODA/.NET and RODA/Delphi have gained (TRO)JavaScriptHttpDispatcher and (TDA)JavaScriptHttpDispatcher components that you can simply drop into your project and hook up to your server channels. These components embed and automatically serve the core RODA/JS script files, and can also serve any custom files (scripts and HTML/CSS/Images) that you created to implement your JavaScript client (from a folder or from resources embedded in your server app).

With that done, you can simply point your browser to a subpath of your server’s URL, such as http://localhost:8099/js to access your web app.

The screenshot above shows the RO/Delphi MegaDemo, but a similar component is available for DA and on .NET, and all MegaDemos and DA Sample Servers have been extended to already expose sample JavaScript clients.

If you run the server and point your browser to it, it will look something like this (not about to win any design awards, but it works ;) ).

What does the source look like? Aside from the HTML that defines what we see, there are three script files included:

<script type="text/javascript" src="RemObjectsSDK.js"></script>
<script type="text/javascript" src="MegaDemoLibrary_intf.js"></script>
<script type="text/javascript" src="script.js"></script>

The first is the core RO/JS library – automatically served by the JavaScriptHttpDispatcher component. The second is the Interface file for our server’s RODL – more on that below. Lastly, scripts.js contains the code we custom-wrote to implement our client. Let’s look at that in more detail:

First, we create our service and related components (I’m shortening the code a bit for the purpose of this post, if you look at the real sample, you’ll see it will optionally choose between JSON and BinMessage, etc):

var Service;
createService();
function createService()
{
    var svcUrl = "http://" + document.location.host + "/bin";
    Service = new MegaDemoService(new RemObjects.SDK.HTTPClientChannel(svcUrl),
    new RemObjects.SDK.BinMessage());
}

Next, let’s look at how we call Sum():

function BeginSumMethod()
{
    var A = document.getElementById("editA").value;
    var B = document.getElementById("editB").value;
    Service.Sum(A, B,
                    function SuccessSumMethod(result)
                    {
                        AddLineToLog('Result is ' + result);
                    },
                    function ErrorSumMethod(msg, ex)
                    {
                        if (ex) {
                            AddLineToLog(" Error: " + ex);
                    } else {
                        AddLineToLog(msg.getErrorMessage());
                    });
}

As you see, JavaScript is big on asynchronicity. Instead of calling Sum() and getting back a value, Sum runs asynchronously, and we provide a callback that gets executed when the result was received (and a second callback that gets called for any errors or exceptions).

To generate Interface files for your custom RODLs (such as MegaDemoLibrary_intf.js in the sample above), both Service Builder (Windows) and rodl2objc (Mac) have been expanded with an extra option to generate .js files. Simply open your RODL and save the Intf.js, as you already know how to do for all the other languages we support:

(As you can see, rodl2objc has also received a bit of an interface facelift ;) )

That’s RemObjects SDK for JavaScript, for talking to custom Web Services. Next, let’s look at Data Abstract.

Like with RO, making a DA server accessible from JavaScript is as easy as adding the dispatcher and (optionally) some custom script or HTML files. Here’s what the JavaScript sample for our PCTrade Sample Servers looks like (both for .NET and Delphi):

On the left, there’s list of all the tables, dynamically created by looking at the schema; once a table is selected, it shows a grid on the right. For this sample, we’re using a jQuery grid, but there’s nothing that inherently ties Data Abstract to jQuery or any other JavaScript framework – you get access to the raw data via a table object and can work with it any way you please. Of course, we cannot only show data, but also maintain updates and apply them back to the server.

Let’s look at the code again:

<script src="RemObjectsSDK.js" type="text/javascript"></script>
<script src="DataAbstract.js" type="text/javascript"></script>
<script src="DataAbstract4_Intf.js" type="text/javascript"></script>
<script src="/js/jquery/jquery-1.4.4.js" type="text/javascript"></script>
<script src="/js/jquery/js/grid.locale-en.js" type="text/javascript"></script>
<script src="/js/jquery/js/jquery.jqGrid.min.js" type="text/javascript"></script>
<script src="DataAbstractjQGrid.js" type="text/javascript"></script>

In addition to the core three RO/DA files (all of which are served by default by Data Abstract’s version of the JavaScriptHttpDispatcher), we include a few jQuery files, as well as a DA-specific helper file for jQGrid that we provide for your convenience. Once again, using jQGrid is just an implementation choice for this sample (much like using QuantumGrid would be for a Delphi app).

Other than that, all the application-specific script in this sample is in the main HTML file.

For example, here is how we set up the RemoteDataAdapter:

var Channel = new RemObjects.SDK.HTTPClientChannel("http://" + window.location.host + "/JSON");
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 rda = new RemObjects.DataAbstract.RemoteDataAdapter(Service, loginService, RemObjects.DataAbstract.Bin2DataStreamer);

And here is how we fetch data for a table (and show it using the jQGrid helper):

rda.getData(Tables[CurrentTable], function() {
                GridView = new RemObjects.DataAbstract
                    .Views.JQGridView(Tables[CurrentTable], "#list", "#pager");
            },
        function(msg, e) {
            if (e) {alert(e)}
            else alert(msg.getErrorMessage());
        });

If you’re familiar with RO and DA, you will already see that the classes are very similar to what you know. We have client channels, messages, remote services and a remote data adapter.

Relativity Server now also optionally exposes the required JavaScript files (including full Intf.js files for its admin API) as well as a JSON message. All you need to do to activate this is to check the Enable JavaScript Publishing option in Server Explorer:

If the option is grayed out, your Relativity Server does not support JavaScript yet; if the option is not available, you need a newer version of Server Explorer for Mac.

A Word about Cross-Domain Data Access

You might be asking: why does the JavaScript need to be served by the RO/DA server? Can’t I just put it on my website? Technically, you could, but there’s a limitation on most browsers that – for security reasons – won’t just let JavaScript connect to different servers willy-nilly. So if you’re opening a website from http://mywebsite.com, the browser won’t let the JavaScript on that site send requests to http://database.mywebsite.com:8099 – unless at least some of the scripts originate from that server. So you can embed JavaScript code in your website and have it talk to your RO/DA server on a different domain or port, but you must at least reference the RemObjectsSDK.js and/or DataAbstract.js files from the RO/DA server to let the browser know that it’s ok to connect there.

This limitation might not apply when using JavaScript on other non-web platforms, for example on Metro (we haven’t tested that yet) or application platforms such as Titanium. It’s a limitation of what the browser lets you do, not a limitation of our client library.

Summary

Our new native JavaScript client libraries open up RO and DA servers to a wide variety of new client platforms, with rich browser-based apps only being one of many possibilities.

We have a good six weeks of beta cycle left before this feature ships, and we hope you’ll give the beta builds a try and let us know any feedback you have. Head over to beta.remobjects.com now to get started.

Enjoy!