Tag Archives: DSP

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. 

 

When is the best time to plant a tree?

When is the best time to plant a tree? According to a Chinese proverb it’s 20 years ago. The second best time is now.

As Uniface developers we know this is true. Most applications written in Uniface originate from 20 years ago. And they are still alive and kicking. Well, I am not sure about the kicking part, but they are certainly alive. But I want to build new applications today. I am sure we all want to.

In previous blog posts I told you about my worries. Some of you replied, or sent me an email. Thanks for that! You told me about these frameworks that existed in the mid-nineties. A good and sound framework is an essential building block 🙂 for fast application development. It’s the foundation of applications, but why should we invent the wheel over and over again? I would rather spend my energy on programming algorithms and code business logic.

But let’s be honest, we need more. I mean more frameworks that can be used to build mobile applications or at least fully responsive web applications with DSP’s.

There are hundreds or thousands of excellent Uniface developers out there. And we need a working space where we can meet and join forces. What if such a place would exist? Where we could create nice tools, examples, pieces of proc code or even a complete framework? Wouldn’t that be great! Let’s join forces and start a new community and have this working space. Interested? I have a plan….

Community

I want to organize a new Uniface developers community. The goal of this community is to build, maintain and share Uniface components. And I am searching for developers to participate. A few assumptions:

  • Let’s start small, with a few developers. Not more than a dozen.
  • It’s an online community, so it doesn’t matter where you live, work or which timezone you’re in.
  • We will communicate in English. My English is not the best, but I try. I am sure we all can.
  • The community and the products are independent. So, the software we create or documents we write are owned by the community.
  • Participation is on a personal basis. So you don’t represent your employer. Not even when it’s Uniface. 🙂
  • Everything we create, we will share for free and is open source. I will write a post about open source in the near future. Because it’s not what we are used to…
  • Last but not least. We will work independently and local most of the time. But a community is about teamspirit. Especially in the beginning. We don’t have to be friends, but we need to respect each other’s opinion.

Rocket science

The community is going to build Uniface components. Of course I am talking about Uniface 10. We will start with some nice examples. That’s also the best to get used to the environment.

All of us know how to build nice applications with Uniface. I don’t know if you have any experience with version control, creating mobile apps or Uniface 10. But I am sure community based development is new for us all. So, at certain points it’s going to be trial and error.

Before we can build anything we need to setup an entire environment where we can work together. Think about the architecture inside your development department, but then completely online.

There is already a complete online environment. All that is missing, is you!

Want to participate? Please send me an email (lammersma@hotmail.com). Don’t worry about the technical stuff. It will be explained to you!

 

Using Palettes and Templates in Uniface 10

You may have seen and experienced quite a number of the advancements in the Uniface 10 product. I presented a Uniface 10 Deep Dive discussing the following:

  • Development objects
  • Containers (vs triggers)
  • Bulk activities
  • Drag and drop
  • Properties inspector
  • Viewable inheritance of ProcScript
  • Modelled components and properties.

Uniface 10 also introduces palettes, templates and snippets:

  • Palettes are development objects that can contain templates of objects and libraries of snippets.
  • Snippets can contain text, complex HTML and JavaScript as well as ProcScript.

Palettes and templates provide a formal mechanism to capture your organization’s standards and leverage your existing expertise in both business logic and presentation technology. Practices such as defining field characteristics and behavior can now be encapsulated into a single development object and dropped onto a structure. This greatly increases your productivity as a developer.

Rather than discussing palettes and templates it probably makes more sense to show exactly what can be done with them. I have put together a small workshop that walks you through, step-by-step the process of creating a palette, creating some templates and snippets and then using them to build some samples. The workshop will help you create Windows Forms components, Bootstrap based DSP’s and a sample RESTful implementation that can then be shared internally or to the community.

Uniface 10 Templates & Palettes
Uniface 10 Templates & Palettes

This and all subsequent materials will be posted in the Uniface Git repositories. This is the place where you can find new and interesting Uniface functionality but also and more importantly contribute to the Uniface community.

The workshop and its supporting materials are located at https://github.com/uniface/UF10_Palettes

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 web workshops, closing the generation gap

In March and April this year, a new initiative–the Uniface Plusprogram ran in the Amsterdam Uniface Lab. The Plusprogram originated from the Benelux user group Face to Face to deliver Uniface / Web workshops for Uniface developers. A special so-called PlusMembership allows Face to Face members to participate in the program which consisted of two parts:

  • HTML5 CSS3 and Javascript concepts
  • Uniface web components like HTML5 widget and Uniface Dynamic Server pages

The workshops were given 8 weeks in a row on Tuesday and Thursday evenings from 5:30 PM unitil 9:00 PM including a “light” Pizza or Sandwich dinner. Participants could choose to go on Tuesday or Thursday as the content for each evening was the same.

Tons blog

Five evenings were all about Web basics and the latest and greatest in HTML5/CSS3 and Javascript technology. These workshops were done by a young Master in Computer Science (Tim–who also happens to be my son) and has a lot of both hands-on as well as theoretical web knowledge. During those evenings it was very nice to watch a 24 year old teaching a class room full of very experienced Uniface developers Modern Deployment using Git.  Looking at the evaluation we held afterwards, the students very much appreciated and learned a lot from these sessions. Every evening consisted of 90 minutes theory, 60 minutes “hands-on” and a quiz. Having a quiz at the end of each session is quite common for Web trainings these days, but for most of the students is was pretty new. I think this a little “generation gap” between a “raised with gaming and Google generation” and a more traditional “schoolbook” generation.

Tons blog 2

The final Web Workshop evening explained modern Javascript libraries like Node.js and NoSQL databases like Mongodb. The other 3 evenings were given by Uniface consultants and developers and explained the concepts of the new Uniface HTML5 widget, DSPs and responsive Web programming which is a “must have” for deployment of Mobile Websites. These workshops showed that Uniface already has many possibilities to use the Web technologies which were showed in the first part of the program. The PlusProgram was very successful. During the 8 weeks over 90% of the participants showed up and we also got requests from other countries to organize the same program locally. For now we are almost ready to organize the same program in Belgium after the summer holidays.  For other countries we will determine on a case by case basis if/when/how the program will be presented. If you have any questions about the Plusprogram please feel free to contact me!