Category Archives: Blog

Structs: More than just an easy way to process XML streams


During the sixties of the previous century IBM’s Charles Goldfarb et al. developed, what can be considered now, as the first Markup Language. From his Generalized Markup Language (GML) the more generally known Standard Generalized Markup Language SGML was developed.  Several criteria were defined for this SGML. One of these criteria is that SGML should describe a structure and attributes. By describing it this way it was (and is) much more likely that data can be processed, using (future) information technologies. SGML was designed to process huge documents, initially used by the US government. SGML was often experienced as quite complex and the advent of XML-structured data made it possible to use the concept of structured data for smaller documents as well.

Nowadays XML is indispensable in information technology. XML (and its “mutants” like JSON) can be considered as the “de facto” standard for data communication between applications, using web services and more. In multi-tiered architectures XML should be used for data communication. Each development tool must be able to process XML-like data streams as efficient as possible. Considering XML strings as a “simple” string data type is far too easy to process XML streams in a fast and development-friendly way.

Initially Uniface defined scripting code (formerly known as Proc) that was geared towards the processing of XML. Scripting commands like XMLsave(to place component data in an XML stream) and XMLload (to load data from an XML stream into a component)  are good examples of this kind of scripting code. With the fact that the “data world” was getting more and more complex, these simple statements no longer covered the need for efficient coding. Many Uniface developers used string manipulation coding to process more complex data structures like XML and JSON.

A new paradigm was needed for Uniface to process XML, to stay on top of being (and staying) the number one productivity development tool. With Uniface 9.5 and 9.6 the implementation of the Struct datatype, in combination with the development of scripting code to manipulate Struct datatype variables and parameters (ie “Struct”), was the answer.  A Struct can be defined as a tree-like data structure, kept in memory, that is used to dynamically manipulate complex data and transform it from or to XML or Uniface component data. Variables of type struct are used to access the Struct. Scripting code commands, access operators, and information functions enables the developers to create, build, and manipulate the Struct.

The application of Struct, initially designed to process complex and structured data, has many more options. The creativity of the Uniface software developer is the limit for the application of Structs.  Here is a short list of applications for Struct. The list is just a limited one and without any doubt there are many more applications for Structs.

  • There is complex parameter support of web services and transformations of SOAP messages. All XML strings can, with only one statement, being transformed into a Struct. Struct can be transformed into component data, after some manipulation, if needed.
  • The processing of entities and multiple occurrences has been made much easier and faster. Component data can be transformed into Struct with one command. Because Struct is kept in memory manipulation of is very fast.
  • Software development according to the “multi-tier” paradigm is more straight-forward now. In a well-developed software application communication between the different tiers will be handled using XML, JSON or another XML-like data format. The transformation from component data into Struct is a very simple one.
  • Exchange of JavaScript objects is no longer a serious issue. Uniface has a JavaScript API to enable the development of client-side code for web-deployed applications. JavaScript uses JSON strings for data exchange a lot. Uniface supports the transformation between JSON and Struct. Easy to apply this on communication between a browser-based presentation tier and its server-based back end.
  • Uniface lists can be replaced by the use of Structs. Uniface developers that have developed Uniface list into list (into lists into lists… and so on) know that it can be very complicated and hazardous, using “goldkey ;” and goldkey !” for the lists inside lists definitions. Structs make live much easier.
  • Complex data exchange between entries, operations, and components can be implemented. Both parameters and variables are supported by the struct datatype. Using parameters makes it possible to exchange Struct to-and-from entries, local operations and public operations.


This was only a limited bulleted list of possibilities that the newly developed Struct data type offers the Uniface developer with Uniface 9.6. I am very convinced that there are many more creative applications for Structs, please show me!

Using Standard Deployment for your Uniface Applications

Author: Michel van den Berg, Uniface Software Architect

Deploying your Uniface applications with standard deployment is a methodology that can perhaps make your life easier. With the classic style of deployment, rolling out your application is not always that straight forward. The following graphic shows this, .dol and .urr files are shared over the components, making it difficult to structure.

Classic Style

