Does Adobe Livecycle forms work in Apple IPAD/ Android devices ??

[Nav]

I created a dynamic adobe form. It worked fine on my system but when I tried opening the form in Android mobile/ Apple Ipad I got the below issue:

"Please wait... If this message is not eventually replaced by the proper contents of the document, your PDF viewer may not be able to display this type of document........."

In one of the Adobe Forms I found that Livecycle forms don't work in android/apple devices.... Is this true??

https://forums.adobe.com/thread/1609418

Please share your thoughts on the same.

Many Thanks,

Nav.

[Hernandez,Raymond J]

Are you using HTML Workspace to launch?  http://localhost:8080/lc/libs/ws/index.html

 

Make sure your render process configuration is set to HTML in WorkBench.

 

 

I’ve had success with Android and not iOS (iphone/ipad).  When rendered form loads on ipad/iphone half of the form gets cut off and you don’t see the save/submit buttons.  I have submitted a trouble ticket with Adobe’s Sr Product Consultant (tier one level) and they have replicated the same problem.  As of last week (12/10/2014), the ticket has been escalated to Adobe’s LiveCycle engineers for investigation.

 

Sorry I couldn’t provide you with better news but I can keep you posted.

 

Ray Hernandez

--
You received this message because you are subscribed to the Google Groups "Adobe LiveCycle Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to livecycle+...@googlegroups.com.
To post to this group, send email to live...@googlegroups.com.
Visit this group at http://groups.google.com/group/livecycle.
For more options, visit https://groups.google.com/d/optout.

---

This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.

[Naveed Syed]

Thank You for your response.

No am not using any workspace. Its a standalone dynamic xfa form which am trying to open in my Android/ Apple device. But it doesn't render even when I use Adobe Reader for opening.

Regards,

Nav.

[Brian Kalbfus]

I've had the same problem.   I heard that adobe has not put support for xfa forms in the mobile versions of Reader.   Some sort of html rendering seems to be the only option.

[Duane Nickull]

My company , Technoracle, is building out a forms solution for mobile forms for LiveCYcle ES.  I also believe that Avoka has a similar offering.

Duane Nickull

******************************

CTO - Hot Tomali/Cientis/Cheddar Labs

www.hottomali.com

NOTICE: This e-mail and any attachments may contain confidential information. If you are the intended recipient, please consider this a privileged communication, not to be forwarded without explicit approval from the sender.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. The originator reserves the right to monitor all e-mail communications through its networks for quality control purposes.

[Naveed Syed]

Duane

Does your solution take adobe form designed using designer and convert it into mobile form; or is the form developed from scratch using alternative methods??please clarify

I also noticed that forms designed in acrobat open up in iPad or android mobile but the JavaScript in the form doesn't work....Any thoughts on this?

Regards,
Nav.

[Angie Okamoto]

Nav,

Mobile reader has a reduced JS engine, and does not support XFA (Designer) forms.  You can get the details here:

http://www.adobe.com/devnet-docs/acrobatetk/tools/Mobile/androidapi/index.html 

The short answer to this problem is to develop the form for HTML.

The Avoka tools do use their own form designer, but upon submission to a server, produces a PDF receipt from the same original form design. No need to build it twice.

I'll let Duane respond for the Technoracle tools.

Cheers,

Angie

Angie Okamoto

[Kai Koenig]

My personal recommendation - if you want to or need to do HTML forms, use an HTML-based technology to develop your forms and not a bridging technology such as LC.

Cheers

Kai

<image002.jpg>

--

Angie Okamoto

[Duane Nickull]

We have a technology that can read a PDF form and turn it into an Technoracle form almost instantly. We can do many XFA forms and different types of forms however this is limited to forms that are authored with structure.  We cannot parse a PDF form that has no form caption and turn that into another form.

The Technoracle forms solution uses HTML5 and some other technologies.  

Duane Nickull

******************************

CTO - Hot Tomali/Cientis/Cheddar Labs

