A note on updates

Android Studio updates usually imply having fun. To me this looks like this…

Project needs updating #1

Project needs updating #2

Currently, I am in the process of updating my book. I already have updated 40 of 80 samples, so this nice thing means I enjoy the fun of doing this stuf 80 more times. 40 times for re-doing, and 40 times for the remaining projects. I am excited to see Android 7.1; will bring us a new API level I am sure, implying I could update the 80 samples once more. Winking smile


On editing fxml files with custom components in Scene Builder

Trying to open a .fxml file of a Gluon Mobile sample application in Scene Builder failed...

...for obvious reasons...

com.gluonhq.charm.glisten.mvc.View is no standard JavaFX control.

To make that class known to Scene Builder we just need to put it on its classpath. Right? The following screenshots describe a workaround when using NetBeans. If there are other, less archaic approaches, I'd love to hear them.

First we need the .jar file.

Now comes the interesting part. How to tell Scene Builder?

There is a config file called SceneBuilder.cfg. On my Windows machine it's situated in C:\Users\tkuen\AppData\Local\SceneBuilder\app.

Just quit Scene Builder and then put the fully qualified path right beside app.classpath=

Here is how Scene Builder will render another .fxml file contain Glisten controls. 

I do not consider myself a Scene Builder expert, so I may be missing a simpler solution. Also, it would be great to have custom components in the palette. Need to check that. Again, any hint is greatly appreciated.

Added Gluon-Port to OpenWeatherMapWeather

Yesterday I introduced you to a new repo of mine, which contains the same app for different platforms. Today I have added a Gluon port. The app as such is rather small. What is important about it is to see similarities as well as differences of the implementations.

Next on the agenda is a UWP app.


Added a repo to GitHub

In preparation of my workshop during Herbstcampus in Nuremberg later this summer, I pushed a repo to GitHub. Currently the repo contains two versions of a small sample app I call OpenWeatherMapWeather. Here is what we have so far:

I will add a version using Gluon and Windows 10 soon. So stay tuned.


Getting just a little more productive

Sometimes entering a command is just the fastest way to get something done. That's why Terminal or shell windows in IDEs come in so handy. Here is how it looks in Android Studio.

Just make sure all the tools you might need are found. I suggest a regular housekeeping of the PATH environment variable. For example, Android devs may wish to include $ANDROID_HOME/tools and $ANDROID_HOME/platform-tools. Java developers need $JAVA_HOME/bin. Of course, $ANDROID_HOME and $JAVA_HOME must point to the installation directories of the Android SDK and the Java Development Kit.

NetBeans offers a Terminal window, too.

There is a plugin called Terminal Extras. It helps setting a base directory upon invocation of the Terminal. You can download it through the Plugin Manager.

Just pick a project and hit Alt-.

Simple yet great.


A few tipps on finetuning lubuntu

I am currently preparing a Linux installation (VirtualBox client) based on Lubuntu. Though Lubuntu (as far as I know) is not specifically focussed on developers, its beauty lies in the fact that the distro is reasonably small. In this post I will share a few tips on finetuning it regarding developer needs.

Lubuntu after a couple of small changes running inside VirtualBox
Lubuntu after a couple of small changes running inside VirtualBox

As I need a really up-to-date Java development kit, I decided to download it directly from the Oracle website. Though this is mere personal taste, I like to put it in /opt and add a symbolic link without a version. This is convenient as I encourage you to include its bin directory in PATH. Switching Java versions can then be done be changing the link, rather than modifying PATH. This brings us to the question of where to change this environment variable. I chose .xsessionrc in my home directory. Why? Well, if another user doesn't want or need a JDK, I think he shouldn't see it.

 # Java (JDK)
export JAVA_HOME=/opt/jdk1.8
export PATH="$PATH:$JAVA_HOME/bin"

As I need Android Studio and the Android SDK as well, I set it up in .xsessionrc, too.

# Android
export ANDROID_HOME=/home/workshop/android
export PATH="$PATH:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools"

ANDROID_HOME comes in handy if you plan to use Gluon Mobile. Well, and access to the tools and platform-tools directory provides quick access to, for example, adb and emulator.

