SAP Fiori experience

It was a long time ago we wrote something about SAP UI5. Since the last blog post I’ve dug deeper into UI5. Now the UI5 is has a new way of make the user experience better. It’s called SAP Fiori. It’s not a tool, it’s like some guidelines how to create eye-catching UX which is easy to use and learn. The main thing in Fiori is to bring the same user interface for different applications. For example if you’re a Sales Representative and you’re using an app for creating quotation, and using another one for manager your timetable it’ll have the same interface. And if you’ll use a new app, you don’t have to re-learn the usage of the application. It’s really easy to deal with new apps, which makes user experience better.

 And as a technical guy you can develop new application in a few days. It’s really fast to develop. And now there’s a new tool for building Fiori applications. SAP delivered the SAP River RDE. The River RDE was announced in June. I’ll write another blogpost about it in next month.

Last time I’ve created a simple application (it was prepared to show it in the University). At first it took some time to learn the basics of UI5 and Fiori, but after the first app it’s much easier to develop another. Right now my plan is to connect my Fiori app to the Fiori Launchpad, which is the landing page of the Fiori applications, and connect the application to an SAP server to use data from there (via Odata).


I think the best thing in UI5 and Fiori that it’s responsive, so you don’t have to develop it to different screen resolution, the UI5 framework will do the job instead of you. And your app will look the same on a PC, on your iPad and on your phone. And you have a variety of useful pre-developed controls. It’s like a magic box, you just take out what you need and use it in your app.

author: Dávid Tóth

First impressions on OpenUI5

Working at Netlife has its perks even if we take away the awesome team and the cool projects. We are always reminded to push ourselves beyond our limits and learn new ideas and technologies.Last week I had the time to try out the newest SAP venture into modern web development: OpenUI5. Accompanied by our intern Dávid Tóth, we dove into the mysterious world of this MVP HTML5 framework.



The first thing that we noticed is the 'P' is very different from the 'C' or 'VM' that we had worked with in other frameworks. The main strength that I see in this framework, that the presentation is completely cut off from the model, we just need to create pseudo-HTML elements in Javascript and the built-in theming take care of the rest. Despite the hard to understand and deficient documentation, we could create a functional mobile and desktop-friendly contact list application in just two hours!

The result:

Such a beautiful app from so few lines!
To take an excerpt from the source, this is all we need to create the table object:

var oTable = new sap.ui.table.Table( "ID_BusinessPartnerTable", { visibleRowCount : 20 }); 

The content is brought in via an oData service in an elegant way, and again, we don't need to think about the presentation of the table, just put the data to the right place.

Integration with other tools

I use Yeoman extensively in my day-to-day work and I was pleased to find a good generator for this newcomer framework.
Because of this, Grunt and Bower integrate with the framework flawlessly and there is no overhead to manage dependencies.


All-in-all, we will continue to play with this new way of approaching enterprise problems, even if it has some issues on the support side of things. The next step is to integrate this with our test SAP server and create a full-fledged application!


New horizons for Firefox OS

