Category Archives: Blog

Inheritance: Why Uniface 10 will save developers a lot of time

As many of you may be aware, we have – for some time – been working on the new version of Uniface, v10. As befits a major version increment, there are quite a few changes in the development environment, as well as to some of the concepts of Uniface. Today I would like to describe one such change, that should help to make development more obvious.

Inheritance, from model to component, has always been a cornerstone of developing an application with Uniface. The model contains the global definition and the component the external variation, the external variation taking a higher precedence over the model when coming to compile. Let’s examine this concept in a little more detail in the area of local procs.

Imagine, if you will, that when using version 9 you have entries defined in the Local Procs Module trigger of a modelled field, and that the field is painted on a component. When you compile and run the component, any calls you have made to the local proc will cause you to execute the entry defined in the model. Now, if you were to create an external variation of the proc and run the component again, you would expect external variation to be used. So given this, the external variation wins out over modelled procs, right? Well, no, not quite! If I were to now paint a new modelled field with yet another version of the local proc defined and lower down the compile order of the component, what happens could be seen as unexpected – the modelled proc of the second field would be used. If the order of compile changes, i.e. the second entity is moved on the component paint tableau, the module that is used could change. This was not the intended behavior.

In version 10 the process has been made much easier to understand – the external variation always takes precedence. All model definitions are compiled before the external variations are overlaid. This change will mean that the compilation becomes far more predictable with less “magic” and mistakes.

There has been another improvement in compilation of local procs – they are now overlaid. Prior to version 10 you could have, in the model, many entries defined in a single trigger, and if you wished to make a change to just one of them in the component, you would have to break inheritance to them all. Effectively, you would duplicate your code into each component where this was the case. Although it is possible to simulate the inheritance using included procs, it can take quite a bit of planning to implement. With version 10 you are now able to overlay just a single proc module, leaving the inheritance for all others.

So how does this look in the component editor of version 10? The first thing you will see is that only the external variation code is displayed, not the modelled code. To enable easy navigation to all the code compiled into the component, a Compiled Module Information (CMI) panel has been added to the editor. It shows all modules compiled into the component. Double clicking on a module in the CMI causes a navigation action and you will be taken to to the definition of the code module – opening a new editor (entity, included proc, etc.) if required. This is a big time saver for the developer.

Uniface and GitHub–Getting Started

We hope you have had a chance to browse around the Uniface samples on GitHub. This blog post will give you some background information and some useful tips for getting started.

Objectives of Using GitHub:

  1. Provide an open public globally accessible area for Uniface code samples and examples
  2. Theme focused
  3. Encourage participation in Uniface projects
  4. Ease configuration and setup of Uniface and Uniface examples

Globally Accessible

We are using GitHub.com to host our publically available repositories.

In using GitHub.com as the code hosting platform you have the opportunity to work with project authors and on your own projects from anywhere. The GitHub platform is widely adopted, very well understood including many samples and guides (https://guides.github.com/activities/hello-world/) and has a variety of tooling on various platforms to interface with the repositories.

How to get to the Repositories

You can obtain access to the projects by navigating to the GitHub Uniface page https://github.com/uniface  and select a Repository. In this example I chose the Project-Startup repository. Once selected the following page will appear:

Uniface GitHub

Click on: GitHub2

Uniface GitHub

If you choose ‘Open in Desktop’ it will attempt to use ‘GitHub Desktop’ available here : https://desktop.github.com/. Alternatively, you can just select ‘Download ZIP’ to download an archive of the project, extract and use as a sample.

Theme Focused

We have created a series of Repositories that include:

Project Startup Basic project structure with support for the Project Setup Tool.
Development Tooling Tooling to support development with Uniface including:

·       Uniface Meta Tools

·       Project Setup Tool

·       Signature Wizard

·       Version Control setup

User Interface User interface implementations:

·       Outlook UI

·       Uniface Tunes (uTunes)

·       Manipulating Windows specific functionality

Integration Uniface Integrations:

·       Utilizing 3GL in Uniface

·       Implementing a REST Api

·       Calling REST

·       Dropbox

·       Sharing data across Windows Applications

·       Interfacing with a GeoIPDB

Mobile The Uniface uClaim application
Product Usage Detailed usage of:

·       Structs

·       Using POSTMESSAGE across your applications

Web Uniface web basics:

·       Charting

·       Promises

·       Security

·       Basic web framework

Encourage Participation

In utilizing GitHub you have the opportunity to FORK( https://help.github.com/articles/fork-a-repo/) the project or projects and add their functionality or techniques to your own project. Additionally, you can request that your additions/changes be incorporated into the master. There is no guarantee that your changes will be accepted, just like every other open-source initiative.

Simple setup and execution

Those Uniface projects that require some basic setup utilize the Project Setup Tool to configure the application for your environment, importing sources, creating shortcuts and compiling the application.

Conclusion

While no attempt is made to provide detailed instructions for using Git and GitHub there are numerous sites that provide instructions and tooling on how to use Git and GitHub. Please take advantage of those resources. As this is the beginning of this initiative please feel free to comment and make suggestions.

 

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.

Windows XP – another nail in the Coffin

I recently read this article about Chrome 50 stopping support for some older operating systems, and the mention of Windows XP caught my eye. 

From a Uniface perspective, we stopped supporting Windows XP in May 2014. Purely from a technology perspective, it freed us up in regards to choices on MS Visual Studio and even how to implement certain functionality. I’m sure in the Uniface source code there is still code that states ‘if Windows XP’…! 

Getting out and about, talking to customers, I’ve had a few conversations about Windows XP, mainly in the context of browser support and Internet Explorer 7, as in the big WWW, it’s pretty well out of control what OS, and what browser an end user can use. (Although I do remember this article about an Australian online retailer who was going to add an IE tax for their transactions.) 

Something that has come up during conversations has been customers who are doing business in China, where there is still a significant amount of Windows XP use. I’m assuming that this is related to how easy it was to bypass the MS licensing model and the availability of older specification hardware which might struggle to run a new version of Windows. 

I’m expecting that with Chrome soon to stop supporting IE, that will start to accelerate the move away from Windows XP, and I’m guessing some of the hardware manufacturers will be rubbing their hands with the anticipation of a peak in new hardware sales, and the recyclers are preparing for more obsolete hardware to be stripped for precious metals. 

And on a personal note, it appears I need to buy a new Mac for use at home, as I’m also impacted by Chrome 50 not supporting my version of Mac OSX! 

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.