Developing Applications

Development Concepts and Overview

When you develop your app with the Persistent Mobile Foundation set of tools, you must develop or configure a variety of components and elements. Learning about the components and elements involved when developing your app helps your development proceed smoothly.

In addition to getting familiar with these concepts, you will also learn about PMF-provided APIs for Native, Cordova and Web applications, such as JSONStore and WLResourceRequest, as well as learn how to debug applications, use Direct Update to refresh the web resources, Live Update to segment your userbase as well as how to handle apps, adapters and other artifacts using the PMF CLI.

You can either navigate to the relevant topic from the sidebar navigation, or continue reading to learn more about the various PMF components.

Jump to

Applications

Applications are built for a target PMF and have a server-side configuration on the target server. You must register your applications on the PMF before you can configure them.

Applications are identified by the following elements:

  • An app ID
  • A version number
  • A target deployment platform

Note: The version number is not applicable to web applications. You cannot have multiple versions of the same web application.

These identifiers are used on both the client-side and the server-side to ensure that apps are deployed correctly and use only resources that are assigned to them. Different parts of PMF use various combinations of these identifiers in different ways.

The app ID depends on the target deployment platform:

Android
The identifier is the application package name.

iOS
The identifier is the application bundle ID.

Web
The identifier is a unique ID that is assigned by the developer.

If the apps for different target platforms all have the same app ID, then the PMF considers all of these apps to be the same app with different platform instances. For example, the following apps are considered to be different platform instances of the same app:

  • An iOS app with a bundle ID of com.mydomain.pmf.
  • An Android app with a package name of com.mydomain.pmf.
  • A web app with an assigned ID of com.mydomain.pmf.

The target deployment platform for the app is independent of whether the app was developed as a native app or as a Cordova app. For example, the following apps are both considered to be iOS apps in PMF:

  • An iOS app that you develop with Xcode and native code
  • An iOS app that you develop with Cordova cross-platform development technologies

Note: The Keychain Sharing capability is mandatory while running iOS apps in the iOS simulator when using Xcode 15. You need to enable this capability manually before building the Xcode project.

Application configuration

As mentioned, an application is configured on both the client-side and the server-side.

For native and Cordova iOS, Android applications, the client configuration is stored in a client properties file (mfpclient.plist for iOS, mfpclient.properties for Android). For web applications, the configuration properties are passed as parameters to the SDK initialization method.

The client configuration properties include the application ID and information such as the URL of the PMF runtime and security keys that are required to access the server.
The server configuration for the app includes information like app management status, web resources for Direct Update, configured security scopes, and log configuration.

Learn how to add the PMF client SDKs in the Adding the PMF SDK tutorials.

The client configuration must be defined before you build the application. The client-app configuration properties must match the properties that are defined for this app in the PMF runtime. For example, security keys in the client configuration must match the keys on the server. For non-web apps, you can change the client configuration with the PMF CLI.

The server configuration for an app is tied to the combination of app ID, version number, and target platform. You must register your app to a PMF runtime before you can add server-side configurations for the app. Configuring the server side of an app is typically done with the PMF Operations Console. You can also configure the server side of an app with the following methods:

You can also use these methods to automate configuration of the PMF.

Remember: You can modify the server configuration even while a PMF is running and receiving traffic from apps. You do not need to stop the server to change the server configuration for an app.

On a production server, the app version typically corresponds to the version of the application published to an app store. Some server configuration elements like the configuration for app authenticity, are unique to the app published to the store.

PMF Server

The server-side of your mobile app is the PMF server. PMF server gives you access to features like application management and application security, as well as giving your mobile app secure access to your other backend systems through adapters.

PMF server is the core component that delivers many PMF features, including the following features:

  • Application management
  • Application security, including authenticating devices and users and verifying application authenticity
  • Secure access to backend services through adapters
  • Updating Cordova app Web resources with Direct Update
  • Push notifications and push subscriptions
  • App analytics