Since I joined Netlife, I tackled many interesting problems and completed several projects, but none of them were as astounding and revolutinary as Firefox OS application development. You may know that we're developing a CRM solution for small businesses, called BeeCRM. When I got to know of the system, I've seen a possible use case for mobile users: Having an easily accessible interface to call/message customers with every relevant information displayed in front of them, like meetings/tasks and prior events, seemed invaluable. Me being mainly a web developer, I welcomed Firefox OS with open arms because I knew Javascript much better than Java or Objective-C, and needed rapid prototyping, while realizing all of the features that were needed to the initial 1.0 version that would be later ported to the more popular platforms. I was very happy with the fast (nearly non-existent) learning curve: I could push my application with ease to our phone, while developing in my well-known, productive environment. I think this is the main selling point of FFOS: making a plaftorm accessible to millions of web developers around the world. So I made a JSON REST API in Go to our database with goweb. On the client-side I used plain old jQuery + knockout.js. This was my first experience with Knockout, and it really peaked my interest in MV* frameworks. But there were some problems, that frustrated me to no end while developing:

  • Offline Storage. MDN mentions IndexedDB and localStorage. IndexedDB is complicated beyond human understanding if you don't use a full-fledged storage library. In contrast localStorage has a very nice interface, the downside is, it's synchronous and it can only store string objects (there are JSON hacks of course, but we don't do "hacks" at this company ;) ). After half a week I found asyncStorage, which was nearly identitical to what I developed until then, to ease my frustration. This should be promoted as the #1 offline storage solution, because it wraps the aforementioned IndexedDB in the localStorage interface, just asynchronically and it can also store any kind of JS objects. Neat!
  • Too much restriction. I think the WebAPI limits the developers too much in the protection of the user. I know after recent events this sounds reasonable, but when I can't determine from a call launched from my app if it's finished or the duration of it... It frustates me to no end. The devs at Mozilla are working on this, but I can't even imagine why this hasn't been implemented in the first place. Automatic logging of calls are a no-no for now.
  • Breaking HTML standards. Building Blocks features multiple best-practices and code samples to achieve native looking effects in your own apps. These "samples" are done in deeply nested HTML tags with non-standard attributes. (Abusing the "role" attr this way is against every HTML standard I know!) Also CSS styles rely on eachother too much and on this abomination of a structure.

Otherwise my experience has been great. When Android was this old it was much-much worse in UI and UX terms, so props to all the great work for every contributor on the project! Of course the OS and the WebAPI ecosystem needs to mature, but we're working on it with the awesome Mozilla team. I'm looking forward watching the wave of the Web Dev Community making the cheap chinese Android knock-offs fall!

Airplanes, Rovers and K.I.T.T.

The X. Simonyi Konferencia (10th Simonyi Conference), named after Karoly Simonyi was held at Budapest University of Technology and Economics last Tuesday. I was there, attending various presentations, and I'd like to share some of the things I've learned.

The first presentation I attended was called "Safety-Critical Software Development in the Aerospace Industry" by Akos Horvath from BME MIT (Department of Measurement and Information Systems). He works with Embraer, one of the largest aircraft manufacturers in the world. Aviation is generally considered to be the safest way of transportation. Did you ever wonder why this is so? Well, first of all, you don't really meet Hummers driven by drunk idiots up in the sky. Also, there are lot more distances between planes. The list goes on and I don't intend to mention every aspect, but there is something we can't discard: the software aiding the pilots are really trustworthy. I think all my readers encountered countless bugs in the software they use. How can we trust aircrafts? Well, the keyword is certificates. If you want to build an aircraft and sell it to airlines, you will have a really bad time. There are many requirements your plane has to meet. The software they use is so well-documented that if you ask them about any line

in the object code, they can show you what it does in the specification and the code is 100% covered by tests! Literally, every condition in the code is tested by every possible inputs. Furthermore, the environment they use (IDEs, compilers, everything that can inject errors to the code) must meet the same requirements! How much time do you spend on testing the software you write? And how high is the coverage? Now, can you see why planes are so expensive?

After a short break, I went to listen to Andras Balogh (ThyssenKrupp) talking about agile software development. Well, it's pretty straight-forward, you can learn about agile development everywhere, just ask your friend Mr Google. The interesting part was that ThyssenKrupp actually uses this agile-like development workflow for the hardware development too! I missed the Q&A part, because

I had to run to the only presentation about web development.

It was held by Peter Szel (EPAM), and it's title can be translated as "Real-Time Web - Write a Facebook Chat." Well, did you think about it? How would you write it? The best way so far seems to be the WebSocket, which is finally provides truly full-duplex communication over a TCP connection. However, it's not yet available in all browsers, so for an unfortunately big part of your users wouldn't be able to use your chat. Would you care to create a fallback option or just use plain old long polling? Well, Microsoft Open Technologies' ASP.NET SignalR (licensed under Apache License 2.0) takes care of all that, and much more!

I'm an Archlinux user, so I can't really play with .NET, but I very much liked what I saw at Peter's presentation. You open up Visual Studio, code a few lines in C#, code a few lines in JavaScript and you're pretty much done. Oh, did I mention you can call JavaScript functions from your Hub in the C# code? Well, you can, and vice versa. You can broadcast stuff to every client connected to your

running server or only to selected client IDs, it's your choice. SignalR seems to takes care of the "CodeMonkey" stuff. You can find some samples here: Too bad it exists only for ASP.NET as majority of the web servers are Linux boxes, running PHP. Well, I'm thinking about creating a PEAR package for SignalR. If anyone feels like joining the team, email me at attila [dot] bukor [at] netlife [dot] hu!

Attila Vekony from NNG talked about voice command navigation. I guess you think "Wow, big deal, I've got Siri on my iPhone". Yup, you may have Siri, but did you know it uses Internet connection? Well, it does. It uses servers to guess what you said. NNG designs navigation systems for cars, which don't usually have SIM card, so it has to guess what you want offline! They use a third-party libraries for the actual voice recognition (they license it from Nuance). But don't think Nuance does all the hard work! It won't actually understand what you said

of course. It will just give probabilities for possible matches in its dictionary. The engineers still need to decide where you want to go - still offline -, and it isn't that easy either. Think about it, there are tens of thousands of cities - the names aren't even unique - and millions of streets. And this tiny device will understand what you wanted in seconds and calculate the route in a few more seconds. Pretty amazing, isn't it?

The next presenter was Matyas Hazadi from PuliSpace, the only Hungarian Google Lunar X Prize competitor. He talked about the competition, and the technical and financial challenges of the project. Every key system - which aren't cheap - has to be redundant, which of course causes the rover to weigh more and ultimately the cost of the transport to grow - the bigger the weight, the bigger the fuel consumption.

The last presentation was held by Peter Halacsy Co-Founder and CTO of Prezi. It was a really interesting presentation, he talked about start-ups, challenges of start-ups. I really can't summarize it, but if you like some great challenge, visit!

The conference was great with interesting presentations. This was my third or fourth one, and I'm pretty sure I'll be there next year too. I hope there will be more guests though.

Javascript: a right way

Backend developers - including me - tend to underestimate the importance of javascript, or somethimes even say things like:
Who cares about js? It's like two lines anyway.
Some people say javascript is just unmaintainable, forget about it, and learn CoffeeScript... or TypeScript or whatever is the most popular library / language that week. I'm not saying that is the wrong approach, but on the other hand I'm not comfortable with a language that compiles to javascript, the very thing it tries to replace. I guess I'm not a glass half full kind of guy. In my opinion, it is up to us, developers to create good code, not the language itself. So what can we do to get better code, better results?

Do it right

Hurrying is the root of the problem. We pay a lot of attention to the backend part, why should we get lazy when it comes to the frontend? Unfortunately it happens often. Yes, it can be done fast, but those few minutes that can be shaved off will come back to bite us later. Spend some more time for each task that requires js, and do it right.

Limit the number of inline scripts

Inline scripts make maintainance nearly impossible, and there is no real reason to do it. For example, declaring variables is a common usage of inline javascript.
<script> var url = <?php echo $url; ?>; </script> 
Use the HTML custom data attributes instead:
<div id="listContainer" data-url="<?php echo $url; ?>"> 
.js file using jQuery:
var url = $("#listContainer").attr('data-url'); // or .data('url'); 
This way, you have a better picture of the origins of the data, and you know exactly which dom element is going to need that data.


Athough javascript does not have the best OO solution, you have options to create objects and keep your code separated. My favourite is to create object literals, and use them like singletons, like so:
List = {    
    goToPage: function(page) {
        $.get($("#listContainer").data('url') + '/' + page, function(data) {


Dependency Injection

10 milligrams of EntityManager, STAT!
  Wait, what? You must think that this guy is a Symfony2 dev gone crazy... well you are right! Don't worry, I'm not suggesting anything serious. Most javascript functions depend on dom elements, or selectors for dom elements. Therefore reusability is limited. The above mentioned List object would fail us, if we had two or more lists on the page. Let's modify our code, and inject the dependency:
List = {    
    goToPage: function(page, $container) {
        $.get($'url') + '/' + page, function(data) {

If you are working with object constructors, and instanciate objects, you can inject the dependencies in the constructor. Note: The $container is not a mistake, it's a common naming convention in jquery, it means the variable is jquery object. (Hungarian notation)

Model-View-View Model (MVVM)

Following the above mentioned rules will get us halfway there. We have a maintainable, scaleable code, but we still have to do a lot of work on the frontend, and in fact we got even slower than before, because of the rules. Clients will not like that. MVVM is a great pattern, it can make the development process much faster. Every serious web application should consider using it. This being a common problem, you don't have to re-invent the wheel, there are many awesome libraries which you can use. My personal favourites are AngularJS and KnockoutJS. They both have great tutorials, including videos, and the learning curve is virtually non-existent: you can start using them after a 20 minute video!