www.hottomali.com

NOTICE: This e-mail and any attachments may contain confidential information. If you are the intended recipient, please consider this a privileged communication, not to be forwarded without explicit approval from the sender.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. The originator reserves the right to monitor all e-mail communications through its networks for quality control purposes.

[Tlrsekar]

Hi

Adobe LC requires Flash components to run which is not supported in IOS, because that the form will not render properly, we tried using in between webservice for normal static pdf rendering n it worked. But not sure about dynamic forms

Sent from my iPhone

<image002.jpg>

[DCS_JEFF]

We are doing this currently...   converting existing forms for use on mobile devices... the pilot is for iPads.

The only way we have found is to render them as HTML5 using ES4.

Rendering in HTML5, so far, has been a pain.   The PDF rendering is different so every form has needed formatting changes.  Some scripts on forms don't work because certain events may not be supported by HTML5, etc.

As for Android...I would imagine there would be a similar approach?

If anyone else have forms generated from LiveCycle to mobile devices (iOS/Android)... how are you doing it?

[steve tempest]

The short answer is no they don't.  As best as I can tell the mobile apps don't have full support for xfa.

I had the same issue and we have ended up creating forms in .net and generating the required xml values to submit so the same data is entering the system, it's just a different delivery mechanism.

As Duane mentioned there are products out there that can do it, but as with most development I would guess that cost will impact as well as introducing new systems.

[Duane Nickull]

Jeff:

We have actually been able to deterministically do this for properly authored forms with really good results.  The performance is quite good, in most cases a form will convert to our forms format (an augmented version of HTML) , upload and render faster than a normal PDF document will load in Reader on a mobile device.

The caveat here is the problem with form authors. If someone builds a form by screen scraping and adding text fields for form field captions, the auto conversion process cannot associate the text field with the form component. If they use the XFA model and use a form field caption however, we can capture that and convert it.

We are using PDF Box with some extensions developed in house.  This is almost ready for a new release.  Stay tuned…

Duane Nickull

******************************

CTO - Hot Tomali/Cientis/Cheddar Labs

www.hottomali.com

NOTICE: This e-mail and any attachments may contain confidential information. If you are the intended recipient, please consider this a privileged communication, not to be forwarded without explicit approval from the sender.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. The originator reserves the right to monitor all e-mail communications through its networks for quality control purposes.

From: DCS_JEFF <jeff.w...@dcs.in.gov>
Reply-To: Adobe LiveCycle Developers <live...@googlegroups.com>
Date: Tuesday, December 16, 2014 at 5:58 AM
To: Adobe LiveCycle Developers <live...@googlegroups.com>
Subject: Re: Does Adobe Livecycle forms work in Apple IPAD/ Android devices ??

--

[Rob McDougall]

As Jeff indicates, the official solution from Adobe is to generate HTML5 Mobile Forms from LiveCycle.  In theory, the process is supposed to be painless (just change your server side code to generate HTML5) but in practice it does require adjusting your form.  Our experience is that the boilerplate changes are pretty straightforward but that many scripts require changes to run in HTML5.  A lot, however, depends on how much script you have and the nature of that script.  The more scripting you have and the more complex that script is, the more likely you are going to require work to convert it to HTML5.  Simple calculations are pretty safe, but many calls to the AcroForms APIs are not supported.

Having said that, each release improves the compatibility.  ES4 SP1 added support a number of new events which improved compatibility with the XFA/PDF apis.

Regards,

Rob

Rob McDougall | Senior Technical Architect | 4Point | www.4Point.com

[geebeelc]

To be able to render xfa based forms on iPad / smartphone devices you have two options
One is to use mobile forms module introduced a whe back with Es4 sp1. This allows you to render xfa based forms as html5 forms
The other option is to use create adaptive form based on the xfa based form you already have. The adaptive form capability was released in AEM 6 . The main difference between AF and mobile forms is that the AF adapts to the device and adjusts accordingly. Also it allows you far greater control in designing the form.

