Hello to all, After using android V3, my HTML doc is not viewed correctly. It is viewed as if it is a word doc, please see picture, If it does not require complicated coding or changes in the codes, I will be fully appreciative of your assistance. https://dl.dropboxusercontent.com/u/78147416/Screenshot_2013-09-16-08-25-16.png NSaya

If you hit Open Document, what app does it open the doc in? If it's something like Chrome, then it's actually viewing it as an HTML document. However...it should be showing in the app itself. Is this a Custom URL screen, or an HTML screen? Mark

Mark, I think he means the HTML Doc plugin I have the same issue. Looking at the code, it's doing what it's supposed to be doing. But the behavior is different than the previous android (activity based not fragment based) version (API 8). What I want is for my html document to open up 'in the plugin' and not have to press a button to use it, much less use a helper app. Right now it's very similar to the PDF plugin for Android. I was hoping David might take a look at it, but I know he's probably busy, and I haven't had a chance to play with that yet. On a lighter note, I have almost finished offline maps for Android, but still playing with markers. Then on to my weather plugin for Android. And if by then no one has gotten to it, I'll work on some kind of 'old school' HTML Doc plugin cause I need one. Cheers! -- Smug (And a fairly complex php project thrown in for good measure)

thank you Mark When I hit, a window with four options appears, Only HTML viewer open it, the rest views it like HTML editor. please see the picture, It is an HTML doc in the assets folder HTML viewer opens HTML Doc but the links in the HTML doc is not opened. Target file for the link is also in the assets folder, same folder. It was working with andriod V2. please see second link. https://dl.dropboxusercontent.com/u/78147416/Screenshot_2013-09-16-21-09-27.png https://dl.dropboxusercontent.com/u/78147416/Screenshot_2013-09-16-21-18-18.png NSaya

Looks like it must be a bug, based on Smug's report, and the details of your report. Hopefully we can get David to look at it soon! Mark

Thank you Mark and thank you Smug, Yes, lets hope for David's attention, Cheers NSaya

Same thing happening for me. As it is my first Android app I thought it was normal (but pants). Glad to hear we might get a fix soon. Farcat

Hey guys.. Yup, like @smug says, this is intentional. It may not be ideal, and it may not be what everyone wants but it's by design. The idea is that all of the document based plugins I've made (PDF, Word, Excel, HTML) will open the document in the app on the device that the end user chooses. The screenshot here (thanks @Nsaya) is a good example of what the user should see: <a href="https://dl.dropboxusercontent.com/u/78147416/Screenshot_2013-09-16-21-09-27.png" target="_blank" rel="nofollow">https://dl.dropboxusercontent.com/u/78147416/Screenshot_2013-09-16-21-09-27.png</a> End users should not need to tell their Android device what viewer to use after the first time. Because Android owners can have multiple document viewers and apps on their devices the Android OS shows a "chooser" option so a user can decide what's best. iOS does not do this. This behavior is for the document type plugins. But, the Custom URL plugin does not do this. It's not opening a local document, it's opening a remote URL. The Activity based plugin (for the older plugin) opened the HTML doc. directly in a built in WebView and lots of folks didn't like that. Again, not everyone uses the same app to view html docs in on Android. So, today, the Fragment based plugin shows the "open with option" and the older Activity based plugin does not. I'm not sure what the best approach is but this is how it's working. I like the idea of consistency between the document type plugins but also understand how this may not be the best approach for HTML. Hmm...maybe an option in the control panel like: "Allow user to choose which app" or "Open in built in WebView" or something like that. Input in this post welcome....

The only 'objection' I have, is that the behavior is different than past experiences. I was expecting an Orange, and I got a Tangerine. A Tangerine still tastes good, but it's not what I was expecting. The control panel option sounds great, if easily implemented (on your end) otherwise I'll probably just pound out an old school web view like the previous version. I know you've got a million things on your plate; whatever suits you is fine by me; I can cope. Cheers! -- Smug

Yup...I agree, it sucks that it's different. And, I was very very wrong when this topic came up a few weeks ago (by you I think). I was thinking the Custom HTML plugin was the better approach but that plugin does not allow an app owner to "point" to an existing document (in or out of the project). Duh! my fault completely...too many things to remember! So, like you said, and from what I'm hearing, it may be that the HTML doc plugin should just go back to the "old way" and toss the idea of consistency with the other doc type plugins. This make sense too because the others require a third party app to view (like a PDF) but HTML does not. I'll see if I can hammer this update out in the next few days. In the meantime, have a look at the Activity based version of this plugin, it's not that tough to understand how to change it "back" to the old way :-)

Ok, it's probably not perfect. I tested it 'once' with the Android simulator, and consider it a 'kit' because it definitely is not in complete plugin form just yet (I *just* finished it about 10 minutes ago). https://dl.dropboxusercontent.com/u/115208762/Sw_smugwebview/Sw_smugwebview.zip However, here is my rendition of the old HTMLDoc plugin for Android, tentatively named 'Smug Web View'. This zip file *only* contains the android java and xml file to be used in BTv3 android projects. You *have* to know where things are supposed to go to use these files. I'll clean it up and make a plugin out of it tomorrow if I have more time. Cheers! -- Smug

