Category Archives: Blog

10 things you need to know about Uniface 10

Working on a product like Uniface 10 feels a bit like the movie Oceans Eleven. A team of highly skilled professionals get together to pull off a feat that is considered undoable, or at least quite difficult to achieve. In fact there are quite a few similarities between the teams working in Amsterdam and the guys in the movie (Although me being Brad Pitt isn’t one of them, apparently). For instance the team working on Uniface 10 consists of people, each with his or her own unique skill set, working towards a common goal. There are lead-characters and supporting cast and everything.

But enough about us, what about Uniface 10? The first thing you will probably notice, besides the fresh white paint instead of the dull gray, is the UBAR, an explorer-type address bar that lets you open your editors. The other thing that jumps from the screen is the tabstrip. A horizontal ribbon bar showing all the open editors, allowing you to switch easily between entity, component, and other UDO’s.

A UDO, short for Uniface Development Object, is something we use in the lab to indicate a Uniface element (entity, field, component, library, and so on). These UDO’s come in two distinct flavors – UDO’s and main UDO’s. The difference? Main UDO’s have their own editor.

Before you can start creating these UDO objects you need to create a project (also a UDO). In my mind one of the better features of Uniface 10 is the ability to organize your work in… well projects. Something I really hated doing was having to verify that all my changes were compiled. Sometimes I would just compile all from the command line (not an option if the application contains over a 1000 components). Just put everything in a project and hit compile. It is even possible to export the entire project and share it.

The Integrated Development Environment or IDE for friends (we dropped the term IDF) also allows you to use snippets in your code. Put your favorite piece of code (HTML, CSS, JavaScript or Uniface code) in a snippet and copy and paste into the wee hours of the night. We will provide you with some of our snippets but feel free to create your own.

Just as in any other film there are some characters that will not make it to the end of the movie. For instance the (pirate voice) URR file is no longer part of Uniface. I have always had great difficulty understanding the Uniface Runtime Repository and am glad to see it go. Seeing it off with a bonfire made from my URR notes and the documentation. The UAR deployment option is the way to go from now on.

The removal of the application model entity from the meta dictionary hit me a little harder. In Uniface 10 the application model is just a namespace. Need to move an entity from one model to another? Just rename the model part of the entity name. So be careful, especially with typos.

We pulled all the triggers. And replaced them with script containers. From now we will supply you have with a Declaration container and a Script container to write your ProcScript in. Just for good measure we will give you three containers in the entity editor (Declarations, Collection and Occurrence). But that’s it. Want to create a trigger? Just use the keyword trigger in the same fashion you define an operation or an entry. Just to raise the stakes a little we have renamed the trigger names to make them more uniform.

What else do you need to know? Well the first version is an early adopter version. We are still working on a lot of stuff, that will be made available in future release. For instance there are no library elements yet. So you have to do without include procs, messages and such. But we just couldn’t wait to show you what we have done so far.

When thinking Desktop “first” still matters (Part 2)

By Clive Howard, Principal AnalystCreative Intellect Consulting

Read Part 1 Here

Great experiences are not just for mobile

In an era of high user expectation and the demand for great user engagement, Application User Interface (UI) design has never been so important. We’ve heard this message before of course, when the virtues of Web 2.0 and Rich Internet Application were espoused in the mid 2000’s and browser based applications along with the proliferation of smartphones, tablets and mobile apps cemented that reality.  Many organisations have now caught up and are starting to realise that users demand more usable experiences and providing them can have productivity benefits. The results can often be seen on a business’s bottom line or through competitive advantage. I worked on a call centre application where improvements to the User Experience (UX) dramatically reduced call times and improved the quality of data collected. This led to efficiency within the call centre and improved outcomes for both the business and the customer. Costs were reduced and customer satisfaction rose.

In a desktop first world designers will still need to provide users with great UX. At the same time they need to appreciate the potential for different end user form factors. Application interfaces will need to adapt to alternate screen sizes. The modern desktop could be a traditional 20 inch monitor or a 10 inch touch screen. Where the desktop application spawns mobile apps they will need to have consistency with the desktop experience. A user should be able to move from desktop to tablet to mobile very easily because the app experience is familiar to them. This is best achieved if the original design considers the possibility of mobile from the beginning.

Plan for a “multi endpoint first” future

For all of those development professionals out there who have spent their careers building desktop applications their future should be secure. But they will need to adapt their skills, thinking,  tools and possibly their processes to a new world in which mobile may not always be first but will be relevant. Many desktop applications will remain installs but many others will be delivered via a web browser. Equally for the IT decision makers they need to think about investments that are not just about mobile. It is very easy in the current climate to think that the future is mobile and therefore investing in mobile only platforms is the way to go.

