Quick tip: Logging in Gradle build scripts

Did you know that it is really easy to log something in your Gradle build files? As the Gradle documentation explains, Gradle adds two log levels: QUIET is used for important information messages, whereas LIFECYCLE should be used to log progress information messages.

To see how it works, take a look at the following screenshot. It demonstrates how to log if Android's new experimental toolchain Jack and Jill is enabled. To enable it, just insert useJack = true.
A small note... You may be asking yourself why I used the unusual == true. It appears that this expression is more reliable if the variable useJack is not present at all.


Thoughts on the mobile enterprise #7: Apps for employees

In a series of posts I will elaborate on how enterprise applications can embrace mobile devices.

In part 6 we took a look at mobile apps for end users. In this post I will turn to apps that are used by employees. Such apps can be divided into several broad groups, too.

Apps that replace old user interfaces

Imagine this scenario: you have an enterprise application that has been in production for several years. The user interface is implemented as a Java-based rich client. Now, the company decides to give the application a fresh new look. One reason for this may be that management has decided to replace the pcs in the offices with thin clients and to establish a virtual desktop infrastructure. As the execution environment for user interfaces is merely virtualized, the old Java-based user interface could be used further. However, depending on the number of computers to be replaced, the server-side infrastructure needs to be quite powerful.

If a change of technology is inevitable (because it is requested), today new user interfaces are usually implemented as web applications. The underlying reasoning is that such apps will easily run on mobile devices. As you shall see in the course of this series of blogposts, this may be a misconception. To be able to switch the ui technology stack, the corresponding parts of the application must be clearly separated. As I have discussed earlier, this is by definition true for rich clients - although this says nothing about the quality or usefulness of the provided interface. Current Web-based apps, on the other hand, unfortunately tend to be a melting pot with fuzzy, difficult to separate layers. Then, changing the user interface, inevitably means refactoring the whole application. Let me be clear about this: this is no flaw the involved technologies per se, but stems from poor application design.

There may be a more substantial change of technology on its way than moving from traditional pcs to virtualized, centralized desktops. Until recently, touch enabled devices without mice and keyboards had form factors way too small to be used in the office. This might change, as the latest tablet generation offers display sizes up to 15 inch. I expect this development to continue. At the time of writing Microsoft's Surface Hub is a (forgive me) fascinating and exciting curiosity. Smaller-sized versions might well become the office device of the future.

To sum up, apps that replace old uses interfaces are the new, friendly face of the host. Devices that display them are seldom moved, are part of the company intranet and are connected to the backend over high speed networks. If this is done by wire or over the air is a matter of taste (driven, perhaps, by costs and available infrastructure).

Special-purpose apps for in-house use

Special-purpose apps for in-house use form a niche group. The devices that display the user interface are highly portable, usually equipped with sensors or scanners to collect data, and may even have a small printer to produce labels. They are part of the company intranet and exchange data with their backend frequently. Depending on the purpose, the device may have a touch screen, or an old fashioned keyboard that can withstand rough working conditions.

If a special-purpose device is used, the technology stack for the user interface may be restricted by the operating system or the vendor. If the system is even more closed, the only possible connection to an enterprise app may be a (hopefully documented) remote interface, or direct access to the system's database.

Examples include inventory systems to support facility management, measurement of environmental conditions and warehouse management.

Apps for off-site employees

This category subsumes apps for employees who mostly work off-site, for example sales representatives, insurance broker or traveling salesmen. We can distinguish between

  • apps that work with customer data
  • apps that operate on company-related data
  • apps that do something

Customer data is related to, well, customers. This may include addresses, contracts data, income, debts, age, children and other personal information. Such data is highly sensitive. The mobile enterprise application must make everything possible to protect it. As you shall see later, this includes the client, the transport route as well as the backend.

Company-related data may refer to products the organization is selling, but also employees contacts data, sales figures, statistics, organizational charts and assets lists. Such data is highly sensitive, too. Therefore the mobile enterprise application must make everything possible to protect them.