I did not know that I could have installed NetBeans through apt-get, so I downloaded it from the NetBeans homepage. The installer kindly put an entry in the Lubuntu desktop menu. As I wanted this for Android Studio, as well, I added that entry on my own. Here is how to do that. Provided, you have installed Android Studio to /opt/android-studio, just create a file called studio.desktop with the following contents and save it to /usr/share/applications.

[Desktop Entry]
Name=Android Studio
Exec=/bin/sh "/opt/android-studio/bin/studio.sh"

Finally: I am a big fan of Sublime Text 3. Here is how to install it.

sudo add-apt-repository ppa:webupd8team/sublime-text-3
sudo apt-get update
sudo apt-get install sublime-text-installer

That's it. Happen to have any other tips regarding Lubuntu? I'd love to hear them.


My upcoming workshop: Java on mobile devices

From Aug 30 til Sep 1 2016 Nuremberg once again will be home to the Herbstcampus, a conference for software developers, architects and managers focussing on Java, .Net, Mobile, Web and the enterprise.

I will have both the pleasure and honor of hosting a full-day workshop about Java on mobile devices. Titled Ménage à trois, we will be taking a closer look at how to build Android and iOS apps using Java and JavaFX. Based upon the open source project JavaFXPorts and its commercial sibling Gluon Mobile, we will build a few real-world apps and deploy them to both emulated and physical devices.

Interested? Take a look the the schedule:

Introduction of the participants
A little bit of history... Java on mobile devices
A first glimpse at the tools: emulators, simulators and virtualization

Coffee break

Setting up the development environment #2
Creating a project
Running the demo
Looking under the cover (walkthrough)

Lunch break

Gluon Mobile and its components
Using device functions #1
Artefact archeology - what finds its way on a device?
Using device functions #2

Coffee break

If something goes wrong (debugging)
What will not work (missing functions)
What's up? Profiling and performance

Coffee break

Taking a look at alternatives (including demos)
Reality check and wrap up

Sounds good? Remember the early bird offering ends tomorrow, Jul 22. Book now.


Yes it works

Have you tried to deploy a JavaFX app as a Web Start app and failed? Fear no more. The issue is easy enough to fix.

When I started my app as a Web Start app, I was greeted with these two fellows:

Screenshot: Runtime Error

Screenshot: Part of a stack trace

The error message seems obvious. Java is unable to find a resource. To be more precisely, it fails to find an fxml document. The usual diagnosis is... The resource is not there. Or... you are doing that getResources() wrong. 


To put a long story short. Not being able to find the resource here means not being able to access it. My Web Start app was sandboxed. As soon as I requested all_permissions, everything was fine.

So, for example, in a NetBeans project just request unrestricted access. Wham!

Screenshot: Granting a Web Start app unrestricted access


On analyzing Android class and package dependencies

Recently I had to analyze the class and package dependencies of an Android app. Jens Schauder maintains an awesome tool called Degraph. Its purpose is to test, visualize and manage dependencies of classes and packages in JVM byte code. So, I asked myself, why not use it?

Although the Google toolchain used to rely on standard Java byte code as an intermediate step, this may no longer be the case in the future. Its final artifact (the end of the toolchain if you like) consists of one or more Dalvik executables. If you take a look at an Android application package (.apk), you will find a file named classes.dex. Depending on the size of the app, there may be other, similarly named ones, too. As application classes as well as any dependent library are put there, I decided to use the .dex files for my dependency analysis.

The Android SDK contains a tool called dexdump. Its purpose is to provide a (nicely) readable representation of .dex files. Hence, all I needed to do was to bake a small tool that interprets dexdump output. You can find this tool here. It is written from scratch and is completely unrelated to Degraph. Still, I feel the need to credit Jens, especially for his idea to visualize the output of his tool using yEd.

You can extract classes.dex using tar xf. The screenshot shows a small portion of a dexdump output. To use it with my tool, you should create a text file as follows:

dexdump -l plain -f classes.dex > classes.txt

Let's see what DexAnalyzer can make out of it.

As you can see, by default analysis is based upon packages. The following screenshot shows how to distinguish classes and produce a file that can be opened in yEd.