Instead they need to consider that the desktop is going to be around for a while and they need to invest in platforms, tools and skills that will support a broad portfolio of applications. Essentially this comes down to being efficient with the code base. Not replicating code should always be a core aim. Creating code that can be tested at all levels of the stack should be a further key ambition; making the functions of that code base available through services to multiple end points should be another. With a services based architecture, the application may be spread across both the company data centre and public cloud environments.

Where development moves to being Agile, development will need to work with Operations in order to speed application changes into production. This will most likely mean embracing a DevOps culture, processes and tools. The modern desktop app will require more regular updates than the old fashioned quarterly release.

There will certainly be many situations where a mobile first approach will make sense in future. Studies show that people are accessing the internet more from mobile than desktop and so for websites mobile first will probably be a good idea in the majority of cases. However, the future will be a combination of mobile, tablet and desktop experiences. Developers and organisations will therefore need to consider each application and in some cases it will make sense to go desktop first.

When thinking Desktop “first” still matters

By Clive Howard, Principal AnalystCreative Intellect Consulting

A few months back, I registered for Mobile World Congress 2015 in Barcelona. As an Analyst, there is a different registration process to the one used for regular attendees. This is so the organisers can validate that someone is a legitimate industry analyst. As well as entering a significant amount of personal data, additional information such as links to published work and document uploads are also required. Crucially, there are a number of screens to complete the registration and accreditation process. But more to the point, many different types of data must be entered – from single and multiple line text entry to file uploads. Some data (such as hyperlinks) requires cut and pasting.

I’m sure that I could have done this using a mobile phone but it would have taken a long time, been awkward and irritating and probably highly prone to mistakes. In short, I would never have considered doing something like this using my phone. Could I have used a tablet? Without a keyboard and mouse it would have been problematic, especially if the screen is small. Using a tablet only Operating System might also have had its problems in places: such as uploading documents from centrally managed systems. Actually I did use a tablet but one connected to a 20inch monitor, keyboard and mouse and running Windows. In that traditional desktop looking environment the process was relatively quick and painless.

Rumours of the desktop’s demise are greatly exaggerated

It is not just complex data entry scenarios such as this that challenge mobile devices. Increasingly I see people attach keyboards to their tablets and even phones. Once one moves beyond writing a Tweet or one line email many mobile devices start to become a pain to use. The reality of our lives, especially at work, is that we often have to enter data into complex processes. Mobile can be an excellent complement, but not a replacement. This is why we see so many mobile business apps providing only a tiny subset of functionality found in the desktop alternative; or they are apps that extend desktop application capabilities rather than replicate or replace them.

One vendor known for their mobile first mantra recently showed off a preview version for one of its best known applications. This upgrade has been redesigned from the ground up. When I asked if it worked on mobile the answer was no, they added (quite rightly) no one is going to use this application on a mobile device. These situations made me think about how over the last couple of years we have heard relentlessly about designing “mobile first”. As developers we should build for mobile and then expand out to the desktop. The clear implication has been that the desktop’s days are over.

This is very far from the truth. Not only will people continue to support the vast number of legacy desktop applications but will definitely be building new ones. Essentially, there will continue to be applications that are inherently “desktop first”. This statement should not be taken to mean that desktop application development remains business as usual. A new desktop application may still spawn mobile apps and need to support multiple operating systems and form factors. It may even need to engage in the Internet of Things.

The days of building just for the desktop safe in the knowledge that all users will be running the same PC environment (down to the keyboard style and monitor size) are gone in many if not the majority of cases. Remember that a desktop application may still be a browser based application, but one that works best on a desktop. And with the growth of devices such as hybrid laptop/tablet combinations, a desktop application could still have to work on a smaller screen that has touch capabilities.

It’s the desktop, but not as we know it

This means that architects, developers and designers need to modernise. Architects will need to design modern Service Orientated Architectures (SOA) that both expose and consume APIs (Application Programming Interfaces). SOA has been around for some time but has become more complex in recent years. For many years it meant creating a layer of SOAP (Simple Object Access Protocol) Web Services that your in-house development teams would consume. Now it is likely to mean RESTful services utilising JSON (JavaScript Object Notation) formatted data and potentially being consumed by developers outside of your organisation. API management, security, discovery, introspection and versioning will all be critical considerations.

