This chapter includes the following sections:
Before you start any testing and debugging of your MAF application, you must deploy it to one of the following:
iOS-powered device
iOS-powered device simulator
Android-powered device
Android-powered device emulator
You cannot run the MAF application until it is deployed. For more information, see Deploying MAF Applications .
To test and debug a MAF application, you generally take the following steps:
Test the application's infrastructure, such as a splash screen, application feature navigation, authentication, and preferences, ensuring that all declared application features are available.
If the application includes MAF AMX content, test this application feature's logic, page flows, data controls, and UI components.
Make changes to the application as necessary.
Reconnect the mobile device or restart the simulator, and then deploy and run the application for further testing and debugging.
There are two approaches to testing a MAF application:
Testing on a mobile device: this method always provides the most accurate behavior, and is also necessary to gauge the performance of your application. However, you may not have access to all the devices on which you want to test, making device testing inconclusive.
Testing on a mobile device emulator or simulator: this method usually offers better performance and faster deployment, as well as convenience. However, even though a device emulator or simulator closely approximates the corresponding physical device, there might be differences in behavior and limitations on the capabilities that can be emulated.
Typically, a combination of both approaches yields the best results.
You should use a combination of the following methods to test the accessibility of your MAF application developed for iOS-powered devices:
Testing with the Accessibility Inspector on an iOS-powered device simulator.
For detailed information, see the "Testing the Accessibility of Your iPhone Application" section in the Accessibility Programming Guide for iOS available through the iOS Developer Library.
Testing with the VoiceOver on an iOS-powered device.
For more information, see the "Using VoiceOver to Test Your Application" section in the Accessibility Programming Guide for iOS available through the iOS Developer Library.
JDeveloper is equipped with debugging mechanisms that allow you to execute a Java program in debug mode and use standard breakpoints to monitor and control execution of an application. For more information, see the section on debugging applications in Developing Applications with Oracle JDeveloper.
Since a MAF application cannot be run inside JDeveloper, the debugging approach is different: you can use the JDeveloper debugger to connect to a Java Virtual Machine instance on a mobile device or simulator and control the Java portions of your deployed MAF application.
MAF automatically configures the project properties for debugging (see What You May Need to Know About the Debugging Configuration). The following are the steps you need to take to use JDeveloper to debug the Java code in your MAF application:
To test or debug an application:
From JDeveloper's main menu, click Run > Choose Active Run Configuration to select an active run configuration.
In the Applications window, right-click on any file that you want to test and choose Run.
Alternatively, choose Debug if you want to run the application with debugging enabled.
Tip:
You can also open any file in the MAF application in Source view, right-click on it, and then select Run or Debug.
Note:
If you are using an existing application that does not have the predefined set of run configurations, you can create new run configurations (see What You May Need to Know About the Debugging Configuration).
For additional information, see the following:
When a new MAF application is created, the creation wizard automatically configures the application properties for debugging. This includes the creation of default run configurations that may be used to run or debug the MAF application on an iOS simulator or Android emulator or device. These run configurations allow you to build, deploy, run, or debug a MAF application by clicking the JDeveloper Run or Debug buttons. When you click the Run or Debug button in JDeveloper and select a MAF run configuration, the deployment profile associated with the run configuration is executed to build and deploy the application to the targeted device. Once the application has been deployed, it automatically starts. If the Debug button was selected, the application will start with the debugger.
For information on how to create and edit run configurations, see Creating and Configuring a Run Configuration.
To create a new configuration or to modify an existing one, complete the Edit Run Configuration dialog (see Figure 30-1 ) as follows:
To debug a MAF application on the iOS platform using JDeveloper, follow the debugging procedure described in Debugging MAF Applications.
For information on how to configure an iOS-powered device or simulator and how to deploy a MAF application for debugging, see the following:
To debug a MAF application on the Android platform using JDeveloper, follow the debugging procedure described in Debugging MAF Applications.
For information on how to configure an Android-powered device or emulator and how to deploy a MAF application for debugging, see How to Deploy an Android Application to an Android Emulator.
To allow debugging of a MAF application running on an Android-powered device or its emulator, verify that the Network Information plugin is enabled, as described in Introduction to Using Plugins in MAF Applications
If your MAF application includes the MAF AMX content, after you configure the device or emulator, you can set breakpoints, view the contents of variables, and inspect the method call stack just as you would when debugging other types of applications in JDeveloper.
Note:
You can only debug your Java code and JavaScript (see How to Enable Debugging of Java Code and JavaScript). Debugging of EL expressions or other declarative elements is not supported.
A maf.properties
file allows you to specify startup parameters for the JVM and web views of MAF to enable debugging of the Java code and JavaScript. The maf.properties
file is automatically created and placed in the Descriptors/META-INF
directory under the Application Resources (see Using and Configuring Logging), which corresponds to the <application_name>
/src/META-INF
location in your application file system.
When you execute a MAF run configuration, the following debugging properties are automatically set in the maf.properties
file:
java.debug.enabled
: Set to true
if doing a debug session; set to false
if doing a run session.
Caution:
When java.debug.enabled
is set to true
, the JVM waits for a debugger to establish a connection to it. Failure of the debugger to connect will result in the failure of the MAF AMX application feature to load.
java.debug.port
: Set to the port number configured in the MAF run configuration being executed.
javascript.debug.enabled
: Set to true
if doing a debug session; set to false
if doing a run session. Applies to Android only.
Note:
The javascript.debug.enabled
property is not required for enabling JavaScript debugging when the MAF application is running on an iOS-powered simulator or iOS-powered device.
The contents of the maf.properties
file may be similar to the following:
java.debug.enabled=true java.debug.port=8000 javascript.debug.enabled=true
For information on how to use JDeveloper to debug the Java code, see Debugging MAF Applications.
If you are working with the iOS 7 or 8 platform, you can use the Safari browser to debug JavaScript. To do so, open the Safari preferences, select Advanced, and then enable the Develop menu in the browser by selecting Show Develop menu in menu bar..
When the Develop menu is enabled, select either iPhone Simulator or iPad Simulator, as Figure 30-2 and Figure 30-3 show, and then select a UIWebView that you are planning to debug, as Figure 30-4 shows.
Note:
Whether the Develop menu displays an iPhone Simulator or iPad Simulator option depends on which device simulator is launched.
Figure 30-2 Using Develop Menu on Safari Browser for Debugging on iPhone Simulator
Figure 30-3 Using Develop Menu on Safari Browser for Debugging on iPad Simulator
Figure 30-4 Using Develop Menu on Safari Browser to Select UIWebView
Figure 30-5 and Figure 30-6 show the CSS, DOM, and HTML Safari Remote Web Inspector in action.
Figure 30-5 Remote Web Inspector
Figure 30-6 AMX Page Analyzed by Remote Web Inspector at Runtime
Figure 30-7 and Figure 30-8 show JavaScript debugging using breakpoints inside the Safari browser.
Figure 30-7 JavaScript Debugging in Safari Browser
Figure 30-8 AMX Page Debugged at Runtime
For your MAF application, you can enable logging on all supported platforms through JavaScript (see How to Use JavaScript Logging) and embedded code (see How to Use Embedded Logging) using a single configuration with the log output directed to a single file. This log output includes the output produced by System.out.println
and System.err.println
statements.
The default MAF's logging process is as follows:
The logging begins at application startup.
The existing log file from the previous application run is deleted, so only the contents of the current run are available.
When you are running your application on an iOS-powered device simulator, you can only access the Java logging output through a file of whose name and location you are notified as soon as the output redirection occurs and the file is generated. One of the typical locations for this file is /Users/
<userid>
/Library/Developer/CoreSimulator/Devices/
<device_id>
/data/Containers/Data/Application/
<container_id>
/application.log
, where <device_id>
and <container_id>
references represent long UUID strings created by iOS during the installation of the application. The values of these references cannot be predicted and when multiple simulators or applications are installed, it is difficult to determine which folder corresponds with the simulator used during deployment. When using JDeveloper for deployment, the -consoleRedirect
option is automatically set to direct the log output to a known location. If you set it on a MAF run configuration for iOS using the Edit Run Configuration > Mobile Run Configuration dialog and that run configuration is used to deploy or run the MAF application on an iOS-powered device simulator, the log file is created at the configured location and its contents is displayed on a console in JDeveloper. If you do not set the value using the Edit Run Configuration > Mobile Run Configuration dialog or you choose to perform a regular deployment (for example, such that it does not use a MAF run configuration for iOS), the log file is created in the <appRoot>/<deployRoot>/<iOSProfileName>/
log
<appName>
.log
file and its contents is displayed on a console in JDeveloper. For more information, see Creating and Configuring a Run Configuration.
Note:
The path must be an absolute path to receive the log file and the location must be writable for the current user.
When you are running your application on an iOS-powered device, the console output is redirected to an application.log
file that is placed in the Documents/logs
directory of your application. You can access this directory as follows on your iOS-powered device:
*.xcappdata
file and select Show Package Contents.application.log
file.On Android, the output is forwarded to a text file with the same name as the application. The output file location is /sdcard
. If this location is not present or is configured as read-only, the log output is rerouted to the application's writable data directory. The contents of the log file is replicated in the Android Logcat utility (see http://developer.android.com/tools/debugging/debugging-log.html
). JDeveloper displays the logging output from the Logcat when you use JDeveloper to deploy your MAF application to an Android-powered device or emulator.
For both iOS and Android, the logging output appears in JDeveloper’s run or debug Log page immediately after the deployment. In case of a regular deployment, the deployment log is displayed in the Deployment Log page, whereas the application log is displayed in a separate Log page. If you use a Run/Debug run configuration to build, deploy, and launch the MAF application, the Terminate option in the Processes tab of the Applications window terminates the MAF application along with the process that performs the log redirection. The View Log option enables you to see the log page, as the following illustration shows.
If your use a deployment profile to build, deploy, and launch the MAF application, the Terminate option in the Processes tab terminates only the log redirection process, whereas the MAF application remains running.
The logging.properties
file is automatically created and placed in the Descriptors/META-INF
directory under the Application Resources (see Using and Configuring Logging), which corresponds to the <application_name>
/src/META-INF
location in your application file system. In this file, it is defined that all loggers use the java.util.logging.ConsoleHandler
and SimpleFormatter
, and the log level is set to SEVERE
. You can edit this file to specify different logging behavior (see How to Configure Logging Using the Properties File).
Note:
In your MAF application, you cannot use loggers from the java.util.logging
package.
MAF loggers are declared in the oracle.adfmf.util.Utility
class as follows:
public static final String APP_LOGNAME = "oracle.adfmf.application"; public static final Logger ApplicationLogger = Logger.getLogger(APP_LOGNAME); public static final String FRAMEWORK_LOGNAME = "oracle.adfmf.framework"; public static final Logger FrameworkLogger = Logger.getLogger(FRAMEWORK_LOGNAME);
The logger that you are to use in your MAF application is the ApplicationLogger
.
You can also use methods of the oracle.adfmf.util.logging.Trace
class.
For more information, see Java API Reference for Oracle Mobile Application Framework.
The following example shows the logging.properties
file that you use to configure logging.
# default - all loggers to use the ConsoleHandler .handlers=java.util.logging.ConsoleHandler # default - all loggers to use the SimpleFormatter .formatter=java.util.logging.SimpleFormatter oracle.adfmf.util.logging.ConsoleHandler.formatter= oracle.adfmf.util.logging.PatternFormatter oracle.adfmf.util.logging.PatternFormatter.pattern= [%LEVEL%-%LOGGER%-%CLASS%-%METHOD%]%MESSAGE% #configure the framework logger to only use the adfmf ConsoleHandler oracle.adfmf.framework.useParentHandlers=false oracle.adfmf.framework.handlers=oracle.adfmf.util.logging.ConsoleHandler oracle.adfmf.framework.level=SEVERE #configure the application logger to only use the adfmf ConsoleHandler oracle.adfmf.application.useParentHandlers=false oracle.adfmf.application.handlers=oracle.adfmf.util.logging.ConsoleHandler oracle.adfmf.application.level=SEVERE
The oracle.adfmf.util.logging.ConsoleHandler
plays the role of the receiver of the custom formatter.
The oracle.adfmf.util.logging.PatternFormatter
allows the following advanced formatting tokens that enable log messages to be printed:
%LEVEL%
—the logging level.
%LOGGER%
—the name of the logger to which the output is being written.
%CLASS%
—the class that is being logged.
%METHOD%
—the method that is being logged.
%TIME%
—the time the logging message was sent.
%MESSAGE%
—the actual message.
The following logging levels are available:
SEVERE
: this is a message level indicating a serious failure.
WARNING
: this is a message level indicating a potential problem.
INFO
: this is a message level for informational messages.
FINE
: this is a message level providing tracing information.
FINER
: this level indicates a fairly detailed tracing message.
FINEST
: this level indicates a highly detailed tracing message.
Caution:
When selecting the amount of verbosity for a logging level, keep in mind that by increasing the verbosity of the output at the SEVERE
, WARNING
, and INFO
level negatively affects performance of your application.
The logger defined in the logging.properties
file matches the logger obtained from the oracle.adfmf.util.Utility
class (see Using and Configuring Logging). The logging levels also match. If you decide to use the logging level that is more fine-grained than INFO
, you must change the ConsoleHandler
's logging level to the same level, as the following example shows.
oracle.adfmf.util.logging.ConsoleHandler.formatter= oracle.adfmf.util.logging.PatternFormatter oracle.adfmf.util.logging.ConsoleHandler.level=FINEST oracle.adfmf.util.logging.PatternFormatter.pattern= [%LEVEL%-%LOGGER%-%CLASS%-%METHOD%]%MESSAGE%
JavaScript writes the output to the console.log
or.error/.warn/.info
. This output is redirected into the file through the System.out
utility.
You customize the log output by supplying a message. The following JavaScript code produces "Message from JavaScript"
output:
<script type="text/javascript" charset="utf-8"> function test_function() { console.log("Message from JavaScript"); } </script>
To make use of the properties defined in the logging file, you need to use the adf.mf.log
package and the Application
logger that it provides.
The following logging levels are available:
adf.mf.log.level.SEVERE
adf.mf.log.level.WARNING
adf.mf.log.level.INFO
adf.mf.log.level.CONFIG
adf.mf.log.level.FINE
adf.mf.log.level.FINER
adf.mf.log.level.FINEST
To trigger logging, use the adf.mf.log.Application
logger's logp
method and specify the following through the method's parameters:
the logging level
the current class name as a String
the current method as a String
the message string as a String
The following example shows how to use the logp
method in a MAF application.
adf.mf.log.Application.logp(adf.mf.log.level.WARNING, "myClass", "myMethod", "My Message");
Upon execution of the logp
method, the following output is produced:
[WARNING - oracle.adfmf.application - myClass - myMethod] My Message
For more information, see JSDoc Reference for Oracle Mobile Application Framework.
Embedded logging uses the java.util.logging.Logger
, as illustrated in the following example. The EmbeddedClass
represents a Java class defined in the project.
import java.util.logging.Level; import java.util.logging.Logger; import oracle.adfmf.util.logging.*; ... Utility.ApplicationLogger.logp(Level.WARNING, EmbeddedClass.class.getName(), "onTestMessage", "embedded warning message 1"); Logger.getLogger(Utility.APP_LOGNAME).logp(Level.WARNING, this.getClass().getName(), "onTestMessage", "embedded warning message 2"); Logger.getLogger("oracle.adfmf.application").logp(Level.WARNING, this.getClass().getName(), "onTestMessage", "embedded warning message 3");
The preceding code produces the following output:
[WARNING - oracle.adfmf.application - EmbeddedClass - onTestMessage] embedded warning message 1 [WARNING - oracle.adfmf.application - EmbeddedClass - onTestMessage] embedded warning message 2 [WARNING - oracle.adfmf.application - EmbeddedClass - onTestMessage] embedded warning message 3
Even though it is not recommended to manipulate your MAF projects with Xcode because you can lose some or all of your changes during the next deployment with JDeveloper, you may choose to do so in exceptional circumstances.
Before you begin:
Deploy the application to the iOS simulator from JDeveloper.
To open the generated project directly in Xcode:
Navigate to the workspace_directory
\deploy\
deployment profile name
\temporary_xcode_project\
.
Open the Xcode project called Oracle_ADFmc_Container_Template.xcodeproj
.
If you are debugging your MAF application using Xcode, you cannot see the Java output in the IDE (on neither JDeveloper console nor Xcode console). Instead, the output is redirected to a file (see Using and Configuring Logging). By adding the following argument to your application's schema, you can disable this behavior and enable access to the Java, JavaScript, and Objective-C log output in Xcode in real time when debugging on either an iOS-powered device or simulator:
-consoleRedirect=FALSE
Using the following APIs, you can access the application log information:
oracle.adfmf.framework.api.PerfMon
oracle.adfmf.framework.api.LogEntry
oracle.adfmf.util.HOTS
For more information, see Java API Reference for Oracle Mobile Application Framework.
You can prevent the logging output from being directed to the application log file, in which case the log file either remains blank or is not created in the first place. When logging is disabled, trace statements are absent from the application log and any output directed to stderr
and stdout
is redirected to either a null
location or other location that is not accessible to the end user.
To disable all logging, set the disableLogging
property to true
in the application's adf-config.xml
file, as follows:
<adf-property name="disableLogging" value="true"/>
By default, logging is enabled in MAF applications and the disableLogging
property is set to false
.
For information on the adf-config.xml
file, see Introduction to MAF Application and Project Files.