I am going into more detail later. For now I encourage you to play with my tool. Please keep in mind that it is in its infancy. If you encounter any misbehavior, please feel free to let me know. Passing command line arguments seems to not work as expected if options appear after filenames. Also, please note that checked exceptions currently do not count as dependencies. I plan to add this later.


Developing inside the matrix

The Mac is still a lovely machine for developers. I enjoy the beauty of macOS, its slick ui and versatile commandline interface alike. Don’t get me wrong. I love Windows, too. That is why I have a Windows 10 running inside VirtualBox. This allows me to work with Visual Studio, for example in order to write Xamarin-Android-Apps. There is one issue, though. The current version of VirtualBox does not allow me to run Hyper-V, the Android Emulator utilizing HAXM, or any other virtualization technology. Para-virtualization is not easy to implement, I am sure. Other products appear to offer this feature, but one of the beauties of VirtualBox lies in being free.

So, what can we do about this?

As a VirtualBox client shares the network with its host, I asked myself why the Android Debug Bridge should not be able to find an emulator running on… the host.

So, I fired up Android Studio and Android Emulator on the Mac. Here is what I got.

Error message regarding VirtualBox

So while we may see a resolution in the future this does not help us now.

Other Android emulators appear to face the same fate.

Trying to run BlueStacks

So, are we left without options? Far from it… If VirtualBox is the only virtualizer that may run at a time, why not run Android inside VirtualBox? Just get an Android x86 image from the Android x86 project homepage, configure a client and install Android from the iso image. Make sure to configure a bridged network.

Once you have finished setup, you will be able to debug Android apps running inside VirtualBox from within another VirtualBox client.

Almost. A few steps remain to be taken.

First, get the ip adress of the emulated Android device. Open system settings, navigate to About Phone/Tablet and click on Status.

Second, open up the Terminal Eumlator app and enter the following command: adb tcpip 5555

The Terminal Emulator app

Third: On the virtualized Windows client, issue the following command: adb connect <device-ip-address>

Finally, use adb devices to verify that the connection has been established.

Executing adb commands

That is it.

Debugging an Android app inside VirtualBox from within VirtualBox on a Mac

Welcome inside the matrix.


Something to look forward to: Eclipse Neon

Neon, the Eclipse Foundation's eleventh annual simultaneous release, will be available June 22, 2016. This is something I am really looking forward to, as the platform finally catches up in high dpi environments. As documented in New and Noteworthy (Platform and Equinox):
SWT now automatically scales images on high-DPI monitors on Windows and Linux, similar to the Mac's Retina support on OS X. In the absence of high-resolution images, SWT will auto-scale the available images to ensure that SWT-based applications like Eclipse are scaled proportionately to the resolution of the monitor.
Something I have been longing for, too:
  • Commands and shortcuts to zoom in text editors
  • Pinch to zoom in text editors
And there is a plethora of further improvements and additions. This simultaneous release includes content from 85 Eclipse projects. Quite a few things to check out.

Ten years ago I started working on Einstieg in Eclipse 3.3. The book was published in 2007. Since then I have been watching Eclipse closely. Well, and four editions of the book followed. I hope to maintain this tradition. We will see. In the meantime, it is great to see and old friend healthy and prospering.


A little less clutter

Pondering on new features for TKMacTuning I came across the user settings of Acrobat Reader. Frankly, I don't like its recent files list. Not because my files are secret, but because I just do not need such a list. My machine collects data that simply is not used. Hence why collecting it in the first place? Let's get rid of it.

On a Mac, user settings usually are stored in the defaults database, which is a set of files residing in ~/Library/Preferences and /Library/Preferences. Those files end in .plist. You can display its contents on the command line by entering defaults read, for example defaults read com.adobe.reader | less. Searching for RecentFiles may reveal, to a little surprise, two or more data structures. The defaults database is heavily hierarchical; what is stored, and how, depends on the app that makes use of it. It turns out Adobe Reader has individual trees for different versions of the software. So I had entries for version 11 and DC.