Developers will equally need to become familiar with working against web services APIs instead of the more traditional approach where application code talked directly to a database. They will also need to be able to create APIs for others to consume. Pulling applications together from a disparate collection of micro services (some hosted in the cloud) will become de rigueur. If they do not have skills that span different development platforms then they will at least need to have an appreciation for them. One of the problems with mobile development inside enterprise has been developers building SOAP Web Services without knowing how difficult these have been to consume from iOS apps. Different developers communities will need to engage with one another far more than they have done in the past.

Those who work with the data layer will not be spared change. Big Data will affect the way in which some data is stored, managed and queried, while NoSQL data stores will become more commonplace. The burden placed on data stores by major increases in the levels of access caused by having more requests coming from more places will require highly optimised data access operations. The difference between data that is accessed a lot for read-only purposes and data which needs to be changed will be highly significant. We are seeing this with banking apps where certain data such as a customer’s balance will be handled differently compared to data involved in transactions. Data caching, perhaps in the cloud, is a popular mechanism for handling the read-only data.

Continuation of the Testing challenge

Testing will need to take into account the new architecture, design paradigms and potential end user scenarios. Test methodologies and tools will need to adapt and change to do this. The application stack is becoming increasingly complex. A time delay experienced within the application UI may be the result of a micro service deep in the system’s backend. Testing therefore needs to cover the whole stack – a long time challenge for many tools out there on the market – and the architects and developers will need to make sure that failures in third party services are managed gracefully. One major vendor had a significant outage of a new Cloud product within the first few days of launch due to a dependency on a third party service and they had not accounted for failure.

Using CouchDB with Uniface

I won’t repeat any definitions of what NoSQL databases are, nor a review of any specific products. I’ve read plenty about NoSQL databases and I think that the general view of developers is that it is one more tool in the arsenal of application development. I generally believe that you should choose the right tool for the job at hand.

So, you may get that task one day where the advantages of using a NoSQL database outweigh the disadvantages. Can, or how can you use this database with Uniface? The answer definitely depends on the specific NoSQL database product. Between them all, they have a large variation in their APIs and data structures. For that reason I will just describe my experiences doing some prototyping with CouchDB from Apache. Be aware that this is slightly different to Couchbase, which appears to be a commercialised offshoot from what Apache took on board as an open source project. For brevity, I refer you to the website for information about CouchDB’s characteristics:   https://couchdb.apache.org/

The major characteristic of CouchDB is that the documents stored in the database are in JSON format. While investigating another project, I stumbled upon a convenient source of JSON formatted documents that I could use to store in my CouchDB database. I hope that you aren’t offended by simple Chuck Norris jokes. It is a unique genre that not all will enjoy, but it served my purposes adequately. Thus in studying my prototype, you could imagine how you would handle more business related data.

I have provided a sample form in the community samples part of Uniface.info. All you need to do, besides compiling that one form, is to download and install CouchDB from the earlier link provided. I downloaded the Windows version. I manually created the “cnjokes” database using the CouchDB provided Futon utility, also installed with the Couch DB. I also manually defined the design document “vcnjokes”; more about that later.

The top part of the COUCHTEST01 form is really a “utility” area, where you can manually enter URIs and run requests against the “cnjokes” database.   These requests use the UHTTP internal Uniface component. The way the CouchDB API is structured gives you a very RESTful web service interface, though there are some comments on how RESTful CouchDB really is, within their online tutorials. The results of the calls are available in the message frame.   You can press the GET button without adding anything to the URI and you will see some global information about the “cnjokes” database. Overall, this “utility” is not as flexible as the CouchDB provided Futon utility, but it might be helpful during further Uniface development.

The 4 buttons, and accompanying entity and fields provide the real prototype; effectively demonstrating a CRUD lifecycle of managing CouchDB documents. The UHTTP component is used to obtain a CN joke in JSON format from an internet website, and then the UHTTP component is used to interact with the localhost CouchDB server. The document format is deliberately unchanged between the external joke website and CouchDB. However, you could manipulate the JSON before storing it in CouchDB if required, using Structs. Note that I have used $uuid as the basis for assigning a document ID.