[Duane Nickull]

I¹d like to weigh in on this again. XFA, and PDF in general, was *never*
designed to run on a mobile platform. There are many layout constraints
and rules that are not nearly good enough for mobile. The basic object
models and event models are also not aligned with mobile technology.
Listening for window events or mouse hover events in mobile is a
non-starter as they are not used. Some can be cast into touch events but
most are merely ignored.

PDF is also very ugly for mobile based on the mouse focus events and
rules. If you have a large form open, first and foremost you notice the
³keyhole browsing² pattern. This is like looking at a room through a
keyhole, hit optimal. Secondly, the PDF focus changes based on the mouse
whereabouts gets ugly real fast. When a cursor is dropped into a form
field and that field gains focus, the entire PDF shifts around. Other
components are forced to re-render and layout again based on their new
dimensions. There are also things happening that you cannot see that
still take up computational resources.

The long and short of all this is that PDF was not intended to run on
mobile devices. HTML5 was also not but it is clearly more aligned with
the mobile methodology. It is really up to the author of the forms to
build mobile friendly forms. Instead of a table layout where form fields
are side by side, it makes more sense to use a flowed vertical layout. If
something is not in the active viewing area, in most cases it is probably
best not to be running scripts or executing instructions for that items
unless its use is critical to the form area being viewed.

Ideally, the best option is a native application. From an architecture
perspective, it is the way things were meant to be done. Unfortunately,
the skill or resources to write an application, get it passed in the app
store etc are beyond many people.

This is why we decided to build a hybrid approach. A native mobile app
with a forms model, extending from HTML5, that can render forms within the
native app. The model I worked on allows us to optimize the form
composition for the best native mobile experience. Using a web view in
native mobile languages, we can display a form and control the elements in
a manner that is best suited for many users. It is not 100% foolproof at
this point but each day we get closer to a better solution.

So your choices are:

1. Convert to HTML 5 (or rather ³express² the form in HTML5) - OK but home
hiccups;
2. Use PDF on mobile (worst solution, clumsy and clunky)
3. Write native (expensive to operate and maintain plus difficult upkeep)

None of these seemed to be an ideal solution. That is why I have been
focusing on developing a better solution. What we have is not 100% ready
for release, but we are seeking some testers in the next few months.
Anyone who is interested, please let me know off list.

Duane Nickull
******************************
CTO - Hot Tomali/Cientis/Cheddar Labs
www.hottomali.com

NOTICE: This e-mail and any attachments may contain confidential
information. If you are the intended recipient, please consider this a
privileged communication, not to be forwarded without explicit approval
from the sender. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this e-mail and destroy any
copies. Any dissemination or use of this information by a person other
than the intended recipient is unauthorized and may be illegal. The
originator reserves the right to monitor all e-mail communications through
its networks for quality control purposes.

[Rob McDougall]

Hi Duane,

As one of the people involved in designing XFA, I’m afraid I have to take issue with some of the points in your reply (and in stating what XFA was or wasn’t designed for).  You lump XFA and PDF together in your first paragraph and then spend the rest of your reply talking about the shortcomings of PDF when the two are not, strictly speaking, synonymous.

XFA was designed from the get-go to allow a form to be presented on a range of devices with a range of capabilities.  Please don’t confuse the way people typically use XFA with what XFA is capable of.  Using XFA you can design forms for mobile that are responsive to the target device.  It is just more work to build a responsive XFA form (just as it is more work to build a responsive HTML page).

XFA was designed to be a domain specific language for defining forms.  It is designed so that you can build a form once and present it in a variety of technologies (including PDF, Postscript, PCL, HTML, and so on).  If you build a static form, it will be static on all devices.  If you build a responsive form, it will be responsive (within the limits of the device/presentation medium).

