The MDApplication class contains the minimal functionality to start an application. You should use it in all projects and refactor old projects which use the deprecated Application class. For detailed information on migration, see Migrating to the New Run-Time Classes. The MDApplication class is the application’s entry point. You must subclass it to start an application. You can override the init() method to initialize some resources or variables. This method is called only once just after the MDApplication instance was created. If you override this method, you must call super.init() to initialize internal bits by MDApplication.

To provide your own content, you must override the getMainWindow() method and return a new nUIWindowDisplay object with the views you want to show.

In contrast to the deprecated run time, the new run time does not spawn any additional thread. Instead, it uses a native main thread in which the particular application was started. All Mobile Designer callbacks are called on this main thread. You should return as fast as possible to avoid UI freezes. All CPU-intensive tasks or tasks that wait for response should be executed asynchronously. To run tasks asynchronously, you can use runAsync methods provided in the MDApplication class.

The MDApplication class resides in the nativeUI library, and it assumes that nativeUI library is used in the project.

When Mobile Designer runs the resource handler that you create for your project, it automatically creates the Parameters static class, which contains the parameters that drive the Mobile Designer run-time code for a particular build. The Parameters class, com.softwareag.mobile.runtime.Parameters, contains information about the devices and project-specific parameters, such as resource, resource block, and text IDs.

Mobile Designer uses the following naming conventions for the parameter names:

When the remaining run-time classes are not used in a project, you can generate the Parameters class by reference in third-party code.