Soluling home   Document home

About Mobile and Tablet applications

About Mobile and Tablet applications

Recently it has become popular to write the same application for all popular mobile and tablet platforms. There are many ways to reach this goal. No matter what you choose or have already chosen, you can use Soluling to localize your applications and reuse translations between different applications and platforms.

Native applications

The most obvious way to build a mobile application is to make a native application. This means that you use the default programming language, the standard development tool, the native API, and the development OS.

Platform Programming language IDE SDK Development OS
Android Java Android Studio, Eclipse, Visual Studio, or Delphi Android SDK

Windows, Mac, or Linux

iOS Swift XCode, Visual Studio, or Delphi Cocoa Touch Mac
Universal Windows Platform C# or Visual Basic Visual Studio UWP SDK Windows
Sailfish C++ QtDeveloper Qt Windows, Mac, or Linux

As you can see, the development toolchains are different on each platform. You need to master several programming languages (C++, Java, C# and Swift), several development tools (Android Studio, XCode, Visual Studio and QtDeveloper), learn several APIs (Android SDK, Cocoa Touch, UWP SDK, and Qt) and also use at least two development computers (Windows and Mac). The process is not easy but is needed if you want to provide the best possible user experience for your clients. In most cases, you will need several programmers or teams, one for each platform.

Once you have written your applications, the localization process is easy because now you need only one tool: Soluling. It can localize all your native mobile applications. You can reuse translations of one application in other applications. The localization process is also very similar. When localizing Android applications, the only file you need is the application file (.apk in Android). Soluling reads the original application file and creates either localized application files or one multilingual application file. Files created by Soluling are instantly ready to be deployed. When localizing iOS, UWP, and Qt application you need the resource files (.strings/.storyboard/.xib in iOS, .resx/.xaml in UWP, .ts/.qml in Qt). Soluling reads the original resource files and creates localized resource files. Finally, you compile the multilingual application file and create a deployment package. If you want to localize the resource source files instead of the compiled application file, Soluling can do that for Android, too (.xml).

Using cross platform tools

If you don't want to maintain several projects but want to have only one, then one choice it to use a cross-platform tool. There are several cross-platform tools, but only a few are suitable for mobile development: Xamarin, Embarccadero's FireMonkey (Delphi). Xamarin supports Android and iOS (and desktop operating systems). FireMonkey also supports Android and iOS (and desktop operating systems).

Xamarin is probably the most popular cross-platform tool. It uses C# and Visual Studio. Developers can share some of the code between different platforms. You can either use Xamarin's user interface abstraction layer (Xamarin forms) or use a platform's own native user interface framework.

FireMonkey uses Object Pascal or C++ language and its IDE that is either Delphi or C++Builder. FireMonkey has several advantages over both Xamarin and Java-based frameworks. First is speed. FireMonkey compiles native applications that do not require any runtime or virtual machine. This makes FireMonkey application as fast as native applications. FireMonkey also supports modern mobile APIs such as multi-touch, location, and sensors. Another advantage is a UI abstraction layer. You can use the same UI for all platforms. This is also the biggest disadvantage of FireMonkey compared to native development. FireMonkey's user interface is almost the same as native it is not quite right. This not quite the right user interface may feel a little bit odd for some users. If this is acceptable, FireMonkey provices a fast and cost-effective alternative to native applications. Firemonkey Localization process is simple. You select the Delphi project file (.dproj), and Soluling creates a multilingual resource file that you add to your application.

HTML 5

If you want even more platform independency than the cross-platform tools can provide, your choice is HTML 5. HTML 5 applications are basically web applications, but all UI code is run on the device. If you need more sophisticated UI than basic HTML can provide you can use HTML 5's canvas object that is very flexible. Most HTML 5 applications can run on any device. Compared to native applications and even cross-platform applications, the user experience is more limited, but development cost can be fractions of those of native applications.

The localization process is similar to web applications. You select page (.html) and script (.js) files. Soluling creates localized page and script files.

Comparing methods

The following table shows some pros and cons of each development methods:

Method Pros Cons
Native
  • UI is right
  • Best user experience
  • Full API
  • Maximum speed
  • Application is accepted to the market place
  • Multiple projects
  • Multiple tools
  • Multiple programming languages
  • Multiple teams
  • Expensive
Cross platform
  • One project
  • One tool
  • One language
  • One team
  • More cost effective
  • UI is not quite right
  • User experience might not be perfect
  • Some API limitations
  • Possible speed issues
HTML 5
  • One project
  • One tool
  • One language
  • One team
  • Works also on desktop platforms
  • Will also work on future devices and platforms
  • More cost effective
  • UI is not native and does not even look like native
  • Limited API
  • Speed issues
  • Some limitations on marketplaces

No matter what method you use, you can easily localize your applications with Soluling.

Visual editors

Visual editors are essential for localization. To properly localize UI strings, you need to know what is the context of the string and what is the space available for the string. Soluling uses native visual editors. It means that each platform has its own visual editor that uses the native control of the platform. Visual C++ editor uses the standard Windows controls, the Delphi editor uses the Delphi components, etc. This works well as long as the operating system where the localization tool run can run the code of the platform. Unfortunately, this is not the case with mobile platforms. The actual application can only be run on the device or on the emulator. This means that the visual editor can not use the native code when it shows the user interface. Instead, it uses code that mimics the platform code. This gives you a general idea about the user interface, but the visual presentation is not 100% accurate.

The mobile user interface brings some challenges that are not present on desktop user interfaces. First of all, the mobile screen is much smaller. This makes many mobile UI is very compact, and there is not that much space for strings expansion. Translated strings may be considerably longer than the original string. Visual editor and validation checkers help, but because the editor is not 100% accurate, you might need some extra checking. This checking is maximum strings length. Soluling can check the length of the translations you enter. The checking can be done either by a character count of my pixels. If you specify a maximum length, then Soluling does not let you enter translation that would be longer than the limit. To make checking as accurate as possible, Soluling tries to figure out the exact font used in that context. If the font can not be detected, then you can enter it.

Another mobile-specific issue is the user interface orientation. The user can rotate the device from portrait to landscape and back. When rotated, the system usually layouts the application again. Soluling's visual editor contains a rotate and size buttons that help to quickly check how the translated user interface works on different orientations and screen sizes.

Visual editors and length checkers make sure that your translated user interface works as well as the original one.