XFA does lack touch events.  This is a shortcoming for forms on mobile devices.  Until recently everyone, including the browser makers, expected that it would be possible to unify the touch and mouse event processing.  After many attempts, however, people seem to be giving up and accepting that the two are different enough that a unified model isn’t possible.  I hope that this means that XFA will one day soon have touch events added.   

Most of the rest of your reply talks about the shortcomings of static PDFs on a mobile device.  That is fair enough.  Adobe recognizes those shortcomings.  That is why the option of generating HTML5 mobile forms was developed.  I believe that approach falls under choice #1 (“express the form in HTML5 - OK, but has hiccups”).  I’m not sure what hiccups you’re referring to.  We have successfully developed mobile solutions based on this approach with multiple customers (and more coming).

I wish you the best on your “better solution”, but you’re really selling futures here.  Unreleased software always compares well against established approaches.  I hope that a year from now we’ll be comparing two sets of released software and a more meaningful dialog can ensue.

Regards,

Rob

Rob McDougall | Senior Technical Architect | 4Point | www.4Point.com

[Duane Nickull]

Rob:

You are correct.  XFA != PDF.  I should have made that clearer.  My points stand about PDF though.

XFA captures the model of a form very well IMO and I always wondered why Adobe never promoted XFA more.  Ideally, a developer should be able to go from XFA to any format for any device.

The Hiccups per se are not a shortcoming of XFA, just a fact of life.  Form designers often are not strict enough in the way they develop forms.  If one were to use XFA properly, there are not many issues to convert the form to HTML.  What I am referring to often is that the Form Designer uses a plain text field to place a form field title or other text near a form field rather than use the XFA caption for that form object.  When this happens, it is not easy to build HTML because you don’t have any way to programmatically see that the form title is connected to the form field.  OTOH, if one uses XFA and the form caption declaration properly, it is known that the caption text is associated with the form field.

The other issues also come from forms that are basically flat, built by someone who scanned a paper form and simply placed a layer over top.  The text and other items cannot be easily converted to HTML5.

To allow for a perfect conversion, the form author must have the discipline to properly design the form in the first place.

Is there any possibility that XFA itself will evolve?  What are the routes that this could take if it were to happen?

Duane Nickull

******************************

CTO - Hot Tomali/Cientis/Cheddar Labs

www.hottomali.com

NOTICE: This e-mail and any attachments may contain confidential information. If you are the intended recipient, please consider this a privileged communication, not to be forwarded without explicit approval from the sender.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. The originator reserves the right to monitor all e-mail communications through its networks for quality control purposes.

From: Rob McDougall <rmcd...@gmail.com>
Reply-To: Adobe LiveCycle Developers <live...@googlegroups.com>
Date: Thursday, December 18, 2014 at 8:39 AM
To: Adobe LiveCycle Developers <live...@googlegroups.com>
Subject: Re: Does Adobe Livecycle forms work in Apple IPAD/ Android devices ??

[Brian Kalbfus]

I'm enjoying this thread!  This is reminding me of Microsoft's JVM that earned much scorn and lawsuits because it allowed developers to write Java code that doesn't work if you're not running their JVM.

A developer on a "cross-platform" technology such as XFA is led to believe that if he can code it and it works one place then it will work other places.  I've made this assumption with HTML:  I coded upon the xfa specifications (I think) and found that the Mobile Forms HTML5 engine in ES4 has not implemented key parts of it yet.  For instance, events don't "bubble" as they do in Reader, xfa.data doesn't exist to be scripted against.  I would rather have Mobile Forms implement XFA entirely before worrying about porting PDF functions.   PDF is just one platform - I understand that I can't create Reader's app.thermometer in HTML.  In an HTML platform I expected Javascript and basic event behavior to be a given.

Taking XFA and translating into a different format yourself with a new tool is a possibility also that crossed my mind - thus I see Duane's tack.

-Brian

[Rob McDougall]

>Is there any possibility that XFA itself will evolve?  What are the routes that this could take if it were to happen?