You may argue that stressing those security aspects seems a little over the top as they are obvious. Keep in mind that most mobile enterprise apps are not built from scratch. Instead they evolve from a system that has been running for years. Even if a proper security analysis has been done when the application went online, network topology, app-server configurations and firewall settings have likely changed since then. Besides, if the route from client to the backend used to be secure, some security measures may not be in place just because they have not been necessary. I will talk more about security later.

The choice of ui technology should be based upon the focus of the app. If a considerable amount of data has to be entered or edited, rich client-like frameworks must be considered. If the app is used to visualize content (animations, photo-realistic renderings, charts), possibly handing the device over to the customer, this requires a slick and polished visual appearance.

I will conclude this post with apps that do something. They may collect some sort of telemetry or sensor data, scan barcodes, print labels or program process control computers. Hence, they are similar to special-purpose apps for in-house use, besides that they are used off-site. So what I have said above applies here, too:

  • the devices that display the user interface are highly portable
  • depending on the purpose, the device may have a touch screen, or an old fashioned keyboard that can withstand rough working conditions


Thoughts on the mobile enterprise #6

In a series of posts I will elaborate on how enterprise applications can embrace mobile devices.

Part 6: Apps for end users

Just as there was a (fortunately long gone) time when company executives used to say We need a website there also has been a time when they wanted an app. There is certainly nothing wrong with this, besides the lack of focus. In this and a few following posts I am going to take a closer look at types of mobile apps (the word enterprise is missing on purpose). Talking about this usually leads quickly to a native vs. cross platform debate. While that decision certainly has to be made, I think it should not be the starting point. Other matters ought to be considered first.

The most important question is Who is going to use the app?. Who will be the target audience? As you shall see soon, its quite short answer end users/customers or employees has a significant impact on further decisions. End user apps can be divided into two broad groups:

  1. apps that solely run on the client (for example games, productivity apps, tools and media players)
  2. apps that connect the user to some service (for example Facebook or Twitter)

The difference lies in the decision if the app itself is the product (which undoubtedly is the case for games) or the service the app connects the user to. In other words: is the app published to make money or gain reputation, or is it put in the app store to promote the underlying service? The distinction between those two groups may not always be easy. For example, what happens if the game saves a highscore list on the publishers' servers? Or if a writing app stores its files there? If the app is tied to the vendor, that is, the user is forced to create an account, the app probably belongs to category 2. If the save function is merely an add-on, the app belongs to the first category.

If the app itself is the product, it has to be as good as possible. What this means depends on its purpose. For example, games must be compelling, that is, graphics, sound and gameplay provide an awesome experience. Do not confuse this with the need to provide super-realistic hd pictures. An app that mimics retro style may be equally fascinating. The important point is that the underlying concept has to be convincing. Especially games are usually implemented as native apps. The decision is often based on the need for maximum performance. Other types of client-side apps may not have this restriction.

Apps that promote a service must do everything possible to make that service shine. Depending on its type, the app may need to integrate deeply into the client system. Here, too, a native app is often the right choice. In such a case, though, not the performance matters, but the need to communicate with other apps and components. For example, the client for a calendar service must make events and appointments available to the system-wide calendar. The same applies to contacts.

Apps of both categories may use wireless communications. Usually apps that solely run on the client will need less transfer capacity. If logins to a backend server are made, both groups have to ensure the security of the users' data. How this can be done is subject to a future blogpost.

Back to part 5


Thoughts on the mobile enterprise #5

In a series of posts I will elaborate on how enterprise applications can embrace mobile devices.

Part 5: Notes by the editor (the story so far)