With Uniface Standard Deployment, the runtime environment will be different, all objects are delivered in single or a small set of  archives.  This of course brings many benefits, such as easier application distribution, updates and partitioning. No more .dol’s or .urr’s files getting mixed together over applications.


To help you get started with using Standard Deployment for your Uniface applications, join this online seminar that will show you the overview of the functionality so you can learn how to move from classic to standardized deployment style.  Registration is open, hope to see you there on January 7th.

There May be Trouble Ahead for Mobile Commerce

By Clive Howard, Principal AnalystCreative Intellect Consulting

With the Christmas holidays just ahead of us there will undoubtedly be new figures showing that e-commerce has once again generated more revenue and accounted for more of the holiday spending than ever before. The same figures will also probably show a rise in the amount that was spent via mobile. M-commerce (mobile e-commerce) has been steadily rising for a number of years and most predictions are that it will continue to do so.

However recent data points to a tapering off of growth in M-commerce over the next few years. This could be significant with growth rates barely rising at all by 2017 and stagnating at around 30+% of total e-commerce spend. The key questions for many organisations should be however, why and how can they potentially buck this trend?

A number of recent surveys by eMarketer show that there are two key reasons why people are growing reluctant to buy online using mobile devices. The first is security and the second is the user experience of mobile transactions.

Consumers don’t have faith in the phone…

The security issue is a significant one and is only becoming more so. With recent high profile breaches such as that of iCloud (although not Apple’s fault) and Target stores in the US, consumers are becoming increasingly aware and concerned about security online. This is accentuated when it comes to smartphones. They are right to express concerns as the last year has seen 167% increase in mobile malware with McAfee estimating 200 threats per minute.

The Android operating system which is installed on 80% of all smartphones shipped has been especially susceptible to such attacks. Some figures put “rooted” Android devices at 20% of the total. A rooted device gives rogue agents potential access to data stores on the device with the ability of data being entered into device or being passed to and from the device.

Google is addressing these issues and Android is not the only mobile operating system to suffer from security challenges. For example, Apple’s much touted fingerprint recognition sensor was cracked shortly after launch.

Technology has responded to try and address these concerns. For example, mobile wallets (such as ApplePay, Google Wallet and PayPal) try to avoid the need to input and store payment data on the device. Apple’s latest ApplePay mobile wallet does not store credit card data either on the phone or in the cloud. Instead an alternate version of the credit card information is stored in a secure element on the phone.

If there is a breach, such as a lost device, then the payment information can be cancelled without cancelling the credit card itself. Mobile wallets which also work in conjunction with physical payment mechanism such as Near Field Communication (NFC) where you only need to put your mobile device in close proximity of the payment terminal are widely seen as the future of mobile payment.

When they don’t even trust the technology leaders in mobile payment…who do they trust?

The challenge is that data shows people do not trust most of the mobile wallet providers. Apple, Google and even PayPal are only trusted by approximately 20+% of consumers according to eMarketer. So while the technology addresses the security challenges the consumer is less likely to put their faith in it.

Surprisingly this issue cannot be put down to age. People in the 25-35 bracket are more likely to try a mobile wallet than those in the 16-24 age group. Some of this might be down to available income but younger generations often show greater awareness of security issues and therefore more likely to take precautions such as not using them.

When asked who they would trust with regards to mobile wallets almost 80% of consumers answer banks or credit card companies. These organisations are now starting to enter into this market. Therefore development teams should start looking into mobile wallets, particularly those provided by banks, as a method for taking payment on mobile devices.

Mobile payments are simply too hard

After security the next significant issue that is deterring users is the experience of paying via mobile. This is especially relevant to smartphones. In a recent survey IBM found that while consumers use smartphones to research purchases far more than tablets, the reverse is true when it comes to actually making a purchase. A clear reason for this is the difference in the form factors, in other words tablets are larger devices than smartphones.

I’m sure that we have all tried entering data using a smartphone and have probably found it difficult. The small screen size often combined with touch keyboards make entering any significant data awkward. When it comes to making payments in the traditional way, using a credit card, the amount of data that needs entering is a lot. There is not just the card information which includes the long number but also address information. In total this process often involves a combination of character entry and drop down list selections.