Well, for all practical purposes Adobe controls XFA.  It is evolving (as you can see the spec page - it's up to v3.3) however control of it is firmly in the hands of the Adobe software developers and architects.  It means that changes to the spec are driven by features that they wish to include in their products.  This has its good and bad points.  On the plus side, any changes to the spec are implemented in a popular platform (Adobe Reader and Adobe LiveCycle), so they are immediately usable.  On the minus side, they are subject to the whims, politics, and changing priorities of a large corporation.  This can lead to inconsistent leadership.

If someone outside of Adobe wants to influence the evolution of XFA, then there aren't any easy paths.  Since Adobe controls it, you have to make it in Adobe's best interest to make whatever change you want.  Adobe listens to its customers, so having a large customer request a feature is one way.  The only other way I can think of is to create a XFA software implementation that rivals Adobe Reader in popularity.  Then interoperability with your implementation will become important to them. :)

Having said that, if someone wants to use XFA as the basis for a software implementation, then that's fair ball.  They can add whatever extensions they want or need to it. I suspect that if someone had an XFA software implementation that implemented touch events, then if Adobe wanted to also implement touch events, then they would look closely at how the independent implementation worked before implementing their own.  Of course, they're under no obligation to be compatible.  That's one of the benefits of being the 800-pound gorilla - you can take whatever side of the bed you want.

I don't want things to sound bleak.  They aren't.  Adobe is a benevolent dictator, but it's their spec.   They are going to do with it what they will.

Regards,

Rob

Rob McDougall | Senior Technical Architect | 4Point | www.4Point.com

[Rob McDougall]

> I would rather have Mobile Forms implement XFA entirely before worrying about porting PDF functions.

I hear you.  I've had similar issues when converting forms designed for PDF into mobile forms.  I've also been on the other side of the fence however and so I understand the competing pressures on the Adobe development side.

The development team at Adobe aren't any different than you and me.  They don't have infinite resources, infinite budget, and infinite time.  They have a set number of people, a set budget and a pre-defined release schedule.  They fit as much work as they can into the time between releases.  This means that they have to prioritize some things and defer others.  This means that some things don't get implemented right away and some things may not get implemented at all.  That, unfortunately, is the reality of running a software development shop in the real world.

They have tried to prioritize the things to the benefit of their users.  I am sure they looked at each feature and compared importance and popularity of that feature with the cost to implement.  The most important and popular items as well as the lowest cost items were implemented.  The high cost, low value features may not have been implemented.

Unfortunately, when you find a feature that you need missing, there's no quick way to get it implemented.  The time from conceptualizing a release to the point where the release goes GA is probably 18-24 months.  When we see a LiveCycle or Reader GA release hit the streets, the developers have already forgotten about that release because their head is buried in the _next_ release that they've been working on for the last 6 months but is still 12 months out from GA.

When I encounter issues like the ones you've encountered, I generally raise it as an issue with Adobe support.  I provide them with a PDF and HTML examples that demonstrate the problem.  I do my best not to let them close an issue until they confirm that a bug report has been raised with development (often they are focused on providing a workaround so that they don't have to log a bug, but I find that with a little logic and a lot of persistence, I can usually get the bug logged).  Having a bug logged doesn't guarantee a fix however it does highlight that at least one person is using the functionality in question.  If enough reports are made, then the Adobe developers will notice.

Personally, I am impressed by what they have done in the mobile forms codebase.  Re-implementing almost all the XFA engine in Javascript is no small task.  Because the code is all in Javascript, it's all visible and you can use a debugger to examine it.  I've looked at it and am impressed by the implementation.  Yes, there are a lot of places where it is incompatible with the PDF implementation and yes, that leads to if statements that contain target-specific code.  That's unfortunate, but in my mind, it doesn't take away the achievement of what they have produced. There are always going to be incompatibilities when you have multiple implementations of the same thing, however over time, if we log the issues we encounter with Adobe, I believe things will get better.

Regards,

Rob

Rob McDougall | Senior Technical Architect | 4Point | www.4Point.com