Tag Archives: javaScript

Keeping up-to-date: Mobile security & Native UI

To catch-up on the latest mobile security and native UI trends, the Uniface mobile development team recently attended the appDevcon conference. A conference by app developers, for app developers. An event which targets developers for Apple iOS and Google Android, Windows, Web, TV and IoT devices in multiple tracks.

In advance, we were especially interested in two main topics: smartphone security and sharing code between web and native apps.

Mobile security

The mobile security presentations were given by Daniel Zucker, a software engineer manager at Google, and Jan-Felix Schmakeit, an Android engineer also at Google. In their – in my view – impressive presentation, they confirmed what I already thought: securing mobile phones is not something which you do after you have designed and developed your apps. It is a key area of app development to consider in advance.

Securing mobile phones starts with a good understanding of the architecture of at least the Android and iOS platforms. How is it built up? For example, as Android is based on the Linux kernel, you get all the Linux security artefacts, like Process isolation, SELinux, verified boot and cryptography. While some security services provided to mobile apps have a platform specific nature, others are platform independent.  An example of the first one is the new Android Permissions, which have now become more transparent to users, as they now get permission requests ‘in context’. An example of the platform independent security artefacts is the certificate validation, which done in an incorrect way, would still make your app vulnerable.

Native UI

Sharing code between native and web apps promised to be an interesting session. Some context: mobile users tend to spend significant more time on native UI enriched apps than on web apps, while web apps are attracting more unique visitors than native apps, as web apps are more widely approachable using different devices.

The best way to share code between native and web apps is simply by writing them as much as possible in the same code. Of course! But how do you do that? In this session the solution was to write fully native apps using a mix of NativeScript (an open-source framework to develop apps on iOS and Android platforms) and AngularJS (JavaScript-based open-source front-end web application framework). These native apps are built using platform agnostic programming languages such as JavaScript or TypeScript. They result in fully native Apps, which use the same APIs as if they were developed in Xcode or Android Studio. That is quite interesting! So using JavaScript you can develop fully native apps. That sounds like music to my ears.

Looking at this trend, it promises a lot. The mobile community seems to put a lot of effort in trying to simplify the creation of fully native enriched apps using plain JavaScript and HTML5 functionalities. Until now, we support our users in creating native/hybrid apps with fully native functionality with our Dynamic Server Page (DSP) technology. As we are looking into ways to enrich this technology further, we will follow the developments on this trend as it is fully in-line with our philosophy to share code between applications (client-server, web and mobile apps) and to support rapid application development, which saves our users time and resources in developing and maintaining fully enriched and cool applications. 


HTML5, Javascript and CSS3 training videos for Uniface developers on Uniface.info

The Web capabilities of Uniface have increased year over year. At the moment there are at least six different architectures to integrate Web technology in Uniface or build full Web applications in Uniface.  The HTML5 Widget, Uniface Anywhere and DSPs are obvious examples. In an upcoming blog post, I will go into more detail comparing all options.

Developing modern enterprise applications also requires more Web knowledge for Uniface Developers.

To facilitate this we made a special series of training videos on Web topics for Uniface developers. This series is available on Uniface.info and consists of Introduction and Advanced videos on HTML5, Javascript and CSS3.

The Introduction videos assume zero existing knowledge of the technology. The Advanced Topics can be played in any order and assume the Introduction as pre-requisite. Some videos come with demo material which is available as a download.

To make it easy, I’ve listed all the available videos:


Hello World:  http://unifaceinfo.com/html-hello-world/

This session is an introduction to the Hyper Text Markup Language (HTML). We will be creating our first website and use a couple of HTML elements to display some simple text and an image.

Introduction: http://unifaceinfo.com/html5-introduction/

This session discusses the basics of HTML5. It introduces a lot of new HTML elements to give a clear structure to your website. Why are semantics are important?

Canvas: http://unifaceinfo.com/html5-canvas/

This session discusses the HTML5 canvas. We’ll create a simple Uniface graphic by ourselves, and have a look at some more complex examples.

SVG & Multimedia: http://unifaceinfo.com/html5-svg-multimedia/

This session is all about the HTML5 SVG, audio and video elements. We’ll discuss the differences between a Canvas and SVG, and see how we can incorporate a video and mp3 without using Flash or third party libraries.

Geolocation & Storage: http://unifaceinfo.com/html5-geolocation-storage/

This session is about using getCurrentPosition() to obtain the GPS coordinates of the user. Afterwards we’ll store this information in the localStorage object so it is remembered.


Introduction 1: http://unifaceinfo.com/javascript-introduction/

This session is an introduction to JavaScript. Its main characteristics will be discussed, and we will be looking at an example. Moreover we will have a quick glance at its connection with HTML.

Introduction 2: http://unifaceinfo.com/javascript-introduction-ii/

This session is part II of the introduction JavaScript session. We will be looking at some more useful functions, types, objects and arrays.

D3: http://unifaceinfo.com/javascript-d3/

This is a short session about D3. We’ll discuss some use cases and see how it works through the use of some examples. 

JSON: http://unifaceinfo.com/javascript-json/

This is a short session about JSON. We’ll quickly see what it is, how it works, and how you can actually use it.

Advanced Javascript: http://unifaceinfo.com/javascript-advanced/

This is an in-depth session about JavaScript. We’ll go through different ways of using events, and see how the only option of executing things in parallel in Javascript is using callbacks.



Introduction: http://unifaceinfo.com/css-introduction/