In part 4 I discussed how much logic can or should be present in the ui layer of an enterprise application. The series so far motivated the term mobile enterprise application. You have seen how they relate to traditional enterprise apps and what has to be done to make them ready for mobile devices. Future posts will discuss matters in greater detail.
Book cover: On Mobile Enterprise Apps
The posts will be combined, expanded and carefully edited to become a book called On Mobile Enterprise Apps. The book will be available through leanpub. I'd very much appreciate feedback about the topic in general and my writing in particular. If you would like to be informed when the book is finished, please sign up for a notice on the leanpub book page.


Thoughts on the mobile enterprise #4

In a series of posts I will elaborate on how enterprise applications can embrace mobile devices.

Part 4: About logic on the client

At the end of part 3 I asked you to imagine that your hypothetical enterprise application is well structured and consists of several components that implement the business logic. These components can be accessed through some remote interface. Further, the ui layer is implemented as an individual program running on a pc. It could call the business components through some remote procedure call mechanism. Should it?

If you found this question misleading, you are certainly right. Of course it should. To some extent. The underlying (hidden) question is how much logic is allowed or wished for on the client.

Consider this: who should take care of the orchestration if several remote procedure calls are necessary to complete a business function? Who is in control of the page flow or navigation? Where does validation of user input take place? How much does the client know about data types and dependencies among fields on a form? To answer these questions we need to decide how thick or thin, rich (or poor) the client should be. Especially the term thin client is used in several ways. To escape ambiguity I prefer an alternative means of distinction: business logic vs. presentation logic. The first one drives the application, it is a manifestation of its use cases. Presentation logic, on the other hand, drives the user interface. It is generally agreed upon that within distributed systems no business logic shall be present in the ui layer. One reason is that you would loose functionality if you exchange the client. Presentation logic is specific for each type of client. Hence it seems natural to put it in the corresponding layer.

If the client knows the page flow and knows which forms will be displayed along the way it can do so without bothering the backend. Of course, at some point it will need to persist user input or invoke a business function. Certainly, final consistency checks must be performed by the backend even if the client knows how to validate input. But if the client is self-sufficient to some extent it spares us server roundtrips. Something that may be crucial for mobile apps.


A look in the crystal ball

There has been quite a buzz around Android N (supposedly to be released some time this year) switching to OpenJDK. But what exactly could that mean? What parts or components might be affected? Attendees of my talk Nummer 5 lebt at HerbstCampus 2015 in Nuremberg (Sep 1 2015) know since then that being related to Apache Harmony Android is somehow stuck in Java 6. Because Google has extended the old code on its own, developers coming from pure Java find it especially hard to guess what class library features are present and which are not. If you have not had a chance to see me, come join me at TopConf Linz 2016. In my talk Beyond Harmony I will give you an update on what you can expect today, and what you might expect from Android N.

While it seems clear that Google will be updating the code base of the Java class libraries to OpenJDK it is mere speculation if and how this move will affect the Java runtime and the use of tools, especially the Java compiler. Unlike when I gave my talk at HerbstCampus last year, it is now common knowledge among developers that since Android 5 the platform no longer uses its own register based virtual machine named Dalvik, but exclusively relies on a runtime named ART (Android Runtime) which is based upon an advanced ahead of time compiler. In doing so, Android apps become native Linux apps at installation time, hence benefiting from all the goodness the Linux kernel has to offer, such as kernel samepage merging. Though I have no inside knowledge whatsoever I doubt Mountain View will be giving this up.

Something not so common place is that since more than a year there is a new (experimental) tool chain around two tools named Jack and Jill, aiming to speed up compilation and build time. Jack (Java Android Compiler Kit) comprises a compiler from Java programming language sources to the Android dex file format. Jack has its own .jack library format and provides most tool chain features as part of a single tool, for example repackaging, shrinking and obfuscation. Jill (Jack Intermediate Library Linker) is a tool that translates existing .jar files to the .jack library format. At the time of writing Jack knows Java 7 language features.

It will be interesting to see if Google will be expanding on this, or giving it up. In any case for us Java lovers this all is quite good news.