The mobile way

Mobile forms component enables XFA forms on mobile devices. The same XFA form that can be used for generating pdf, can be used to generate html form as well. The html version should behave almost exactly same as the pdf version. XFA has a very rich support for scripting. It supports tons of APIs and almost all the properties are exposed via scripting interface. But as the famous 80-20 rule suggests our customers use only 20 % of that capability. The difficult part was to find those script constructs that are used in real world cases and prioritize them higher than the rest of the script constructs. We have run through the large collection of customer XDPs we have and generated the list of javascript constructs that people use. Interestingly, we found that usage to be less than 20%. Out of 2600 javascript object properties and APIs, forms were using around 200 constructs at least once. So we decided to prioritize based on it. Mobile Form is covering that gap fast but there would be certain things that would never make sense in html or mobile world.

Here is screenshot of both pdf as well as html form for comparison.

Then there are things that matters in pdf world doesn’t have same importance in html/mobile world, e.x. barcodes. Barcodes are more relevant in printed documents so we decided to do away with this barcode object purely from UI level. We still keep it at model level so one can always generate pdf with barcode using the data exported from the html form. If required, one can always insert custom widgets to show barcodes on html form. That is the beauty of Mobile Form architecture. It is way more open than the pdf form where all the widgets are locked down. In Mobile Forms world, one can customize the widgets to enhance the user experience on Mobile devices. For example, one can replace the xfa numeric field with the slider object to capture number information from users.

Signature field is another component that can be interestingly done using the html world solutions like e-sign. So we decided to de-prioritize it for Mobile Forms. On the other hand, we provide a scribble object, using that one can scribble his signature on the form and it will be saved as an image on the form. More detail on the scribble form can be found here.

As I mentioned, Mobile Form will look like almost same as Pdf form. Time has come to explain the almost part here. Mobile Form, because of its html nature has lot of advantages, for example easier to customize, faster opening time, availability on mobile etc. But it has its own set of inherent issues also like support for very thin lines thinner than 1 px.

We use data uri scheme to show images in the Mobile Form. This is supported by all the modern versions of the browsers but you cannot help but notice the differences in the range of image formats that these browsers support. So one should test the images across all the browser matrix before deploying the forms.

In mobile form, pagination, the ability to generate pages due to content changes like adding enough text in the text box to go beyond page boundaries, doesn’t matter. But keeping all the content cluttered would not look nice either. Mobile Form, that is why, chooses a hybrid approach where it generates panels, a box to give feel of pages, as many as there is in the template but it doesn’t increase or reduce panels by data content merged or by user content.

This is second post in my previous series of LiveCycle Mobile Forms. In this post, I will introduce utility tool called Forms Management that eases out forms deployment on live production systems.

The Forms Management streamlines the process of updating, managing, and retiring thousands of forms and the business users can manage forms without any help from IT support.

One can access Forms Management console through http://<server>:<port>/lc/fm. Here is how it looks like once you log in using super admin user.

There is search control where one can search through the forms. Forms Management UI shows all LiveCycle applications that contains forms. You can go and select one of the applications and browse into the forms. You can select the forms and preview it as pdf or html5. Here is how preview screen looks like:

You can select a form and edit metadata corresponding to it and the metadata is searchable too.

One of the many new offerings in LiveCycle ES4 is Mobile Forms that is ability to display and fill forms on mobile devices like iPad and other tablets. Mobile forms uses the already stable and widespread html5 as its rendering format so practically, any device that supports html5 can show LiveCycle forms. With the explosion of mobile devices, our existing customers were looking for this component to increase their reach and not only that, it would also enable many new use cases. Mobile Forms plays key role in customer’s workflow and enabling that workflow step on mobile device will further reduce the time taken to complete the process.

Mobile Forms generates html5 document for XFA forms. The API is RESTful, another change from the Document based LiveCycle service APIs as html is more suited for http requests. Html fragment for XFA form can be embedded into any html document.

“Web” and “online” are two closely associated terms, downright synonymous to many people. But with the advent of html5, now people are developing offline web apps. Mobile Forms, being an html5 document, can also be used to build offline forms. So one can open the form even if she is not connected to company intranet or for that matter internet. Mobile Forms closely follow the html5 offline W3C spec for building offline-able forms. I’ll discuss this feature in detail in some other post. Let’s focus on html5 form render first.

As I mentioned Mobile Forms is a RESTful application and its render API has the following commonly used parameters to specify form and data:

Parameters

Description

template

This parameter takes the file name of the template.

contentRoot

This parameter is for specifying the path where template and associated resources resides.

dataRef

This parameter takes absolute path of the data file to be merged with the template. Please remember it takes absolute value of the data file path.

data

This parameter takes UTF-8 encoded data bytes to be merged with the template.

submitUrl

The url where the form data will be posted to.

debugDir

Directory location on server machine where the debug intermediate files will be dumped. Do not use this parameter in production as it will slow down the rendering considerably. This parameter is for Adobe internal usage and can be changed in the future.

templateBytes

This parameter takes UTF-8 encoded template bytes to be rendered. This is again Adobe internal API and can be changed in future.

As you can see, Forms Mobile render API is fairly simple and can be easily used. Out of the box, the render API is exposed on both GET and POST. The sample uri looks like the following:

Hit the above URL in browser and see your XFA forms being rendered as html5 document. XFA forms can also have webservices or scripts that are to be run on server side. In that case, the rendered html doc contacts http://<lcserver>:<port>/lc/content/xfaforms/submission/default.html url so make sure you don’t block this url while hardening the system in order to smooth functioning of form.