Want to use Eclipse to build an on-device mobile application that runs on iOS devices (iPhones and iPads)?
No problem - here is a step by step demo on how to do this:
Oh, and by the way the same app will function also on Android without any changes to the code :-)
This is an extract from an online seminar that I recorded for one of Oracle's Virtual Technology Summits - and I figured people who didn't sign up for that event might still benefit from having access to the demo part of the video.
In the demo I show how to build an on-device app that access local data as well as remote data through web services, and how easy it is to integrate device features too.
It seems that REST interfaces are all the rage now for accessing your backend data, this is especially true in the world of mobile development. In this blog I'm going to show you how easy it is to provide a complete REST interface for your database by leveraging TopLink/EclipseLink and JDeveloper.
This relies on a capability that is available in TopLink 12c where every JPA entity that you have created can be RESTified with a simple servlet that TopLink provides.
All you need to do is locate the file toplink-dataservices-web.jar on your machine (this is included in the JDeveloper install so you can just search that directory) and then package your project as a WAR.
At that point you'll be able to get a complete CRUD set of operation for this entity.
In the video below I'm to retrieving departments by their id using a URL like this:
Mobile users are getting used to specific touch gestures, such as swipe, in their applications. And sometimes you might want to incorporate those gestures as a means for navigating between pages in your ADF Mobile application.
You can do this by using the amx:actionListener component and having it bind to a method in your backing bean.
The basic ingredients:
In an AMX page add an actionListner to a component for example:
I posted before on how to do code level debugging in your ADF Mobile application, but sometimes debugging is an overhead and you would rather just put out some log messages that will allow you to track what's going on where.
You can use a line of code like this in your code:
Logger.getLogger(Utility.APP_LOGNAME).logp(Level.INFO, this.getClass().getName(), "Shay","We invoked the button");
Then don't forget to set the right level of logging (and possibly the log message format) in the logging.properties file under your META-INF directory.
The logging chapter in the doc, doesn't mention where to actually see the messages being logged.
One utility that you can use to see your log messages comes with the Android SDK - look into the tools directory there and you'll find the ddms.bat file - run it and you'll be able to see the log messages from your application.
On the side of that utility you can also define filters to just show you the messages you are interested in.
Here is a quick demo showing how this all works together:
By the way - a comment I got pointed out that ddms is old school and you should be using the new monitor.bat at the same locaiton. This will basically work just the same and will look like this:
The dial gauge is a very visual way to show data in an application - and it has been there in Oracle ADF Mobile since 11.1.2. However in that release you could only use a range of 0-100 - well now you can do better with the new ADF Mobile version.
But there is one little trick to how this works compared to the way it works in the regular web ADF Faces gauge component, and if you don't notice it you might think you are still stuck in the 0-100 days - The trick is the new background property.
If you are working in the property inspector you can right-click in the property to see explanation and the available values.
Or if you work in the code editor just use the code insight to choose the value you want.
For defining your own range you'll want to use the costum options.
Then you can get something that looks like these:
Also note that you can control the indicator type with the indicator property.
The new Oracle JDeveloper 184.108.40.206 just went out with a bunch of new features for ADF Mobile developers. Read more about it here - or watch this video.
One small feature that somehow got left out from the above two links is that there is a new UI component offered in ADF Mobile now - Star Rating.
The official tag name is dvtm:ratingGauge - and you can find it in the DVT Mobile AMX component palette under the Gauge section.
You can configure how many stars you want to show for your rating in the data section of the property inspector, and you can even specify to advance in half steps.
The component supports multiple shapes that you can choose from - star, diamond, circle, rectangle
You can also specify a different shape to be displayed for the unselected spots.
The code for the above 3 components is: <dvtm:ratingGauge id="ratingGauge1" value="2.5" maxValue="3" shape="circle"/> <dvtm:ratingGauge id="ratingGauge2" unselectedShape="dot" inputIncrement="half"/> <dvtm:ratingGauge id="ratingGauge3" shape="diamond"/>
Not that you'll ever need this, after all your code is perfect. But I did run into a situation where I wanted to figure out what exactly is wrong with my ADF Mobile code. The way to do debugging is documented in the ADF Mobile Developer Guide, but here is a version of those instructions with nice pictures (which might make it easier for you to find files etc).
1. First locate the cvm.properties file (In the Application Resources accordion). In this file you'll want to change the value of java.debug.enabled to be true. Also note in this file the value set for java.debug.port, by default this is 8000 and we are going to keep that default value in our example.
2. Next have a look at your application level deployment profile, or even better create a new deployment profile and call it debugDeploy. The key thing here is to make sure your build mode is in Debug mode and not Release mode (remember the previous post where we told you that Release mode creates a smaller/faster deployment, but right now we do need the bigger package to be able to debug).
3. Next deploy your application with your new debugDeploy profile. We'll assume deployment directly to the device.
4. Now from the command line locate the directory where your Android's SDK adb.exe utility is and issue the following command to let the device (-d) know that we are going to use port forwarding for debug:
adb -d forward tcp:8000 tcp:8000
5. Now on your device start your application. You'll notice that it seems to be stuck, well this is because it is waiting for the debugger to connect to it. So what are you waiting for?
6. In JDeveloper, stand on your viewController project and right click to choose debug. If you changed the port number you'll need to update that info in the dialog that pops up - but if you kept it at the default 8000 we should be ok.
The debugger will now try and connect to your running application, and will stop at the breakpoint you set.
By the way if you want to debug on the emulator of Android the only difference will be in step 4 where instead of -d you'll use a -e .
Most of the enterprise Web services you'll access are going to be secured - meaning they'll require you to pass a user/password in order to get to their data.
If you never created a secured Web service, it's simple in JDeveloper! For the below video I just right clicked on a Java class that I exposed as a Web service, and chose "Web Service Properties" and then checked the "oracle/wss_username_token_service_policy" box from the list of options (that's the option supported by ADF Mobile right now):
In the demo below we are going to use a "remote" login server that does the authentication of the user/pass.
The easiest way to "create" a remote login server is to create a "regular" web ADF application, secure it, and deploy it on a server. The secured ADF application can just require ADF Authentication with a simple HTTP Basic Authentication - basically the next two images in the Application->Secure->Configure ADF Security menu wizard.
ok - so now you have a secured ADF application - deploy it on a server and get the URL for that application.
From this point on you'll see the process in the video which deals with the configuration of your ADF Mobile app.
First you'll need to enable security for your ADF mobile application, so
it will prompt users to provide a user/pass combination.
You'll also need to configure security on specific features. And you can have them use remote login pointing to your regular secured ADF application.
Next define your Web service data control. Right click on the web service data control to "define Web Service Security".
You'll also need to define the adfCredentialStoreKey property for the Web Service data control in the connections.xml file.
Many of the SOAP based web services out there have parameters of specific object types - so not just simple String/int inputs. The ADF Web service data control makes it quite simple to interact with them. And this applies also in the case of ADF Mobile.
Since there were several thread on OTN asking about this - I thought I'll do a quick demo to refresh people memory about how you pass these "complex" parameters to your Web service methods. By the way - this video is also relevant if you are not doing mobile development, you'll basically use the exact same process for building "regular web" ADF applications that access these types of Web services.
One more thing you might want to do after you create the page is look at the binding tab to see the method call in there, and notice the parameters for it in the structure property. Go and look at their NDValue property to get the complete picture.
As you might have noticed from my latest ADF Mobile entries, I'm doing most of my ADF Mobile development on a windows machine and testing on an Android device. Unfortunately the Android/windows experience is not as fast as the iOS/Mac one.
However, there is one thing I learned today that can make this a bit less painful in terms of the speed to deploy and test your application - and this is to use the "Release" mode when deploying your application instead of the "Debug" mode.
To do this you'll first need to define a keystore, but as Joe from our Mobile team showed me today, this is quite easy.
Here are the steps:
Open a command line in your JDK bin directory (I just used the JDK that comes with the JDeveloper install).
In this entry we'll dive a bit deeper and address an update scenario through these web service interfaces.
You can see the full demo video at the end of the post.
In the first steps I show how to add an explicit method execution to fetch a specific record we want to update on the second page of a flow.
For an update you'll be invoking a service method and passing the record you want to update as a parameter. As in many other Web services scenarios, we need to provide a complete object of specific type to the method. The ADF Web service data control helps you here by offering an object of this type that you can drag and drop into your page.
The next step is to make sure to fill that object with the values you want to update. In the demo we do this through coding in a backing bean that shows how to use the AdfmfJavaUtilities utility. The code gets the value from one field, gets a pointer to the parallel update field, and then copy from one to the other.
At the end of the bean we manually execute the call to the update method on the Web service.
Here is the demo:
Here is the code used in the backing bean in the demo above.
Update (Nov 2015) - while the approach shown here could still work, we highly recommend that you'll use a REST/JSON architecture instead to access your ADF layer from MAF - as shown in this blog entry.
If you are not familiar with ADF Mobile - it basically lets you build applications that run on iOS and Android devices using the concepts you already know - components based UI constructions (same idea as JSF), taskflows, data controls, Java and of course JDeveloper.
I created one demo that shows how to build an on-device application that gets data from local Java files (that run on the device - yes we do Java on iOS too) - you can see it here.
However, one thing many of you might be wondering is how can you get data from your database into these mobile applications.
Well if you already built your data access with Oracle ADF Business Components then here is a two step video demo that shows you what to do.
The steps are:
1. Expose ADF Business Components as Services
2. Create an ADF Mobile application that consumes the above services with the Web service data control
That's the whole point of ADF Mobile - making on device application development as simple as possible.
In this entry I'm starting from his sample application and I'm showing how easy it is to build an interface that will look great on an iPhone (or other mobile devices) using Oracle ADF Mobile Browser.
For those of you who are just using ADF and never tried ADF Mobile Browser - you'll find that the development experience is quite familiar and similar to your normal Web application development. In the latest version of JDeveloper (220.127.116.11) which I'm usingin this demo we have a built-in skin that will give your application the native iOS look and feel. In the demo I achieve this by setting the styleclass of a tr:panelHeader component to af_m_toolbar to get this. For more on this styling read the doc.
One of the areas that got a bit more attention this year at Oracle OpenWorld is the usage of Oracle ADF to build new interfaces to existing applications and for Oracle Apps Unlimited specifically.
The basic idea is that you can access data and functionality from your existing applications and develop either rich web user interfaces or interfaces for mobile devices using JDeveloper and Oracle ADF.
Here is a little demo that I did in one of my sessions showing how this works when accessing a Web service exposed by Peoplesoft.
By the way - if you want a more native looking iOS application you can use the skining capabilities - see the way it is done in this demo with EBS.