Tag Archives: Uniface 9.7

Uniface mobile – Custom Cordova plugin support

Some would have noticed that this week has seen the release of two new Uniface patches – G302 for 9.7.02 and F102 for 10.2.01. Normally I wouldn’t post about a patch, however, this time, there is something new that has been included that I would like to share with you. It is now possible to include custom plugins into your mobile app.

In 9.7.02 we introduced the ability to access the Buildozer online build services to compile iOS and Android apps. Included in this integration was the facility to select, from a predefined list, a number of plugins to be included and made available, in JavaScript, to your DSP application. The latest patches have increased this support to enable you to also include plugins from third parties or ones you have created yourself.

Looking in the development environment with the application shell type set to Mobile you will see it is possible to set the mobile app’s properties. With these patches, a new field has been added to the properties screen that allows you to specify one or more public (git) repository where the plugins reside. Now, with the plugins selected in application startup shell, you can submit your app to be built and, as part of server processing, the plugin will be downloaded automatically and included within your project.

Mobile app definitions
Mobile app definitions screen

As an example, we have been asked for the ability to interface with Bluetooth to print a label on a wireless connected printer. A quick search on Google (for Cordova Bluetooth plugin) offered me several options that seem to fit the bill one of which, picked at random, is https://github.com/evothings/cordova-ble. If I was to include their repository (https://github.com/evothings/cordova-ble.git) in my Uniface definitions, before building my app, I would be given access to the device’s Bluetooth capabilities using the documented API.

The Uniface G302 and F102 patches also include the latest documentation which has been updated to include this topic.

Loading loads of Glyphs

As a software developer, every once in a while you find yourself performing a tedious manual task for some hours. As it seems to be something you need to do only once, it does not seem to be worth automating the task. But then later it turns out that you have to do it again. So you make a quick and dirty tool. And then later a colleague has to do the same thing and asks if you have an efficient way of doing it. So you make your tool a bit nicer so people other than you can use it.

For me this happened for the task “load a very large number of image files into Uniface Glyphs”.

So here I present you my tool.

It allows you to select a folder on your disk, then it presents you all the files that are in the folder. You select the files you want to convert and press the button. Occurrences are created in the Uniface Glyph table. Files in an unsupported format are marked yellow, Glyph names and descriptions that are too long are also marked in yellow. Make your changes and press the next button and all your Glyphs are stored and compiled.

Now we can perform a task that used to take hours in a few minutes. (Admittedly you don’t have to do this very often but it is really boring task when you do need to do it!)

The attached Uniface export is for Uniface 9.7. With some adjustments it should also work with older Uniface 9 versions. You need to have a DICT model in your repository (have umeta.xml imported).

http://unifaceinfo.com/download/6470/

Disclaimer:

This tool is not part of the Uniface product and therefore not in support. It also uses some code that is not officially supported and that is subject to change without notice. Please feel free to change the tool to your own requirements.

Glyphmaster

NB:
Have a look at what I did around the selection of the folder:

  • You can either type the name,
  • Or select it from a dialog when you press the button,
  • or select it from your history using the dropdown.

 

Experimenting with the AWS S3 API

Last month I uploaded a community sample that showed how to call an Amazon Web Services RESTful API, in particular for their S3 storage service.  That sample is contained within a single form, and is accompanied by some simple instructions and notes on assumptions made etc.  I used a form component type, and constructed it to use operations for the actual API calls, so that it would be easy to understand, and easy to modify to a service component, for wider usage.

The next thing I wanted to try was to provide the same functionality from a DSP.  Initially this could have meant replacing the Windows GUI layer with a HTML5 based layer in a DSP.  However, DSPs make the Uniface JavaScript API available, and thus there is an opportunity to try out the AWS SDK for JavaScript (in the Browser).  Information is available at http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/browser-intro.html .

The main advantage of using this SDK is that becomes possible to avoid a lot of low level coding with the RESTful API.  If you study the form sample I mentioned earlier, you will see a lot of code to build canonical requests, and then to sign them securely.  This is all buried inside the various SDKs that AWS provides.  This was worth a try!