The user interface of Adobe Acrobat Reader allows you to clear the list of recent files. However, this seems to have impact on the current version only. Because if I do so, the recent files list of the older version remains untouched. But why keep the settings for the old version at all? At the commandline I can issue defaults delete com.adobe.reader 11. This rids me of the old waste. The settings for DC are still intact.

To keep the app from storing the recent files lists does not require the commandline. In the Document settings you can just enter 0 as the number of recent files.


A glimpse at Android Studio 2.0 and the new emulator

Google has finished Android Studio 2.0 and has made it available in the stable channel.

In this post I will show you a few screenshots.

An update of the Gradle plugin is needed

An update of the Gradle plugin is needed

Revamped Deployment Target Dialog

Revamped Deployment Target Dialog

Emulator window with a control sidebar

Emulator window with control sidebar

Enhanced emulator settings

Enhanced emulator settings


An update on TKMacTuning

My hobby project TKMacTuning has made some progress in the past few days. Why not taking a look at its issues section? I'd love to see a few pull requests.


Just a handful lines of code…

Allow me to introduce you to… Image Snatcher…

Screenshot of Image Snatcher

On Windows 10 you can configure the lock screen to show beautiful pictures provided by Microsoft.

Configuring Windows 10 lock screen

Those photos are in fact so pretty, that sometimes I want to use them as my desktop wallpaper. Currently this is not possible out of the box. So I searched the net where the pictures might be stored. It appears to be AppData\Local\Packages\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy\LocalState\Assets.

Well. I wrote a small JavaFX app that displays the contents of this directory. If you move the mouse pointer over a preview image and click on Save, you get a file save dialog. Enter a filename and the picture is saved as a .png file. Also, you can show the image in the default image viewer.

The beauty of this app isn’t its visuals, but its line count. Roughly 230 lines of actual code. Getting a small app ready fast is possible with JavaFX, too. Sadly enough, beauty fades when it comes to actually distributing it. Yes, I could run the JavaFX packager, just to get tons of megabytes. I keep getting nostaligc, but letting go Project Vector was one of the worst ideas Oracle ever had.

Edited 2016/07/02: I removed the class from my BitBucket snippets and put a little more capable version on GitHub. Currently we have about 230 lines of code, but you can not only save the image, but show it in the default image viewer


A few more configurations for TKMacTuning

In the last couple of days I added a few new configurations to TKMacTuning. Though it certainly cannot compete with all the other fancy tuning apps for Mac OS X, it has a few nice features, I think.


Welcome Android N preview, welcome Java 8

Today, Google announced a very early Android N preview. During my talk at TopConf Linz  in February I speculated that we would be seeing Java 8 language features through the Jack compiler. Well, it'll be exactly that way.

Also, I am thrilled that they will introduce multi window support. Remember my post a few days before Christmass? I predicted that, too.

Awesome, it is great to see which direction Android is taking.


Revived an old project of mine: TKMacTuning

I'd like to introduce you to a long forgotten project of mine...

TKMacTuning aims to help you configure Mac OS X. It is written in Java/JavaFX and is published under the terms of the GNU General Public Licence version 3. I started working on TKMacTuning in 2008, but it soon got buried under a pile of other projects. Originally the app was planned to use Swing accompanied by the reference implementations of JSR-295 (Beans Binding) and JSR-296 (Swing Application Framework). You still can see that in the earliest commits. Sigh. Those were the days... Anyway, sometime I decided to do some JavaFX programming. I figured it might be a good idea to revive the project.

So, what does TKMacTuning do?

A lot of configuration in Mac OS X is done using a defaults database. There is a commandline tool called defaults to access it. The command is used as follows: defaults read com.apple.screencapture disable-shadow displays a particular setting. write changes values and delete removes entries. TKMacTuning will put a nice user interface on top of this. So you can change settings with checkboxes, comboboxes and file dialogs. Under the hood, the commandline tool is accessed.

So far, just a few settings have been implemented. The ones you see in the screenshots do work, however. In the coming months I hope to expand the scope significantly. For example, you will be able to change the login background window and configure the login screen. The ui will get nicer, too. Anyone interested in participating is more than welcome to clone the repo at GitHub.


The story so far...

Quite a lineup, isn't it? And there is more to come this year...
Tommis books


