Thursday Jan 24, 2013

Enable JavaScript Debugging on Mac OS Mountain Lion

Hi, everyone:

JavaScript debugging is a critical functionality when skinning the application, as you can interactively test out CSS commands interactively while the application is running in the simulator.  For example, you can enter a new color in a style class in the debugging window in the Safari browser on your Mac, and see the color change in the simulator as soon as you enter it. The entire setup requires using Safari b

Unfortunately, Safari 6 broke compatibility with the JavaScript debugging capabilities.  If you are on Lion or prior Mac OS, you can at least downgrade to 5.x Safari to enable JavaScript debugging.  Safari 5 is not available on Mountain Lion.  If you are using Mountain Lion Mac OS, then you will need the following combination of software to support JavaScript debugging:

  • Xcode 4.5.x

  • iOS Simulator version 5.1

    • There are some known issues with using iOS simulator version 6.0 and therefore not recommended.

    • Please note that the ADF Mobile application will run fine on devices running on iOS 6, as long as it's compiled using the iOS 5.1 SDK.

  • Safari 6

The steps to configure and setup Xcode 4.5 with iOS simulator 5.1 is as follows:

  1.  Install (or upgrade to) Xcode 4.5.x (current version as of Dec 18th, 2012) from Apple AppStore or download directly from

  2. After installing, start Xcode

  3. Go to menu item Xcode-preferences

  4. Click on the Download tab.  The Downloads tab loads and show you options to install iOS 5.1 and 5.0 simulators.  Click to install the iOS 5.1 simulator.

  5. After the download/installation is complete, go back to JDeveloper.  Select menu item Tools - Preferences - ADF Mobile - Platforms -iOS.  In the iOS SDK Simulator directory, make sure you select the Simulator version 5.1 that you have just installed.  Please make sure you re-select this path specifically.

  6. Deploy the application to the simulator.  The ADF Mobile app would deployed to the 5.1 simulator, although 6.0 simulator would be started by default.  This is because JDeveloper relies on Apple Script to start the iOS Simulator, and 6.0 simulator is the default.  This means you will not see the app in the 6.0 simulator.

  7. You will need to switch to the 5.1 simulator by going to menu Hardware - Version 5.1.  You will then see your application running in the simulator as expected

Now, to enable JavaScript debugging, you will need to:

  • Set the following properties in file in your ADF Mobile application workspace (under Application Resources Panel in JDeveloper):

# JavaScript debugging settings


# Specifies the feature that will trigger the activation of the JavaScript debugging

javascript.debug.feature=<feature id>:9999

  • Deploy the application and navigate to the amx page to be inspectedAccess the http://localhost:9999 URL in a Safari browser to view the list of AMX pages in the App.

  • Select the link corresponding to the page displayed in the simulator to inspect the DOM for the page or debug JavaScript.

That's it!  You can then interactive change the style classes in the Safari browser window, and see ADF Mobile App's UI change in real time.

Please let us know if you encounter any issues, and hope this helps to debug some of the skinning challenges you have encountered.


ADF Mobile Team

Friday Jan 11, 2013

Using Hi DPI Images in your Mobile App

Getting Started with ADF Mobile Sample Apps

Whether you are developing an ADF Mobile application or a classic ADF Server application, it is becoming more and more important to support hi-DPI screens (high resolution or "retina" displays). There is no easier way to make your application look out-dated than to use grainy, unprofessional image assets or use them improperly.

In HTML, the "px" unit corresponds to the same amount of space regardless of the DPI of your device (however, the number of device pixels may vary). The original iPhone models did not have hi-DPI displays. Each point of color on those screens corresponds to one HTML CSS "px" unit. Newer iPhone models introduced a hi-DPI (or "retina") display that has 4 device pixels in the same amount of space that 1 device pixel used to take up (2 device pixels wide by 2 device pixels tall); on these new devices, the width and height "px" values use twice the amount of device pixels.

Why is this a common problem? Since ADF Mobile uses HTML, displaying an image is not as simple as just specifying the source path and magically hoping the browser will know that you are using a high resolution image. You must specify dimensions to go along with the source path.

Let's work with an example. You have an image named "image-64.png". This image has a size of 64 by 64 individual dots of color (individual points of color information). If you coded your page like the following, the image will be shown with a width of 64px and a height of 64px (one color dot per "px"):

   <amx:image id="i1" source="images/image-64.png"/>

This would look just fine on a classic low-DPI display. However, on a hi-DPI display, it still takes up the same space but since there are more device pixels, the image will look very grainy.