As it turned out, coding the JavaScript to list the bucket contents, download and upload files, was relatively easy.  In particular, the feature to generate signed URLs for downloading files is very handy.  In fact most of the buttons on the sample DSP have browser side JavaScript which calls the AWS SDK without much reference to the Uniface JavaScript API.  This just means that in some circumstances you might not need to use DSPs at all, but if your use case does involve exchanging information with back-end processes, then this sample should be of interest.  One such use-case is to save S3 files on the back-end server, and so a JavaScript activate is done to send the signed URL to a DSP operation, to complete the download.  In any case, it is tidy to keep the JavaScript code in the Uniface repository as much as possible.

So … although the JavaScript coding turned out easy enough, the challenge turned out to be how to authenticate the SDK calls.  In the form sample I used the AWS Access Key ID and a Secret Access Key to sign requests.  These were quarantined from the form source code, and the runtime user (who shouldn’t have access to the Uniface debugger), by storing the sensitive data in assignment file logicals.  Not the ultimate form of protection, but adequate for my sample.  The JavaScript SDK requires access to these artifacts, and since this runs in the browser, it exposes them to all users.  To slightly obscure these private values, I placed them in a separate JavaScript file, which is not referred to in the HTML, but dynamically loaded by Uniface with this statement:  $webinfo(“JAVASCRIPT”) = “../js/aws_config.js” .  Of course you can read the variable contents with any browser debugger.  So this DSP sample comes with a similar caveat to the AWS recommendations.

The options for supplying credentials to the AWS JavaScript API are described here:   http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/browser-configuring.html .  So for my sample I did effectively supply hard-coded credentials for an IAM user that has read-only permissions.  Real applications will want a more secure method.  I was going to evaluate AWS Cognito, but it is not yet available in my region.  Another option to investigate is to use Temporary Security Credentials, via the AWS Security Token Service.  Further discussion on authenticating credentials is beyond the scope of this blog / sample.

One final security configuration had to be made, because the sample is running within a browser, which is likely to be enforcing CORS.  This is best explained in the documentation at http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/browser-configuring.html#Cross-Origin_Resource_Sharing__CORS_ .

To summarise, Uniface developers have a choice when integrating with AWS.  They can choose the RESTful APIs for lower level control, in a wider set of situations, or they can use the JavaScript SDK for easier integration when using the Uniface JavaScript API.

Uniface 64 bit deployment for Windows

During the deployment session from the Uniface Lectures, we covered Uniface 64 bit deployment for Windows in the morning session (not in the afternoon because it took to much time, the videos are available to watch on our YouTube channel though). 

We had a few really interesting questions, I’ve worked the answers into the text below and I dug up an old posting from the old Frontline site, and used that as the basis. 

The oldest Uniface PAM (Product Availability Matrix) I could find was from Uniface 6.1, and with that old version we  delivered 64 bit support on DEC Alpha hardware with Uniface 6.1. OpenVMS, and DEC Unix ports of Uniface. I remember seeing one of the DEC Unix workstations here in the Amsterdam Lab, running the Motif GUI and thinking how advanced it was, how fast it was and I wanted one. Always dangerous to wish for more, I ended up with a Mac on my desk a week later. 

For a number of releases we focused on Uniface server versions for 64 bit, think IBM AIX, HP-UX, Intel Titanium hardware and so forth.  

It was in 2012 that we delivered a 64 bit Windows server version, delivering it in Uniface 9.5.  

It took us a long time, and to be honest, I recall have a few conversations on the topic over the years, and from an out and out technical perspective, the view was that there were few perceived benefits when compared to the 32 bit version to justify the investment to make it happen. I should mention that we had done some clever things with compiler switches to enable memory addressing for a number of releases. 

A Windows 64 bit Uniface client was a different story, and was quite a significant project.  Clearly there were overlaps with the Windows Server (technically they share a lot of common source), but the GUI layer needed a lot of work. We had to refactor a lot of code, as we had a lot of legacy (technical debt) from older versions of Uniface. The name Uniface originated from Universal Interface, and it was possible to develop one Uniface app and deploy it on those old GUI platforms which we used to support thanks to the Uniface specific widgets such as the unifield.  (I’m sure some of us who have been around Uniface for a long time remembers Uniface on Mac, Motif, OS/2 and Windows 3.x.)  There was a lot of old code to clean up and/or remove, and we also have to keep those legacy widgets operational. 

