With the latest version of the Android viewer I've noticed two things:
1 - When I quit the app and re-open it I see the "Sign In" text in the upper left. I tap it once and there is no change, I tap it a second time and it pops up with the box for entering a username and password. With previous versions of the content viewer I don't remember having to sign-in every time I quit and restarted the app. It almost seems as if I'm already signed in after restarting, however the text says "Sign In' instead of "Sign Out".
2 - I've successfully updated a folio for the iPad and it downloaded only the changed article. However when trying to update the same article for Android I got the "can't find files/article..." message so I had to delete that article and import it fresh. I did that, entered the metadata, and dragged it to its proper place in the order of articles. I then saw the update notice on the Xoom for that folio and tapped the view button and the update progress bar was only on screen for a couple of seconds for an article that was approximately 40MB. I viewed the folio and the update hadn't been made, the article looked the same. I then deleted and re-imported all the articles for that folio and the same thing happened, an update available notice but an extremely quick update. I gave it 10-15 minutes in case the server was just slow to see the updates and it didn't make a difference. No update notice after waiting, so I deleted and imported the first article again with the same results, the article didn't actually update. I then tried downloading the whole folio fresh onto my Droid X and it was successful with the changed articles being displayed correctly.
Has anyone else noticed the strange Sign In behavior with the Android viewer? Will the client be forced to tell everyone updating this folio on an Android device to tap the Archive button and re-download before they can get the updated articles? This was what I had to do to correctly see the updated articles on our Xoom.
Andrew
I updated a different folio and had the same issue as #2 above. The new articles I added worked great. An old article gave the error message "Could not update article layouts. Could not find the files for all the layouts." I deleted it, imported it again, and the updated article design didn't come down in the update download from the server. I've had issues with replacing articles in the past and the only way to get it to work was to rename the article in the Folio Builder. I tried this and it worked, the new design updated from the server. Of course this made all of my links to that page stop working so I renamed it back to the original article name and all seems to be working now. I'm still concerned that particular article won't update correctly for the customer.
I'm assuming this is because the folio for the Xoom was created over a month ago before the server updates. I accept that the "could not update article layouts..." error message means I have to delete and reimport any articles that give me this message. My concern is that because the article name is the same in the Folio Builder this is causing problems with updating those articles in the Adobe Content Viewer for Android. Anyone else having these sorts of issues?
The same design updates for the iPad version were easy without any problems.
Andrew
Yes, this problem with hanging articles was the result of a bug that some people experienced a few weeks ago for iPad folios as well. Unless I misunderstand the situation, the fix is to delete and re-create your articles. You should be able to delete and reimport your articles without changing the article names.
Hello Bob,
Yes, that worked for the iPad version, however with the Android version of the viewer the recreated article isn't showing the new files. The content viewer shows the old design, as if the new files weren't being used. The only way to get the new design to download that I've found is to rename the article in the Folio Builder. That's what I was trying to say.
An example would be that the old file was a menu with 3 options and the new file is a menu with 4 options. The Android viewer keeps showing the old version with 3 options, even though I downloaded the update that it told me was available. Only when I "rename" the article in the Folio Builder does the new 4 option menu download to the Android viewer.
Perhaps it just takes a lot longer (over 30 minutes) for files to percolate through the Android viewer when an article with the same name has previously existed. With the iPad viewer the changes showed up as soon as the update was downloaded.
Andrew
Tried updating another article and the same thing happened.
I deleted and re-created a menu page with the same name. The changed menu would not show up. I tried changing the name in the Folio Builder and then changing it back before updating on the Xoom, no change. I tried the sidecar method to force a re-download of all the articles, no change. The only time it changed was when I changed the name in the Folio Builder and then downloaded the update on the Xoom. Since this made the link to the menu from other articles stop working I then changed the name back in the Folio Builder. The biggest problem with this is that it only works for my device, this "fix" doesn't work for others since it appears to be a cache type of problem with the viewer.
I think there is definitely a problem on the Android version of the Adobe Content Viewer with articles not refreshing after that article has been deleted and re-created in the Folio Builder. My only solution is to tell the customers they'll have to Archive and re-download the entire folio. This is not ideal. Can you replicate this issue on your end Bob?
Andrew
Well, after updating to the latest Folio Producer tools and Folio Builder panel I have found that I can get an article with the same name to update in the Android version of the content viewer. I first deleted the old version of the article and then imported the new one with a different name. When I'm having difficulty uploading a large or complex article I've found that naming it something completely different can help. I then rename the article to the original name. It still doesn't update on the device at this point. I then update the newly imported version of the article in the Folio Builder panel (it has to build and upload again) and then the changes are reflected in the updated folio on the Xoom. A bit of a hassle, especially since I have some pages with lots of MSOs and big videos, but it does seem to work reliably. Thanks to those who tried to help.
Andrew
Trying to get it to work on the target device (in our case the Xoom) is the best way to understand the current Android viewer limitations.
The one's I'm most aware of (the last time I checked) are:
- no inline videos, you must play videos full screen
- the in-app viewer (Open in Folio) won't play youtube videos correctly, you must use "Open in Device Browser"
- HTML articles and web views are not up to the iPad version's capabilities
- PDF formatted folios/articles don't pinch/zoom. On the iPad you can only pinch/zoom on pages without any interactivity.
Here's a list culled from the new feature release notes that tracks the limitations and how they've been improved.
http://help.adobe.com/en_US/digitalpubsuite/using/WS67cb9e293e2f1f60-6 abcbe621311f4e52df-8000.html
Release 15
Scrolling is now enabled in HTML articles for the Android viewer.
- You can now create retail folios for Android viewers. Customers can click a Buy button in the Android viewer library to purchase a folio.
- Customers can now restore all purchases in Android viewers as they can do in iPad viewers.
Articles set to Horizontal Swipe Only (“flattened articles”) now work in the Adobe Content Viewer for the Desktop, as well as for Android and PlayBook viewers.
The performance of PNG and HTML articles on Android devices has improved. The Android Viewer supports in-app web view.
Although the Android Viewer more closely matches the iPad Viewer, some features are not yet supported. Unsupported features include flattened articles, inline videos, panorama overlays, and folios exported in PDF format. HTML articles and Web View overlays may have performance issues.
Hi guys,
You all look to be experts in the Adobe Content Viewer. I've built out some presentations that have run successfully on the iPad viewer. I'm now trying to make them work well with Android.
My issue is inline video. I know this is not supported on Android which is fine, but when I add a video, you can open it on Android in full screen, but the only way to automatically go back to the viewer is to move the scrubber to the end of the video. Is there a way to stop the video once it plays so that you can quickly exit the video if you don't want to watch and return to the folio page you were viewing?
help greatly appreciated!
Dan
Thanks Andrew! Good advice. If anyone else has any other video
implementation tips for Android that would be great. I'm under the
assumption that the best (only) way to do it is to have it inline on the
iPad but show up full screen using the media overlay on Android.
Is there a way to embed video in HTML or something that you could create a
back/close button that's more visible on Android?
Hello.
I'm trying to add a video but I'm having problems. Basically, I can see the first frame but when I tap the video (to play), is shows a black screen and the player buttons (play, pause, etc...) and nothing else.
I use a Samsung Galaxy Tab 10.1v and my video config is:
Auto play (checked)
Play full screen (checked)
I'm using the resolution 1290x755px
Need help! Please! ![]()
Another minor bug/limitation with the Android viewer on our Xoom is that videos don't autoplay when a page first opens. It works fine (with a minor flash of the new page's design) on the iPad using the same assets, etc.
I see the forum area for feature requests, but I couldn't find a bug report area on the forum. Maybe it hasn't been added yet.
Andrew
You can now log DPS bugs using the standard Adobe site: www.adobe.com/go/wish
Just started using the Adobe Content View on our Kindle Fire today and realized there were a few things that are not working and causing the Fire to lock up, where I have to turn it off and on.
A lot of the 'auto-play' videos do not play automatically all of the time. They will play sometimes, I have not noticed anything that causes it to play or not play.
Also, one of the videos you have to tap to play and it will play fullscreen, then it is supposed to dissapear. The video plays fine, but as soon as it's done the video turns black and freezes up the Kindle requiring me to reboot it.
I didn't know if these were common issues, it did not seem like anyone else had this same issue.
I have been using these layouts on iPads and they work perfectly, so I know it's not a problem in the build.
thanks!
Andrea
North America
Europe, Middle East and Africa
Asia Pacific