With websites this can be particularly problematic where they do not correctly fit within the confines of a small screen. Surprisingly even some websites optimised for mobile do not fit all screens. Then there can be the issue of the underlying code, especially the use of JavaScript which can sometimes not work as expected within mobile browsers. In a Jumio survey, 23% of people reported having a transaction fail to go through on mobile. This represents some kind of technical problems affecting mobile.

This is not surprising as there are a large number of different devices available running a number of different versions of operating systems. In many cases these operating systems have been customised by handset manufacturers of telco networks. In addition there are new devices and updates to operating systems becoming available very regularly. The result is a very large number of potential environments. Testing all of these is near impossible and many organisations only test on the most popular according market statistics.

Such problems with the experience of making a payment leads customers to lose trust, which in turns raises even greater concerns over security.

The Mobile Mind-Shift: The End of Apps as we Know Them?

Mobile apps have become ubiquitous. Companies are trying to get to grips with an unprecedented digital transformation and keep up with the resulting changes in consumer behaviour. There are now more than 1 billion smartphones and hundreds of millions of tablets in use across the globe, so having a mobile app strategy is essential for success in the connected world.

But, Josh Bernhoff of Forrester, argues that, a strategy that involves ‘building an app’ by itself is no better than a strategy that involves porting a web site. The real question is – what is the app going to do for the customer?

We’ve entered a time when consumers have made a ‘mobile mind-shift’, that is, they expect to access what they want, in a relevant context, in a moment of need.

Bernhoff writes, that for app designers, the challenge is to think about the points in time and space when someone pulls out a mobile device to access information relating to their immediate circumstance. Companies need to prepare for the ‘mobile mind-shift’ because it will change what customers expect and demand of an organization.

From a design perspective, Paul Adams, of Intercom, writes that, “The experience of our primary mobile screen being a bank of app icons that lead to independent destinations is dying”. The consequence of this is that it will change what we need to design and build.

He suggests that in the future, the primary interface for interacting with apps may not be the app itself. The app is primarily a publishing tool so the number one way people will use your app is through an interactive notification layer or aggregated card stream, not by opening the app itself.

But will apps disappear completely? Where apps might survive and thrive is in creating useful and contextually specific information for end users. We will still need apps to process data to present complex information in a functional and contextual format to the end user.

Where these apps will live on our mobile devices in the future is definitely open to change. According to Paul Adams, they may sit in the back-end, pushing content into a central experience with a card based notification center taking precedence.

Recently, at our North American user conference in Las Vegas, we detailed our mobile strategy to create cross platform mobile applications. Our strategy will help address the current opportunities and challenges of developing mobile apps.

What kind of future do you see for mobile apps? Will they become obsolete or do they just need to reconfigure their purpose? If you have an opinion on what the‘mobile mind-shift’ means for the future development of mobile apps, tell us about it!

Uniface deployment currency survey – a few weeks in

Hopefully you’re all aware of the Uniface application deployment currency survey which we sent out a few weeks ago. After a few weeks, we’ve had a good number of responses (over 100), and I was asked a few times what the results are looking like, so I thought I’d share some details.

From a platform/OS perspective, the top platforms which Uniface customers are using,  are Windows and Linux, which doesn’t really surprise me, as this is the feedback I get, based on what I get in regards to requests, tech support calls and so on. They are also the platforms we usually deliver maintenance by default.

Uniface Platforms Currently in use. (Nov 2014)
Uniface Platforms Currently in use. (Nov 2014)
  • And from a database perspective, there were a few surprises.
    Some are using PostgreSQL, although we’ve not even start the development of a native driver, it’s planned for the new year.
  • ODBC is being used more than I expected.
  • Sybase is being used more than expected.

I expected the majority of Uniface apps to be deployed with Oracle, MS SQL Server and MySQL, which seems to be the case.

Uniface deployment databases currently in use. (Nov 2014)
Uniface deployment databases currently in use. (Nov 2014)

Finally, there does seem to be interest in NoSQL databases, which is really interesting, we will be following up on that in the future.

I will share some more at a later date.

And if you click on the graphics, they will zoom (a good Uniface term!) and they are more readable!