In order to look crisp and professional, you need to set a size so that each dot of color corresponds to at least one device pixel. For a hi-DPI display, this means your image needs a width and a height specified such that you use 2 dots of image color information per HTML CSS "px" unit (e.g. a 64 by 64 sized image should be specified to use a width of 32px and a height of 32px. In code, your page should look like this:

   <amx:image id="i1" inlineStyle="width:32px;height:32px" source="images/image-64.png"/>

Even if you still want to support legacy devices for your application, this same image (with the same specified width and height) will look beautiful on low-DPI screens because of how images are processed modern browsers.

If for some reason you really needed or wanted to specify alternate images for each kind of device, you have the option to use a device properties EL variable to toggle the rendered state of alternate amx:image components or simply use that EL to alter the inlineStyle and the source path as desired.

Thursday Jan 10, 2013

ADF Mobile REST JSON/XML example

This article discusses and demonstrates the use of REST web services in your ADF Mobile applications.  

First you should download the RESTDemo example application and install it and run it and take a look.  The general usage of the app is that it takes a domain or IP address and returns you the geo-location of it.  The app provides this in a form and then you can view it on a map as well.  This demo uses a public web service provided by FreeGeoIP and it's author, Alexandre Fiori.  NOTE:  This service has a throttling mechanism of 1000 queries an hour so if you get a 403, you should wait until the next hour before you test again.


There are two flavors of REST supported by ADF Mobile.  The first we'll talk about is REST XML.  The nice thing about REST XML is that it's structure is defined by an XSD and thus the design-time knows that the format should be and can provide you with a shape for the data when building your app.  You use the URL Data Control wizard from the new gallery to define a Data Control backed by a REST XML service.  You need to supply an XSD that defines what the structure will be.  Note: if you have a service that returns XML but you don't have an XSD, there are many free utilities that will generate the XSD for you.  When specifying the endpoint, you should typically keep this to the minimum needed for all methods of your web service.  You then specify the HTTP method for the method of your service you want to invoke.  Note that if you have a single service that supports multiple methods, you should be selecting the same endpoint and just keep adding methods to it, DO NOT generate separate Data Controls for each method.  Any extra info you need for specific methods, including parameters should be put into the Source field. 

Once your DC is created, it can be used just like any other Data Control.  You can optionally decide to invoke these Data Control methods from Java and follow the techniques outlines in the Web Service example #2 in this blog if you wish.

The REST XML Data Control for the Geo IP is used directly in the REST-XML feature and shows you how to declaratively use the DC without a bean.  


Because of the loosely structured nature of REST JSON services, there is no declarative model available for most because they do not provide a consistent way to describe the shape of the data model.  The way to use REST JSON services with ADF Mobile is to execute these services with our helper classes and then use the supplied JSON parsing classes to create beans from the data and bind your UI to those beans. 

In the second feature, REST-JSON, we have a managed bean created called RESTJSONBean.  This bean maintains the parameter that we send to the service method along with the JSON response that is returned. 

Steps to invoke and parse the REST JSON web service:

  1. The bean method loadData first declares an instance of the RestServiceAdapter class.  This is a helper class that lets you invoke REST web services and simply returns the results in string format. 
  2. The RestServiceAdapter lets you set the connection name (from connection.xml), the request type (GET/POST/etc), what the retry limits are and then you can specify anything else you want added to the URI. 
  3. The send method of the RestServiceAdapter is invoked and the service is called and the JSON string is returned.
  4. To easily parse the JSON string into a bean, we provide the JSONBeanSerializationHelper class.  This class has a fromJSON method where you can specify the destination class type and the string to parse and it will return an object of the class you specified.  In our case, we have defined a RESTJSONResponse class to hold our GeoIP information returned from the service.

Now that the service is invoked and the results are parsed into the bean, the UI is updated because it is already bound to the bean DC.  With the REST JSON version of this you don't need a Data Control for the service, but you do need a connection in your connection.xml to store the URL connection.   You can optionally bind the data directly to your bean or create a Data Control out of the Bean and bind that to the UI.  Normally it's easier to do the latter once you understand the binding framework.

What's next?

This pretty much completes this example.  I've added the map just as a nice UI representation of geo-coordinate supplied by this service.  In the future you will see some more structured REST JSON web services coming out of Oracle that have methods that provide schema information.  This will allow us to use them declaratively within ADF Mobile.

Good luck and happy coding!

ADF Mobile applications built on Oracle Forms!

Yes, it's true!  You can build ADF Mobile applications built against an Oracle Forms back end!  One of Oracle's partners, OraPlayer,  has built a recorder/player that can turn a forms app into a series of web services and a corresponding client proxy class for use with ADF Mobile.  You don't have to rewrite any server code and you get extended use and capabilities out of your existing Forms apps.

Here is a great blog article with a demo of the technology.

Join us for a joint Webinar with the OraPlayer folks on February 7th, 9-10am Pacific.  

This is a great way to create new state-of-the-art mobile applications without retooling your Forms applications!

Monday Jan 07, 2013

Are You Currently Developing with Oracle ADF Mobile?

As part of our work on the next versions of Oracle ADF Mobile, the ADF Mobile team is looking to get in touch with customers who are actively developing applications with ADF Mobile.

If you are in the process of developing an application with ADF Mobile, we would like to hear from you and have some mutually beneficial interaction that will help us develop the next versions of ADF Mobile. Beyond the chance to get a better product to meet your needs, you'll benefit from direct contact with the product management team.

If you are interested please send us an email and include the following information:

Company name:

Current development status with ADF Mobile:

Planned timeline for your Mobile application going production:

Number of developers involved:

Please note at this time we are looking for customers who are doing real application development, and not for those who are just evaluating/playing with the technology.

Thursday Jan 03, 2013

ADF Mobile Configuration Service Usage


ADF Mobile Configuration Service provides a mechanism for ADF Mobile Apps to update the end-points after they have been deployed to devices. This service allows any end-points configured in connections.xml to be updated on the server and have the deployed Apps uptake the changes without having to go through the normal App update process. All the end-points configured in the connections.xml like Web Service WSDL URI, REST Service URI, LoginServer URI, Remote URL etc can be updated using the Configuration Service.  


1. Test to Production : When Apps are built they are configured to use dev/test end-points used by the developers for testing during development. Typically these end points are configured by administrators to point to production instances as part of application provisioning. Using Configuration Service allows mobile application administrators to configure the end-points a part of App provisioning.
2. Updating Configuration for Apps in production : In certain cases one may need to change the end points used by an App after deployment to a production environment due to maintenance or some other reason. Configuration Service  & checkForNewConfiguration() API can be used for the configuration changes to be propagated to the mobile apps in production.

Configuration Uptake Flow

First time App start up:

1. When Configuration Service is enabled in an ADF Mobile App, the user is prompted with a dialog to provide the credentials and URI for the Configuration Service. A default URL is populated for the Config Service URL field based on the seeded URL entry in adf-config.xml. User can change this to any end-point provided by the administrator

Config Service Login

2. After the user enters the credentials and submits the FWK downloads connections.xml from the Configuration Service and restarts the App with the new configuration.

3. During the Application restart the FWK checks for the presence of the downloaded connections.xml and continues with the normal startup flow.

Configuration updates after deployment:  

Developers can use oracle.adfmf.framework.api.AdfmfContainerUtilities.checkForNewConfiguration() API to check if the connections.xml on Configuration Service has changed and if so, download a new version of the connections.xml file from the server. If a new version of the file is downloaded, the application is restarted with the new configuration. Developers can either invoke the API through some UI as shown in the attached sample app or do the check automatically as part of Application or Feature Lifecycle listeners at a certain event point in the App lifecycle.    

Enabling Configuration Service

Configuration Service can be enabled using the  following configuration in adf-config.xml. This file is in <App root>/.adf/META-INF folder 

<adf:adf-properties-child xmlns="">
     <!-- Enable Configuration Service Check at Startup--> 
     <adf-property name="use-configuration-service-at-startup" value="true"/>
     <!-- Seeded Configuration Service URL -->
     <adf-property name="adfmf-configuration-service-seed-url" value=""/>

Server Side Configuration Service Setup

Configuration Service can be implemented as a WebDav service or as a Service that accepts HTTP GET and returns connections.xml. The URL used by the Config Service Client is of the following format : <URL Configured in adf-config.xml>/<application bundle id>/connections.xml. The Config Service end-point can be secured using Basic-Auth or Basic-Auth over SSL.

Sample Details

The provided sample application has :
1. ADF MF App (ConfigServiceTest): This App has two features ; 1. remote URL feature pointing to 2. Config feature with a page to check for config changes on the server. The App is configured to check for configuration during initial start-up. The URL used by the remote URL feature is configured in connections.xml. This URL can be changed in the Configuration Service App to point to say, for ex: and the mobile app can pick up this change using Config feature. 
2. J2EE app(ConfigService) that contains connections.xml at HTML root/<application bundle id> . This App does not have to be a J2EE App. In fact, it can be any endpoint that accepts HTTP GET and returns connections.xml using the specified URL format. 

Steps to try the sample:

1. Deploy the ADF Mobile App to a simulator or device.
2. Deploy the WAR file to a WLS instance(tested with integrated WLS shipped with JDev

3. Start the mobile App. Enter the Config Service URL from step2 in the Config Service dialog displayed during the app startup as shown below. Make sure you change the host and port to point to the WLS instance used in step2.

Config Service Login

4. The App will download the connections.xml from Config Service and restart.

5. When the App restarts Search feature will display google search page 

Config Service Login

6. Change the remote URL in connections.xml in the Config Service App to Make sure the changed end point is visible in the connections.xml by accessing the file from a browser
7. In the mobile app, access the Config feature and click on the "Check For Config Changes" button to detect the config change and download the new connections.xml.

8. The App will restart after downloading the new configuration. This time the search feature will display the bing search page.  

Config Service Login

This approach can be used to change any end points used by the app like WSDL URI, REST Service URI, Login Server URI etc.


This blog is is dedicated to announcements,tips and tricks and other items related to developing, integrating, securing, and managing mobile applications using Oracle's Mobile Platform. It is created and maintained by the Oracle Mobile product development team.

Archive of past entries

Even More Mobile Development Blogs

Oracle A-Team Site - Mobile Related Entries

Code samples from the Community

Fusion Middleware Blogs


« January 2013 »