Thoughts on the mobile enterprise #9: Long term strategy

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

In part 8 we took a look at factors influencing the decision whether to make or buy a mobile app. I concluded by saying that the long term strategy of an organization has great influence on that matter.

Who can define the long term strategy of an organization primarily depends on its legal form. If the organization is an ordinary company, its destiny is ultimately controlled by the owner. He, of course, may delegate the task. This is also true if the ownership is shared among many people, as in corporations. In such scenarios, we usually find a chief information officer, who is in charge of everything related to information technology. Though he is not responsible for the long term strategy of the organization as a whole (which would be the chief execute officer), he needs to make sure his decisions comply with it. This might mean answering the question whether to build mobile apps.

The situation may be a little more complicated if the organization is public, such as authorities. Their organizational structure is determined by law, as is their long term strategy: public institutions are not supposed to make money, but to fulfill a specific purpose (for example ensuring the welfare of the people). Still, larger authorities do have chief information officers these days. Now, would he decide if his organization should build mobile apps? To answer that question, let us think about the term long term strategy a little bit more. 

For an ordinary company it might mean increase the market share by 5 percent within the next five years. How this can be achieved depends on the product the company is selling. If that is traditional desktop software, the company must seek new platforms, since the number of new personal computers being sold has been shrinking for quite a while, whereas smartphones and (to a lesser degree) tablets still sell like hotcakes. So, yes, that company should build mobile apps.

How about authorities? Here, part of the long term strategy might be increase the quality of service by, for example, making it easier to contact staff or to check if a claim has already been decided. It certainly makes sense to offer filling in forms or tracking status electronically (over the web). But does there have to be a (native) mobile app? I am by no means implying that there should not be one. I just want to stress that there has to be someone who weighs the benefits (increased level of service) and the costs (for developing the app).

To sum up, the long term strategy of an organization determines where the organization whats to be in five or ten years. This may have great influence on product development, recruitment and training of the personnel. It most certainly influences the decision whether to deal with mobile apps. Whether this means making or buying, has to be decided afterwards.


Thoughts on the mobile enterprise #8: Make or buy

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

In part 7 we took a look at different types of apps, in particular apps for employees. In this post we will focus on one of the most crucial yet underestimated questions: should a mobile enterprise app be developed in-house, or should development be outsourced?

Developing software on a larger scale requires a lot of processes be established and a lot of prerequisites be met. Consider these questions:
  • Are there enough people with the required skills available to develop and maintain the software?
  • Is a software development process in place, including guidelines, best practices and regulations?
  • Do developers and testers have access to required hardware?
  • Is the required hardware properly integrated in the overall infrastructure?
  • Are all necessary tools available?
  • Are all formal and legal prerequisites for bringing software into production met?
If an organization has already established development teams and corresponding infrastructure, those questions can probably be answered with yes. But what is true for traditional enterprise application development need not necessarily be the case for mobile enterprise app creation. Think of this: to build a native iOS app and to test it on a device you will need a Mac. Developers targeting Android may choose from a broader range of development machines, but if the infrastructure team decided to lock the usb ports, they are out of luck either. More on this later.

 Now, what factors do - or should - influence the decision whether to build a mobile enterprise app or to buy it? Take a look at this deliberately unordered list:
  • Time to market
  • Criticality
  • Dependency
  • Cost
  • Available skills
  • Long term reputation
  • Requirement
  • Perception
  • Strategy
Let us translate these words into pairs of questions:
  • Is it important to bring the app to market as fast as possible? Or is it vital to be best in class?
  • Is the release of the app an urgent necessity? Or is it more important to demonstrate ones capabilities?
  • Must development costs be as low as possible? Or are other factors more important?
It is clear that there is a tension between those factors. They influence each other. For example, although time to market and overall costs may suggest outsourcing development, the long term reputation (We did the app on our own) may be more valuable, even if this means setting up a mobile dev team from scratch. The other way round may also make sense, however: even if a team is capable (in terms of skills) of developing mobile enterprise apps, it simply may not be worth adapting processes, investing in infrastructure or tools, establishing rules and regulations, if that one project is expected (or wanted) to be a mayfly.

