RemoteUI FAQ

The RemoteUI Framework is a Java Library that allows you to build mobile applications for iOS and Android that run on the server. A RemoteUI app runs in a Java Web Container environment either bundled (Apache Tomcat) or installed as WAR into a JEE7 compliant runtime.

RemoteUI Clients on iOS and Android connect to such an app via a WebSocket connection. They render its user interface that they retrieve as binary layout descriptions. As the native SDKs on each platform are used for rendering, the apps look & feel like native applications.

During development and integration, you typically use the generic RemoteUI Clients, that allow connecting to every URL and have RemoteUI branding (splash screen, logo). As license holder, you typically customize the clients with a fixed URL, custom logo and splash screen for distribution via play store, app store or other means.

No.

As your app runs on the server, you never need to compile a mobile app package. You will compile a JAR or WAR and run it, which works on every platform. For the client, you use our Maven plugin to customize a RemoteUI Client package (IPA for iOS and APK for Android) with your logo, package and splash screen. This process can run locally on Linux, Windows and macOS.

No, you need at least a 2G internet connection. You may present a static layout in offline-mode.

The software architecture of the RemoteUI Framework provides some kind of a thin-client environment where the logic of an app runs on the server. This has many advantages over traditional mobile app approaches: The apps are cross-platform enabled, have super-fast startup and development times, offer direct backend integration, great tooling (debugging, performance analysis, runtime reload and preview) and a full JVM environment with the latest language features (JDK 8, 9, 10 …). A RemoteUI app can easily be deployed and updated. Java, Kotlin and Groovy developers do not need to learn new tooling and can work on every desktop platform, they prefer. These great features come at the cost of reduced offline capabilities.

There are two possibilities to offer offline capabilities for certain distinct use cases:

1. You can provide a single layout that will be displayed by the client when it is in offline mode. This layout can be updated at runtime, so you can use this functionality to provide an important set of information (e.g. shopping cart contents) when the user is offline.
2. RemoteUI is available as client-side library. It is possible to build a hybrid app that only partially uses RemoteUI to realize its functionality. With this approach, you can realize an app that offers offline-capabilities for certain use cases (including logic). At the moment, this functionality is only part of our enterprise licensing program.

Yes.

The RemoteUI Protocol has been designed to work with minimal bandwidth requirements. It uses a persistent connection, resource variant reduction, persistent layout caching, binary encoding, continuous compression and advanced image codecs to reduce the size of all transferred content to a minimum. Therefore, a RemoteUI app works in a 2G environment with bitrates from 150Kbit/s on. Our experience shows, that many other applications with backend access e.g. via JSON-based APIs already stop working, when RemoteUI apps are still running without problems. Our research has also shown, that the initial load of a RemoteUI app requires 5 to 150 times less traffic than loading a mobile web app.

You can run about 5000 simultaneous RemoteUI sessions per Gigabyte RAM.

RemoteUI apps run their logic and keep their state on a server. The state of an app is held in a traditional HTTP session. Therefore, it is possible for the RemoteUI client to reconnect to an existing session for the case of connection-loss or the app going into background because of an incoming phone call or other disruptions.

Holding state on the server means, that the main requirement for most RemoteUI apps is RAM. However, the RAM requirements are relatively small for the RemoteUI technology itself. The RemoteUI Framework never holds GUI-related object trees in memory like other UI technologies do (e.g. JavaServer Faces). Instead, only the Activity objects of an application and their dependent objects (typically your data), are held in memory. Additionally, memory is used for a shared LRU cache of compiled UI bindings and adapted layouts.

In a test with a productive app that used JPA/Hibernate to access a MySQL database and consisted of about 10 screens, we observed a data requirement per started session (that included a Hibernate Session in this case) of ca. 200KB. This means, this app could serve about 5000 simultaneous and active user sessions per Gigabyte RAM. We expect significantly better numbers for apps that use session-less persistence APIs as alternative.

It will detect it, inform the user adequately and realize session-continuation when being reconnected.

We have invested a considerable amount of effort to make the RemoteUI Client’s network library a super-robust piece of software, that can handle all kinds of network conditions gracefully. The library automatically measures round-trip times on the fly and triggers appropriate callbacks for user feedback. It uses message correlation with a piggy-backing approach to keep data requirements for this measurement at a minimum.

During user interaction, a 1.5 second delay is pre-configured for the detection of short time-outs, meaning, the server does not respond on user interaction within this time span. When such a time-out is reached, the RemoteUI Client automatically shows a spinning progress bar on top of the user interface to inform the user, that her input has been accepted but needs time for processing.

If the server response takes longer than 10 seconds, the library triggers the long time-out and the RemoteUI Client supposes, that the connection has been lost. It switches to a reconnect dialog to let the user decide on whether to try a new connection or close the application.

Short and long time out mechanisms apply during user-interaction with the app. Additionally, keep-alive messaging is applied during times of no interaction. Every 25 seconds, the client sends a WebSocket keep alive message, expecting the server to respond within the short and long time-out periods respectively. If no adequate response is retrieved, progress spinner and reconnect dialog are applied as described above.

Of course, the library reacts on a gracefully closed TCP-connection, e.g. triggered by a server-shutdown or the user switching off Wifi or cellular networking on the mobile device. In all cases, the connect dialog is automatically displayed.

During reconnection, a session cookie is transferred as part of the WebSocket request. If the session on the server is still alive, which is typically the case for 20 minutes, the app is opened where it was last seen. The user can continue where she left.

Only for certain logic of your app. Typically not for the RemoteUI Activities.

Sure, you can run JavaScript as part of every Java application. The same is true for your RemoteUI app on the server. You can use Java’s built-in Nashorn engine or V8 Java bindings to realize this. It will however be a bit tricky to use npm, if you plan for this. You could have a look on GraalVM to find a way of mixing RemoteUI’s Java implementation with your npm-related workflow. Please let us know, if you made it ;-).

The free version of RemoteUI is meant for trying out the technology without any qualitative restrictions. As you know, our main concern is simplicity and speed for developers, giving you the best tools to realize a fast time-to-market. Giving the free version to you without asking for time-consuming registration or payment processes and without any trial period restricting your evaluation phase is one of the approaches to make your life easier. At the end, we know, that the RemoteUI Framework will save you a lot of time and money, when you are going productive. For the latter case, we like you to get a paid license. Therefore, the following restrictions have been imposed on the free version:

• The free variant of the RemoteUI Client does not support transport encryption (TLS).
• The free version of the RemoteUI Framework restricts the number of concurrent simultaneous connections to 5.
• Without a paid account, you cannot build your own installable app packages with logo, package name and branding.
• You retrieve basic community support only.

With this approach, you have no restrictions when developing an app and demonstrating it to possible customers. If you are going in production and want to publish your app in the play store or app store, a paid license is required.

Yes.

Your app will work as long as OS updates don’t enforce updates for client or server components. Typically, Apple and Google provide major upgrades for their mobile OSs once a year. You should be prepared to test your app with them and possibly update to the latest RemoteUI version, if anything does not work. For the update, a license is required.