In this session we’ll explore the new possibilities of CSS3. It provides a lot of new features that make the life of the developer and designer a lot easier.

Advanced CSS3: http://unifaceinfo.com/css3-advanced/

This is a follow-up of the CSS3 – Introduction session. Transformations allow you to modify the appearance of any HTML to your liking. Be it rotated, translated or skewed. Transformations and animations make HTML elements move around and respond to events.

If you have a question about any of the videos just open a topic on the forum.


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 9.7 WEB: When business rules

Guest contributor Dino Seelig (Uniface Business Partner) talks about his first impressions of Uniface 9.7

Last week I visited the Uniface Lab. The goal: getting informed about connecting WEB apps using Uniface DSP’s.

Building an app, using an off the shelf frame-work, integrating the power of Uniface service was for me a wish for many many years.

Communicating from a WEB app with a Uniface server using a HTTP request was not that hard, but something simple like: “leaving this field validate of the value of this field is a valid key” was still a lot of work. Setup an event listener, pickup the event fired, post an request over HTTP, handle the response, and so on.

With the introduction of Uniface 9.7 the javascript library Uniface.js simplifies the number of actions. The Uniface 9.7 way: create using javascript a new instance of your Uniface component, activate your operation using params and get your result makes life easy. The power available in Uniface Client/Server becomes now a part the web environment. Not bad. Implementing requirements like “can you calculate the sum? can you switch value when? can you hide show when?” are not time consuming anymore.

Is that all? No there is more. The lab switched from promise driven to quality driven delivery. In the past, the timebox (4 months) was used for to deliver the communicated promises. However the time box is not changed. The vision is. They will spend the time needed to make it excellent. That for me is the best promise to move to 9.7. Uniface is back on track simplifying complex things and shorten the time to delivery again.

Dino Seelig

Dino Seelig
Dino Seelig


Yow Connected Mobile and IoT Conference Report

The YOW Connected conference was held in Melbourne on 17th to 18th September http://connected.yowconference.com.au/ . It was a developer’s conference based on Mobile and IoT topics. Since Uniface is adding Mobile devices as a deployment option in 9.7, I thought I should find out what problems existing and aspiring mobile application developers are experiencing, and how they are solving them.

Keynote presentations should give a buzz to the audience, and this conference had one on the magic of mobile devices, with plenty of Harry Potter analogies. Another keynote was on IoT wearables, which showed many examples of how technology failed to make good partners with fashion.

The technical presentations for smart phones generally fell into iOS and Android camps, i.e. native app development was very important to most attendees. There was a strong belief in maximising the user experience over portability of business applications, and this meant gaining the most out of native platform features. Indeed, whilst people figure what to do with Apple watches and Galaxy gear, I can imagine that they need to use native platform features.

Given that there was strong commitment to native mobile development, it came as little surprise that using JavaScript to program the user experience was seen as second rate technology. However, when an industry heavyweight like Facebook come along with a new JavaScript library, people start to overlook their general JavaScript prejudice. So this is where I first learnt of the React library http://facebook.github.io/react/index.html . React differentiates itself from other JS libraries with the use of a virtual DOM. Your JS programming updates the virtual DOM, and then these updates are combined to update the real browser DOM. This turns out to perform much better than scanning and updating the browser DOM for each individual update.

But Wait, Facebook has done more … they have also introduced React Native https://facebook.github.io/react-native/ . So, instead of using JS to manipulate HTML for rendering inside a UIWebView container, you use JS to manipulate view structures inside native components. There is still a virtual DOM equivalent, and then the actual native component objects are updated by this library. Facebook has initially developed this with iOS native component models, and thus you are limited to developing on an Apple platform, but as recently as one month ago, you could also target the Android native platform.

This is where the development philosophy gets interesting. In the Uniface world we are used to “write once, deploy anywhere”, and there is a suggestion that React Native might support something similar, but in fact their mantra is “learn once, write anywhere”. Even though React Native has adopted standardized layout mechanisms from CSS3 using flexboxes, they really encourage you to choose native component types that exploit the best of what the native platform offers, i.e. avoiding a lowest common denominator user experience, at the expense of full portability and productivity. My personal view is that you would only choose React Native when user experience is clearly a very high priority, and use more proven platform independent tools, like Cordova, as often as possible. Perhaps this would change as React Native evolves, after all, it is still at release 0.11.0.

There were numerous IoT technical presentations, and I include Virtual Reality and Augmented Reality apps in this category. The presentations covered things like how to make a LED flash on a microprocessor (see https://www.particle.io/prototype for examples) using calls to the Particle Cloud written in JavaScript (groans from the smart device developers, but IoT developers don’t mind). Another presentation covered VR from high-end Oculus products to DIY Google Cardboard, once more, using JavaScript to program the API calls. This article shows the basic JavaScript libraries that you can practice with http://www.sitepoint.com/bringing-vr-to-web-google-cardboard-three-js/ .

I did initially struggle to see why these IoT technologies would be important to business applications, and thus where Uniface might be able to help, but eventually the spirit of adventure in programming comes out of you (OK, call it inner geekiness) and you want to play with it anyway. Besides, we know that other IT technologies have evolved from past experimentation, and so I wasn’t surprised to find myself ordering a Google Cardboard device on the weekend https://www.google.com/get/cardboard/get-cardboard/ . Soon enough, I may be using the Uniface JavaScript API, to send data to 3D rendering JavaScript libraries, for display in my Google Cardboard device.