I am by no means implying that outsourcing development is necessarily cheaper than doing it in-house. Here, it serves only as an example. A valid and serious comparison of the costs has to take into account lots of figures, for example the organizational structure of the company, the subject (the app) and of course the offers of potential contractors.

The most important driving factor for mobile in-house development is the long term strategy of the organization. We will hear more on that in a later episode...


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.


Thoughts on the mobile enterprise #3

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

Part 3: Logical units

I concluded part 2 by saying that the business logic must be accessible from the outside world through some remote interface. What outside world really means, remains to be defined in a future post. For now it shall suffice to say accessible by a remote front end. This interface must reflect the whole functionality of the application. If it does, we meet the prerequisites I posted in part 2.

Applications need to be distributed.

If we have a remote user interface layer... Check.

Applications need to be properly layered.

You might frown upon this one. At this point I merely mean that the data access layer is properly separated from the business layer, which in turn is properly separated from the user interface layer. And the ui layer does not have direct access to the database layer (and vice versa). Nothing extraordinary, just well-behaved architecture. If this is something we see often, is, of course, another story...

Functionality must be accessible individually.

What does this mean? How do you structure an application in blocks or parts or components or services in a way that makes sense? Fortunately it is not up to me to answer these questions. I am in the comfortable position to just demand that these building blocks be there. ;-) To identify them, you can take a look at the use cases of an app (as a first step). Send a message. Dial a number. Send an email. Such simple sentences describe what an actor does to achieve something with or within a system.

Android uses this concept as one of the main building blocks for its applications. An activity is an action (for example, play a song) combined with a particular user interface (what the user sees on screen while the song is playing). If an activity wants to initiate another action it sends so-called intents. Hence, the action (play song) is the business logic (playing a song) combined with what the user sees on the display while the action takes place.

Another way to find individually accessible parts may be to look at business processes. Each step may be a candidate for a building block, especially if the step is reused among multiple business processes.

Let us stop here for now.

Imagine, your enterprise application is well structured. It consists of several components that implement the business logic. They can be accessed through some remote interface. 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?


Thoughts on the mobile enterprise #2

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

Part 2: Improvement to the worse?

In the first part we remembered that using full-fledged pc's for running the user interface of enterprise applications had become expensive. Each new application required a new front end on the client, which in turn reached its limits increasingly often. Keep in mind, that at that time (the first half of the first decade) there were no dual cores, no gigabytes of ram, no 64 bit systems, no gigabit Ethernet - at least not in the offices.

So, was the idea of building the user interfaces of enterprise applications using traditional client technologies bad? By no means. It offered tight integration with the client, for example by accessing local hardware (printer, scanner, chip card reader, ...), or to communicate with other apps. Today, Android developers take it for granted that they can utilize functionality of other apps simply by firing and consuming intents. In the early 2000s (and even before) that would have been possible, too. Typical Windows apps heavily relied on the component object model, which exposed functionality of a program to other apps. Sadly, competing technologies relied on incompatible object models. Out of the box, it was impossible to have a Java Swing-based client app talk to, say, MS Office, and vice versa. The constraints imposed by the hardware have already been mentioned. As I wrote in the first part of this series, the solution seemed simple.

A web browser seemed like a reasonable execution environment for user interfaces. If the user interface is rendered by the browser, there is no need for an additional rollout when a new enterprise application is introduced. What the browser would render, had to be prepared by the backend and then sent to the client. Hence, this transmission contains data and display instructions. User input is sent back to the backend and processed. Early web frameworks produced user interfaces that could not compete with well-designed rich client applications. No validation of user input, bad usability, delays due to server roundtrips, ... Even a decade later some aspects still require ridiculous workarounds. For example, have you asked yourself why generally agreed upon shortcuts (hotkeys) are not used in web based apps?

Anyway... This is not meant to be a rant against certain technologies. I am merely trying to set the stage for what I would like to call the mobile enterprise, that is, how organizations and their applications can embrace mobile devices. To do this, quite a few prerequisites must be met. A few of them are:

  • Applications need to be distributed.
  • Applications need to be properly layered.
  • Functionality must be accessible individually.