Thank you David for responding to this post and thank you Smug for sharing the files and all other helps. As you see in the picture, "open document" button catchs only those four irrelevant options( apart from HTML web viewer); not chrome, opera or other browsers. With older version, I used to use webkit, java script,CSS to make menus in HTML doc and link them to target files in the same folder. Those menus were working perfectly, but with android V3 it is not working. Like this file (person like me with no coding experience may need this). By this I tried to apply simi-JQuery buttons. Of course my friend who knows coding helped me. I don't know how much it is professional, but it was working very well with android v2, ha ha ha, https://dl.dropboxusercontent.com/u/78147416/BAB12.html Dear David two more problems have been raised by buzztouchers; Send email plugin is not working and Statusbar is not hidden despite I selected it to be hidden when I configured the themes. regards Nsaya

Email plugins: Strange, can't seems to work fine in our testing. Looking into it.. Status bar: We should have been more clear about this for v3.0. Android's design patterns with newer Android devices strongly recommend NOT hiding the status bar. This should work anyway, even if it's not a good idea. You're right in that it's not being honored in the v3.0 package - we're working on a fix....

Hi Smug! Thank you once again for the code, I solved my problem, there was one small issue: when I hit back button, no mater which page was open, it returned to simple menu page. I mean, my HTML had a link to another HTML. When I opened that HTML page, and hit back button (device back button) it took me not to previous HTML, rather to simple menu page. When developing this code as a plugin, I think it would be better if this is taken into consideration. For sure if I can, I will be the first to buy your plugin. Paypal don't cover my country. about send email error, You are right David. It works, I re downloaded my code and after some modification I ran it. The plugin is working. I could not find why it was not working with first download. Anyway, here is the link that it was reported not working: https://www.buzztouch.com/forum/thread.php?tid=F7C571DAEFEBE3D97D5E6DA&currentPage=1 regards Nsaya

I wasn't planning on selling it; it's basically Davids old plugin. Cheers! -- Smug

Yes please fix the HTML doc to how it was in 2.0! Specifically, I was calling the jquery mobile style sheets using html doc screens, which can't be done in customHTML without getting an infinite loop. @Smug, how can I use those files you linked to restore the old functionality in my app?

Your best bet is to create your project, and replace the code (keep an eye on what goes where) in the 'new' htmlDoc plugin with my sample code. There is a java file, and an xml file. I haven't messed with it since then, so it may still need a little tweak or two… Cheers! -- Smug

So did we have any good news about returning the Html doc to previous state as it was in V2 ? i was so usefull when you wanted to display informations and text contents as part of the application and not as different content . SmugWimp the files in the zip folder called ''sw_smugwebview.xml'' and ''Sw_smugwebview.java'' are for replace the internal code of the files html doc ? http://i30.photobucket.com/albums/c316/caslor_1978/diafora/htmldoc_zps11763079.jpg

Those files have code that will work, but it's not in 'finished plugin' format. If you need a current plugin with the old style behavior, you'll have to cut/paste the new code over the old. But be careful! I did not include 'all' functionality into my replacement code. It will display a file, and that's about it. Any email link, or back button, or any 'additional' functionality has not been implemented. Cheers! -- Smug

thanks :)

Hey guys, I was wondering if anybody got that HTML issue sorted. I am very much a noob in Android and I am scared senseless to break something in my shiny new app. @Smug, any luck with the plugin you were working on by any chance? :) Frankly I am surprised that this thread hasn't attracted more posts. Surely the new way HTML doc open is a big pain in the backside for many people? Farcat

I'm kind of finishing up on another plugin at the moment. When I'm finished, I may redo that one and publish it… but it'll be a couple of days or a couple of weeks, depending on my current Android issues… However, things could be speeded up nicely if anyone knows how to perform a search in Android using a custom array adapter… it's driving me nuts, lol! Cheers! -- Smug

Thanks Smug! All the best in your search. :) Farcat

Hi everyone, I'm having lots of trouble with the html doc change, from the "old school" to the current behavior...could you please help me? If I buy smug plugin, will I have to change, in my app control panel, all the html doc screens to "smug screens"? That could be a problem, considering I have more than 150 html docs...furthermore, David suggested that 1)it's not that hard to change it "back" to the old way: does anyone know how to do it? 2) he would include a "Open in built in WebView" option in the control panel...will this option come out soon, David? Thank you in advance for your time! João Barata

Hi, I'm experiencing now in Android the issue described in this old topic, I'd like to know if there are updates on solutions to fix it. I created about 50 HTML Doc screens in my app in iOS. Now I tested in Android and I noticed that it asks the user to open the document, different behavior from BT v2 that the document opens automatically. Thanks.