The other 3 buttons query the CouchDB database using views. Ad-hoc queries are not possible in CouchDB. The 3 views are defined in a single “design document” called “vcnjokes”. The source for that design document are provided with the sample download, as comments for the COUCHTEST01 form.

  • Button “Get all current jokes from CouchDB” uses view “joke_by_jokeid”. All jokes are retrieved, and sorted by joke_ID, but only a few columns are selected. It cannot be edited as the revision ID is not available. Note that escaped quotation symbols in the data are displayed as quotations.
  • Button “Get all nerdy jokes from CouchDB” uses view “nerdy_joke”. The jokes list is filtered to those that have a category of “nerdy”. This list also cannot be edited.
  • Button “Get all current data from CouchDB for edit” uses view “all”. This view references all of the document and so all fields, including revision ID, are available. Thus editing can be done, and when stored, the new revision number is updated. Note that escaped quotation symbols appear as stored, for ease of updating.

When preparing the JSON for display in a Uniface form, it is certainly necessary to use Structs to manipulate it into the Component data structure. In fact the choice of the external data structure of the form entities is quite arbitrary. CouchDB has no fixed schema. Thus you can never be sure that an external application won’t add data that renders your entities and fields obsolete. All I could do is generate a useful number of jokes, and observe that some of them have one category with a value of “nerdy”. However, I can see that the category is defined as a JSON array, and so I make sure to set   $tags->jsonClass = “array” before converting the struct to a JSON string. This is what led to the one to many relationship between CNJOKE and JCATEGORY. With my CouchDB data set, I verified my schema by manually adding several extra categories to some jokes, using structure editor commands to add and remove occurrences (tool tip text will assist you).

Hopefully this prototype demonstrates how modern features in Uniface allow integration with other modern software systems.

 

Our Day by Day Highlights of MWC Barcelona

It was the first time we participated in MWC15, and to sum it up in a few words: Totally exceeded our expectations! Here’s a day by day recap of our time in the “trenches.”

Day 1:

It was a very interesting first day. There were initially some quiet moments, but then things picked up and all demo stations (3 of them) plus the 5 devices were being used by our Uniface colleagues were all busy and everyone engaged in conversations. It was awesome. The energy flowing around the booth and within the team was fantastic. The day flowed with up and down time and in general with a lot of positive reactions.

Danny (account manager) attended Mark Zuckerberg’s keynote presentation. Even the Uniface (freelance) photographer ;-) got a great picture of the King of Spain!

Arriving at the event

Arriving at the event

The King of Spain who attended the event

The King of Spain who attended the event

Day 2:

After an early team debriefing at the booth to the Uniface crew, the energy was good, we had a good synergy between the whole crew and the roles were working fine. We worked hard, including sending people canvasing around to talk to people around our section “App Planet” which by the way it is the perfect spot to have Uniface. Also, it was clear that our tag line “Design your mobile enterprise” is spot on.

Remind me to tell you later about my public transport adventure after the day was over, I mean  Tianle, Thomas, Christophe and myself going back to the hotel with the idea to see a bit more of the city. And we did, including walking the “extra” mile … literally!

Busy time at the Uniface booth

Busy time at the Uniface booth

Day 3:

The Uniface crew went through a metamorphose with some people leaving and new people coming. I must confess that as a former ‘amateur’ football coach/trainer, you know you never change a winning team; so I was a bit worried. Luckily for me, this was not a football match, so everything transitioned perfectly fine.

Again the day passed on the blink of an eye. For me, the best way to describe it is using as reference the differences between the length of technical demos which are: on day one demos lasted approximately 15 minutes, on the second day those lasted 25 minutes and on the last day these were over the 35 minutes average; the main reason being the interest of the prospects (of course) and the type of questions they asked.

At the end of the day, people were partying all over the exhibition halls, listening to music and having drinks. I have a complaint which I want to make public now, Danny Ragowan went to drink tequila with my fellow Mexican countrymen on my invitation and he left me behind at the booth. I was invited earlier on the day when I visited them. (On his behalf I need to say I was involved in the last demo.)

Part of the Uniface Crew

Part of the Uniface Crew

More booth traffic

More booth traffic

Day 4:

The experience has been unreal – In my wildest dreams I would not have imagined such positive results of MWC15 for Uniface. The people we talked to were interested in the core Uniface message, which means that a cross-platform model-driven development and deployment environment is what people are looking for.

Besides the above, how about our approach to the market by extending technologies (CHUI, C/S, WEB, RIA, Mobile) in the spirit of shielding the business from technological evolution and then again empowering the developers to embrace those and in case needed go the depth necessary to solve the business requirements. And guess what? It did all of these and more. Because even fellow exhibitors considered that an incredible strength of Uniface.

As a bonus, the Uniface culture also shined at the event. The ambiance and behavior will be remembered and we heard on several occasions: “Here come the nice guys in the white shirts!”

Packing up at the end of MWC

Packing up at the end of MWC