You need to use PMF server throughout your app’s lifecycle from development and test through to production deployment and maintenance.

A preconfigured server is available for you to use when you develop your app. For information about the PMF server to use when you develop your app, see Setting up the PMF Development Environment.

PMF consists of the following components. All of these components are also included in the PMF. In simple cases, they are all running on the same application server, but in a production or test environment, the components can be run on different application servers. For information about possible topologies for these PMF components, see Topologies and network flows.

PMF server and PMF administration service

The PMF Operations console is a web interface that you can use to view and edit the PMF server configurations. You can also access the PMF Analytics Console from here. The context root for the operations console in the development server is /mfpconsole.

The administration service is the main entry point for managing your apps. You can access the administration service through a web-based interface with the PMF Operations Console. You can also access the administration service with the pmfadm command-line tool or the administration service REST API.

Learn more about the PMF Operations Console features.

PMF runtime

The runtime is the main entry point for a PMF client app. The runtime is also the default authorization server for the PMF OAuth implementation.

In advanced and rare cases, you can have multiple instances of a device runtime in a single PMF. Each instance has its own context root. The context root is used to display the name of a runtime in the operations console. Use multiple instances in cases where you require different server-level configuration such as secret keys for keystore.

If you have only one instance of a device runtime in PMF, you do not typically need to know the runtime context root. For example, when you register an application to a runtime with the pmfdev app register command when the PMF has only one runtime, the application is registered automatically to that runtime.

PMF push service

The push service is your main access point for push-related operations like push notifications and push subscriptions. To contact the push services, client apps use the URL of the runtime but replace the context root with /mfppush. You can configure and manage the push service with the PMF Operations Console or the push service REST API.

If you run the push services in a separate application server from the PMF runtime, you must route the push service traffic to the correct application server with your HTTP server.

PMF Analytics Receiver and PMF Analytics Console

Persistent Mobile Foundation Operational Analytics Receiver is an optional component that provides an analytics and logger log forwarder feature that can be used by mobile apps to forward analytics and logger logs to Persistent Mobile Foundation Operational Analytics. Usage of this service will free up the log handling done by PMF.

Persistent Mobile Foundation Analytics and PMF Analytics Console

Persistent Mobile Foundation Operational Analytics is an optional component that provides a scalable analytics feature that you can access from the PMF Operations Console. This analytics feature lets you search for patterns, problems and platform usage statistics across logs and events that are collected from devices, apps, and servers.

From the PMF Operations Console, you can define filters to enable or disable data forwarding to the analytics service. You can also filter the type of information that is sent. On the client side, you can use the client-side log capture API to send events and data to the analytics server.

After you install and configure PMF into the topology that you want, any further configuration of PMF and its applications can be done entirely through any of the following methods:

  • The PMF Operations Console
  • The PMF administration service REST API
  • The pmfadm command-line tool

After the initial installation and configuration, you do not need to access any application server console or interface to configure PMF.
When you deploy your app to production, you can deploy your app to the following PMF production environment:

On-premises

For information about installing and configuring PMF server for your on-premises environment, see Installing PMF.

Adapters

Adapters in PMF securely connect your back-end systems to client applications.

You can write adapters in either JavaScript or Java, and you can build and deploy adapters as Maven projects.
Adapters are deployed to a PMF runtime in PMF server.

In a production system, adapters typically run in a cluster of application servers. Implement your adapters as REST services with no session information and stored locally on the server to ensure that your adapter works well in a clustered environment.

An adapter can have user-defined properties. These properties can be configured on the server side without redeploying the adapter. For example, you can change the URL that your adapter uses to access resources when you move from test to production.

You can deploy an adapter to a PMF runtime from the PMF Operations Console, by using the pmfdev adapter deploy command, or directly from Maven.

Learn more about adapters and how to develop JavaScript and Java adapters in the Adapters category.

Client-side tutorials to follow

▲
Last modified on