A few additional challenges included our use of automated test tools which didn’t support 64 bit platforms, which also forced our journey to replace them and use Ranorex for our testing. (I’ve covered this in the forums and talked at a few user groups on this topic.)  

We delivered a Windows 64 bit client with Uniface 9.6 in December 2012. We’ve had some good feedback, I recall talking to a customer in the UK, and their comment was that it just seems more ‘fluid’. I talked about this with one of the architects, and the view is that this is probably as a result of the refactoring, possible the additional memory capabilities, but it’s great to get positive feedback. 

It’s available for deployment rather than development, as we have a few external pieces of functionality in the developer, for example the DSP Editor which are not available as a 64 bit product. 

The HTML control we delivered in Uniface 9.6 is also currently restricted to 32 bit. But this will change, it’s based on Chromium (sometimes know as CEF) from Google, and the sources were (finally) updated to 64 bit and we have been working on getting that into Uniface 9.7, and will be part of the Uniface 9.7.02 update which we are finalising. That was a challenge to get working, changes to threading models and API’s meant some rework and lots of testing, but it’s pretty well code complete. 

The Uniface 10 IDE uses that same HTML control extensively, so the move to CEF3, now opens the way to deliver a 64 bit developer. There will be a significant Uniface 10 release in September, but this is something for another posting next month.    

 

Uniface Modernization: Modern buttons are flat

New button properties are welcome

During the modernization of IDF 9.7 it became clear that 3D buttons could not be used anymore. Windows has gone flat and all the office applications as well. So we needed to address this with some simple properties on the command button widget. The defaults stay untouched even though the new properties make the button more appealing. So we don’t break the look and feel of the existing applications but open the possibilities to a modern user interface.

Properties explained

These new properties make the difference and allow the UNIFACE developer to change the looks of the entire application in a wink. You need to set the button representation to “UNIFACE” is you want to make use of the new properties.

Uniface

With the new properties we were able to completely mimic the Windows 8 tiles as well as the common flat buttons.

Some examples

In the following example the “Transparent” property is set while the button is placed on a form with a very colorful image. Not very user friendly, since it looks like a label, but it shows the possibilities.

A button with transparency set to TRUE.

Uniface

The following table shows a button with an image which is styled in different ways:

Uniface

New property value

Unifac

During the modernization of IDF we missed the option to create big buttons with an image big enough to fill up the button. The “imgsize” property has a new value to accommodate the workspace buttons in IDF.

Uniface

Example the UNIFACE Journey planner

If we start making changes to GUI widgets or the GUI driver, we always look to other applications and try to make the user interface in UNIFACE. For the buttons I took the Android application made by the Dutch national railway company NS. With the new button properties we could mimic the user interface completely. Following picture shows the UNIFACE Journey planner which uses flat buttons.

Uniface

To make designing the application more easy, I created logical widgets with the necessary properties, so I was able to paint the Journey planner very quickly. Creating the logical widgets was some work but after this you can develop an application following a certain theme. You can paste the following buttons into you usys.ini to get the looks as shown in the sample.

pltimebutton=ucmdbutton(representation=uniface;transparency=true;forecolor=white;frametype=bottom;framecolor=#9bd1f3;framewidth=2;font=SansLarge)

plheadbutton=ucmdbutton(representation=uniface;backcolor=#ffcc33;transparency=false;forecolor=black;frametype=bottom;framecolor
=#dcab1e;framewidth=5;font=SansHuge)

plplanbutton=ucmdbutton(representation=uniface;backcolor=#3395e4;transparency=false;forecolor=white;frametype=bottom;framecolor
=#1762cc;framewidth=5;font=SansHuge)

pldepariv=ucmdbutton(representation=uniface;backcolor=#1b8ee1;backcolorhover=#349ae5;backcolorfocus=#349ae5;transparency=false;
forecolor=white;frametype=bottom;framecolor=#9bd1f3;framewidth=4;font=SansHuge)

pldfromto=ucmdbutton(representation=uniface;backcolor=white;backcolorhover=#349ae5;backcolorfocus=#349ae5;transparency=false;
forecolor=#272775;frametype=off;framecolor=;framewidth=1;font=SansHuge;imgsize=img_xlarge;halign=left)

I hope this helps you in creating modern looking UNIFACE applications and modernizing existing applications.