Known limitations
General limitations apply to IBM MobileFirst Platform Foundation as detailed here. Limitations that apply to specific features are explained in the topics that describe these features.
In this documentation, we can find the description of IBM MobileFirst Platform Foundation known limitations in different locations:
- When the known limitation applies to a specific feature, we can find its description in the topic that explains this specific feature. Then immediately identify how it affects the feature.
- When the known limitation is general, that is, applies to different and possibly not directly related topics, we can find its description here.
For more information about product known limitations or issues, see Known issues.
Globalization
If you are developing globalized apps, notice the following restrictions:
- Part of the product IBM MobileFirst Platform Foundation v6.3.0, including its documentation, is translated in the following languages: Simplified Chinese, Traditional Chinese, French, German, Italian, Japanese, Korean, Portuguese (Brazil), Russian, and Spanish. Only user-facing text is translated.
- The MobileFirst Studio and MobileFirst Operations Console provide only partial support for bidirectional languages.
- The applications that are generated by IBM MobileFirst Platform Foundation are not fully bidirectional enabled. Mirroring of the graphic user interface (GUI) elements and the control of the text direction are not provided by default. However, there is no hard dependency from the generated applications on this limitation. It is possible for the developers to achieve full bidi compliance by manual adjustments in the generated code.
- Although translation into Hebrew is provided for MPF core functionality, some GUI elements are not mirrored.
- In MobileFirst Studio and MobileFirst Operations Console, dates and numbers might not be formatted according to the locale.
- Names of projects, apps, adapters, Dojo custom builds and Dojo library projects must be composed only of the following characters:
- Uppercase and lowercase letters (A-Z and a-z)
- Digits (0-9)
- Underscore (_)
Some examples of the problems that you might encounter if the names of the Dojo library projects are NL strings are the incorrect display of the UI pattern preview, the failure of the generation of the Dojo custom build, and the failure to display the NL string in the Dojo custom build console.
- There is no support for Unicode characters outside the Basic Multilingual Plane.
The Server Configuration Tool has the following restrictions:
- The descriptive name of a server configuration can contain only characters that are in the system character set. On Windows, it is the ANSI character set.
- Passwords containing single quotation mark or double quotation mark characters might not work correctly.
- The console of the Server Configuration Tool has the same globalization limitation as the Windows console to display strings that are out of the default codepage.
IBM MobileFirst Platform Operational Analytics has the following limitations in terms of globalization:
- In reports, the format for dates and times do not follow the International Components for Unicode (ICU) rules.
- In reports, the format for numbers does not follow the International Components for Unicode (ICU) rules.
- In reports, the numbers do not use the user's preferred number script.
- In reports, searching for Chinese, Japanese, and Korean characters (CJK) returns no results.
- Messages that include non-ASCII characters and created with the log method as defined in the WL.Analytics class, or with the error method as defined in the WL.Logger class are not always logged successfully.
- The Analytics page of the MobileFirst Operations Console does not work in the following browsers:
- Microsoft Internet Explorer version 8 or earlier
- Apple Safari on iOS version 4.3 or earlier
- On Mozilla Firefox browser and Google Chrome browser, the locale used to display dates and time might differ from the locale set for the browser.
- The dates on the X-axis are not localized.
You might also experience restrictions or anomalies in various aspects of globalization because of limitations in other products, such as browsers, database management systems, or software development kits in use. For example:
- You must define the user name and password of the Application Center with ASCII characters only. This limitation exists because IBM WebSphere Application Server (full or Liberty profiles) does not support non-ASCII passwords and user names. See Characters that are valid for user IDs and passwords.
- On Windows:
- To see any localized messages in the log file that the test server that is embedded in MobileFirst Studio creates, you must open this log file with the UTF8 encoding.
- In the test server console in Eclipse, the localized messages are not properly displayed.
These limitations exist because of the following causes:
- The test server is installed on IBM WebSphere Application Server Liberty profile, which creates log file with the ANSI encoding except for its localized messages for which it uses the UTF8 encoding.
- The test server console in Eclipse displays the content using the ANSI encoding, not the UTF8 encoding.
- In Java 7.0 Service Refresh 4-FP2 and previous versions, we cannot paste Unicode characters that are not part of the Basic Multilingual Plane into the input field. To avoid this issue, create the path folder manually and choose that folder during the installation.
- Custom title and button names for the alert, confirm, and prompt methods must be kept short to avoid truncation at the edge of the screen.
- The applications that are developed with MobileFirst Application Framework running in Portuguese (Portugal) will see runtime messages in Portuguese (Brazil).
- JSONStore does not handle normalization. The Find functions for the JSONStore API do not take account of language sensitivity such as accent insensitive, case insensitive, and 1 to 2 mapping.
- The sorted results of JSONStore Find API are not language-specific and not compliant with Common Locale Data Repository (CLDR) rules.
Application Center mobile client
The Application Center mobile client follows the cultural conventions of the running device, such as the date formatting. It does not always follow the stricter International Components for Unicode (ICU) rules.
The Application Center mobile client for BlackBerry has the following known limitations:
- It supports only a limited set of languages. In particular, it does not fully support right-to-left languages, such as Arabic and Hebrew.
- It does not support Unicode characters outside the Basic Multilingual Plane.
- It supports Unicode characters inside the Basic Multilingual Plane but how these characters are displayed depends on the fonts that are available on the device
Application Center mobile client: refresh issues on Android 4.0.x
Android 4.0.x WebView component is known to have several refresh issues. Updating devices to Android 4.1.x should provide a better user experience.
If you build the Application Center client from sources, disabling the hardware acceleration at the application level in the Android manifest should improve the situation for Android 4.0.x. In that case, the application must be built with Android SDK 11 or later.
Rich Page Editor
The Rich Page Editor fails to show the page when the code that initializes it attempts to communicate with MobileFirst Server.
The Rich Page Editor simulates the mobile device environment without any connection to a real server. If the code that initializes the page tries to communicate with MobileFirst Server, a failure occurs. Because of this failure, the page content remains hidden, and we cannot use the Design pane of the Rich Page Editor.
As an example, a failure occurs if the page calls an adapter procedure in the wlCommonInit() function or the wlEnvInit() function.
In general, however, the initialization code is not strictly necessary to get a reasonable visual rendering of the page. To avoid this limitation, temporarily remove the "display: none" style from the body element in the page. Your page then renders even if the initialization functions do not execute completely.
The standard Eclipse editor does not handle UTF-8 with the BOM (byte order mark) properly, therefore the Rich Page Editor does not support UTF-8 with byte order mark.
The Rich Page Editor supports jQuery mobile 1.4.2. It does not support jQuery mobile 1.4.1
JSONStore resources for iPhone and iPad
When you develop apps for iPhone and iPad, the JSONStore resources are always packaged in the application, regardless of whether you enabled JSONStore or not in the application descriptor. The application size is not reduced even if JSONStore is not enabled.
Analytics page of the MobileFirst Operations Console
Response times in the Analytics page of the MobileFirst Operations Console depend on several factors, such as hardware (RAM, CPUs), quantity of accumulated analytics data, and IBM MobileFirst Platform Operational Analytics clustering. Consider testing the load before integrating IBM MobileFirst Platform Operational Analytics into production.
Deployment of an app from MobileFirst Studio to Tomcat
If we use Tomcat as an external server in Eclipse (for example to test and debug the applications directly in MobileFirst Studio), the following restrictions apply:
- The context path set to the project is ignored. When you deploy the app from MobileFirst Studio to Tomcat, the default context path, which is the project name, is used instead of the context path. The URL of the MobileFirst Operations Console for your app similarly uses the project name.
- When you deploy the app from MobileFirst Studio to Tomcat, the deployed WAR file is not visible in the Server view of Eclipse (in MobileFirst Studio), even if the application is correctly deployed.
To avoid these issues, keep the default value of the context path of the project, which is the project name.
IBM MobileFirst Platform Foundation components cannot contain multiple environments
During the creation of a MobileFirst component, you include Android as well as iPhone or iOS environments. The addition of the same component fails because it contains multiple environments.
Separate MobileFirst component needs to be created for each environment, such as Android, iOS or iPhone.
Installation on a cluster of IBM WebSphere Application Servers Liberty profile that you administer with a collective controller
The following limitations apply if you install MobileFirst Server on a cluster of IBM WebSphere Application Servers, Liberty profile, that you administer with a collective controller:
- The Application Center installation with the MobileFirst Server installer does not use the collective controller. You must install MobileFirst Server on each server separately.
- The MobileFirst Operations Console installation with the <configureApplicationServer> Ant task does not use the collective controller. You must run the <configureApplicationServer> Ant task for each server separately.
No white space with Eclipse workspace path
The MobileFirst Development Server (an instance of the WebSphere Application Server Liberty profile server) cannot handle an Eclipse workspace path with white space. As a result, a simple app cannot be deployed or previewed. Do not use an Eclipse workspace path with white space.
Installation of a fix pack or interim fix to the Application Center or the MobileFirst Server
When you apply a fix pack or an interim fix to Application Center or MobileFirst Server, manual operations are required, and you might have to shut down your applications for some time. See Upgrading to MPF v6.3.0 or Upgrading to MobileFirst Server v6.3.0 in a production environment.
FIPS 140-2 feature limitations
The following known limitations apply when we use the FIPS 140-2 feature in IBM MobileFirst Platform Foundation:
- This FIPS 140-2 validated mode applies only to the protection (encryption) of local data that is stored by the JSONStore feature and protection of HTTPS communications between the MobileFirst client and the MobileFirst Server.
- For HTTPS communications, only the communications between the MobileFirst client and the MobileFirst Server use the FIPS 140-2 libraries on the client. Direct connections to other servers or services do not use the FIPS 140-2 libraries.
- This feature is only supported on the iOS and Android platforms.
- On Android, this feature is only supported on devices or simulators that use the x86 or armv7 architectures. It is not supported on Android using armv5 or armv6 architectures. The reason is because the OpenSSL library used did not obtain FIPS 140-2 validation for armv5 or armv6 on Android.
- On iOS, it is supported on i386, armv7, and armv7s architectures. FIPS is not yet supported on 64-bit architecture even though MobileFirst library does support 64-bit architecture. Therefore, FIPS must not be enabled on 64-bit target platform when XCode Build Setting (Architecture) is also set to 64 bit.
- This feature works with hybrid applications only (not native).
- The use of the user enrollment feature on the client is not supported by the FIPS 140-2 feature.
- The Application Center client does not support the FIPS 140-2 feature.
For more information about this feature, see FIPS 140-2 support.
Support for Android Emulator 2.3.x
MPF does not support Android Emulator 2.3.x because of known issues, as detailed in the Android list of issues at https://code.google.com/tech/android/issues/list (search for issue 12987).
User Certificate Authentication feature limitations
The following known limitations apply when using the User Certificate Authentication feature in IBM MobileFirst Platform Foundation:
- This feature is available only on the hybrid iOS and Android environments for this current release.
- This feature is not supported with the FIPS 140-2 feature.
- This feature is supported on WebSphere Application Server and WebSphere Application Server Liberty profile.
- This feature does not support an environment where the MobileFirst Server is protected by container security that requires a CLIENT-CERT authentication method. Instead, the server must be configured to accept the client certificate optionally, and not require one.
- Self-signed certificates are not supported with the User Certificate Authentication feature.
- This feature cannot be used when we use the IBM HTTP Server between the client device and the MobileFirst Server. The IBM HTTP Server is unable to provide user identity to the MobileFirst Server after authenticating with the client certificate.
LTPA token limitations
An SESN0008E exception occurs when an LTPA token expires before the user session expires.
An LTPA token is associated with the current user session. If the session expires before an LTPA token expires, a new session is created automatically. However, when an LTPA token expires before a user session expires, the following exception occurs:
com.ibm.websphere.servlet.session.UnauthorizedSessionRequestException: SESN0008E: A user authenticated as anonymous has attempted to access a session owned by {user name}
To resolve this limitation, you must force the user session to expire when the LTPA token expires.
- On WebSphere Application Server Liberty, set the httpSession attribute invalidateOnUnauthorizedSessionRequestException to true in the server.xml file.
- On WebSphere Application Server, add the session management custom property InvalidateOnUnauthorizedSessionRequestException with the value true to fix the issue.
On certain versions of WebSphere Application Server or WebSphere Application Server Liberty, the exception is still logged, but the session is correctly invalidated. See APAR PM85141.
Support of Oracle 12c by MobileFirst Server
The installation tools of the MobileFirst Server (Installation Manager, Server Configuration Tool, and Ant tasks) support installation with Oracle 12c as a database with the same limitations as in Use complex Oracle connection descriptors.
The database and database users must be created before you run the installation tools. The connection information must be entered using a JDBC URL. See Use complex Oracle connection descriptors.
Liberty server limitations
If we use the Liberty studio server on a 32-bit JDK 7, Eclipse might not start, and you might receive the following error: Error occurred during initialization of VM. Could not reserve enough space for object heap. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.
To fix this issue, use the 64-bit JDK with the 64-bit Eclipse and 64-bit Windows. If we use the 32-bit JDK on a 64-bit machine, you might configure JVM preferences to mx512m and -Xms216m.
Parent topic: Release notes