If a physically distant client program is used as the user interface of an enterprise application, there MUST be a public interface. If this was well-written and thoughtfully designed remains to be seen, but at least it is there. My experience is that in typical web apps the separation between business logic and the ui layer is often fuzzy, if present at all. If all melts into one single .war or .ear file, why bother a costly separation of layers? Test yourself. What is a front controller or a business delegate?

The take away of this part: the need to properly structure an application and to establish well-defined interfaces is as urgent as ever. How this can be achieved shall be the topic of a future installment.

Go to Thoughts on the mobile enterprise #1


Android to reach out for desktops?

You won't need a crystal ball to see the future of Android. Android is reaching out for the desktop. As ars technica points out in a superb article there is quite some way ahead. But there is already a lot there. Yes, right now there is no real window support (available to end users). But earlier reports made it clear that Google is working on supporting split screen windows, which we can see in Windows 10 and on the iPad Pro, and more. So, to take an educated guess, we will see this in Android 7. Once rolled out, it'll be up to Google and third party vendors alike to adapt their apps as fast as possible.
If the market wants another desktop-like system remains to be seen. Still, the Chromebooks have been quite a success. If Google is really planning to phase them out, Mountain View needs to make sure that the key advantages of Chrome OS are present in a future Android, too. Among others, these are...

  • low maintenance costs
  • reliability
  • stability
What do you think - is there a scenario you would trade your Mac OS X or Windows machine for a Android-based desktop or laptop?


Thoughts on the mobile enterprise #1

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

Part 1: Once upon a time

For a long time, the basic building blocks of enterprise applications were easy to choose: a programming language, a distributed component model infrasturcture, a relational database management system and a ui library. The database often resided on a dedicated database server, an (app) server hosted the business logic, and the ui was put on the client. The client usually was a Windows-based pc, running apps written in C++, Java, Basic, Pascal, or any other language the developer saw fit, the only prerequisite being access to some graphical user interface toolkit. Conceptionally, each enterprise application lived in its own world. Exchange of data with one of the few other applications was neither planned nor wanted. Why would department a share its information with department b?

And then came the problems.

Throughout the years, business processes became more complex. What once was done in one department, became a shared effort among several business units, requiring the use of several programs. Consequently, the users wanted the applications to cooperate with each other.

And then came the complaints.

Rolling out client software became expensive, time-consuming, prone to error. Building the user interface was said to be expensive, too. As was the necessity of frequently updating the hardware: more programs on the pc required more ram, bigger hard drives, faster cpus, networks with higher bandwidths. The solution seemed simple. If rolling out the ui is expensive, why roll it out at all? If upgrading the pc is expensive, why do an upgrade at all? The rise of the web brought a browser to every client (pc). Hence, wasn't it natural to use it as a runtime environment for the ui?

Let us stop here for a moment. As I have said at the beginning, enterprise applications used to be distributed: different layers ran on different pieces of hardware. Usually the ui layer (a program on a desktop pc) communicated with the business logic layer using some binary protocol, for example IIOP, RMI over IIOP or T3. The amount of data that needed to be transferred depended on the interface the business logic provided. If it was well designed, only small amounts of data had to be transmitted. And that data was just... data.

As we shall see in the second installment, this was going to change...


Reflections on a suggested coding convention

Today I read an interesting post by Sam Atkinson about a few new Java coding conventions. One of his suggestions is to use zero comments. While I am not saying the idea per se is wrong I am suggesting to stay open for exceptions. Consider this:

// manage your api key at http://www.example.com
private static final String apiKey = "...";

I think we agree that hinting at where to manage the api key is sensible. Any developer maintaining this code may have to manage the key. But if we remove the comment we need to pass the info elsewhere. I doubt that we should name a variable apiKeyCanBeManagedAtHttpWwwExampleCom. Should we?


Join me at TopConf Linz

Join me at TopConf Linz Feb 1-3 2016 Linz, Austria. I will be talking about Android and Java, subtle and not so subtle differences, origins and possible futures.

The title of the talk is Beyond Harmony: Java SE vs. Android. It's scheduled 2016-02-02 at 12:00. Abstract: It is common place that most Android apps are written in Java. But what does that mean? Are enhancements to the language available immediately, or can't they be used at all? Do developers benefit from improvements to the class library? This talk not only addresses these questions, but explains how to use features that are not meant to be available.


Touch is the new click (most of the time)

Recently, I made an interesting discovery. I found out that – while my computer was in touch mode – NetBeans did not respond to double taps. Generally speaking, double taps are a common gesture on touch devices, for example to expand or collapse nodes in tree views, or to open a file. Now you might argue that touch devices are not particularly well-suited for developing purposes, and therefore, it does not matter. That is true. The purpose of this post is to find out what is going on, as NetBeans is a very well-crafted Swing-based application, and it is quite unlikely that NB is doing something wrong here.

My machine is a Surface 3 Pro. If connected to the so-called Type Cover, it is an ordinary Windows 10-PC. The Type Cover has a keyboard and a trackpad which controls mouse pointer movements. In this mode, of course, double clicks on tree views work flawlessly. Touch mode kicks in if the Type Cover is removed. You can still see and use the desktop, and you can still use all apps. There is no mouse pointer, however, so which object is accessed depends on where you touch the screen with your finger. Single taps work like single mouse clicks. Double taps work like double clicks. Well, or should. To see if Java or Swing have issues here, I ran a pre-compiled SwingSet2. Double taps work as expected. So, I then wrote a small program that uses both JavaFX and Swing. Here is the source. And this is how it looks like:

Screenshot of a sample program

Tap detection works as expected, too. At least most of the time. Once in a while the double tap does not get delivered, though.
At that point, I decided to get the NetBeans sources and try to debug then. Building does take some time, but in the end I was able to debug NetBeans - in NetBeans. Guys, this is awesome. I decided to debug org.openide.explorer.view.TreeView. It attaches an instance of PopupSupport which in turn extends MouseAdapter to a ExplorerTree using addMouseListener(). Everything is fine here. Debugging shows that mouseClicked() is correctly called twice when not in touch mode, but only once when touch mode is active. When or where the tap gets lost still needs to be investigated. As of today I would assume that NB has nothing to do with this strange behaviour.


Auf Wiedersehen. Hello and welcome

Heute wende ich mich einmal nicht mit einem technischen Thema an Sie, liebe Leserin, lieber Leser. Dies ist der letzte Post auf Deutsch. Nicht, weil ich mein Blog schließe, sondern weil ich mich entschieden habe, ab sofort auf Englisch zu posten. Der einzige Grund hierfür ist, hoffentlich eine noch größere Leserschaft zu erreichen. Bitte bleiben Sie Tommis Blog dennoch gewogen. Vielen Dank.


Neues von Notes and Tasks

Erinnern Sie sich noch an meinen Ultimate Swing-Marathon, der irgendwann ein jähes Ende zu nehmen schien? Heute hatte ich mal wieder Lust, an der im Zuge der zahlreichen Blogposts entwickelten App Notes and Tasks zu schrauben. Da Google Code bald nicht mehr unter den Lebenden weilen wird, hatte ich das Repository im April nach Bitbucket migriert.
Die Codeänderungen beseitigen ein paar generics-Warnungen des Compilers und binden die App besser in Mac OS X ein. Konkret lässt sich der Programminfo-Dialog über die Menüleiste aufrufen. Gleiches gilt für die Settings. ...wobei es den dazu passenden Dialog in der Anwendung noch nicht gibt.

Vielleicht fragen Sie sich ja, warum ich mich mit diesem alten Kram befasse. Ich schraube einfach gern, und außerdem habe ich ja mal versprochen, eine schöne Notizanwendung zu bauen. Und da es JavaFX nicht besser geht als Swing, kann ich das gerne auch weiterhin mit Swing tun. ;-)


Ans Aufräumen denken

Seit ein paar Tagen gibt es Android Studio 1.5. Wer das Update gemacht und die Migration seiner alten Installation erfolgreich abgeschlossen hat, sollte prüfen, ob das alte Datenverzeichnis noch gebraucht wird. Denn auch in Zeiten großer Platten/SSDs lohnt es sich, gelegentlich zu entrümpeln.

Belegten Speicherplatz freigeben