Questions about the HTML doc plugin

Get Started | Login

Discussion Forums > Plugins, Customizing, Source Code

Replies: 6 Views: 97

chris1 Code is Art Posts: 3862 Reg: Aug 10, 2012 Austin, TX 50,120	confirm \| cancel 09/20/12 09:57 AM (13 years ago) Questions about the HTML doc plugin I have a couple questions about the "HTML doc" plugin. 1) If I load the file from a URL, how does this differ from using the "Custom URL" plugin? Will the app still try to connect to the specified URL every time the user clicks on that screen? Or will it download the html file into cache and allow offline use? 2) What does the "force refresh" option do? I have a local html file stored in the app which uses a form to send to an online php file. Ideally I'd like to redirect the user back to the local file when done, but I can't figure out how to do this. If I include a back button, it doesn't reload the javascript because of the way jQM works. And if I have the 'force refresh' option turned on, simply clicking the tabbar icon for the screen doesn't reload the local file with javascript. Instead, I have to include a back button and a refresh button, hoping users will click the back button and then click the refresh button. Obviously, this is not ideal. Is there a better solution? Thanks! Title Comments I have a couple questions about the "HTML doc" plugin. 1) If I load the file from a URL, how does this differ from using the "Custom URL" plugin? Will the app still try to connect to the specified URL every time the user clicks on that screen? Or will it download the html file into cache and allow offline use? 2) What does the "force refresh" option do? I have a local html file stored in the app which uses a form to send to an online php file. Ideally I'd like to redirect the user back to the local file when done, but I can't figure out how to do this. If I include a back button, it doesn't reload the javascript because of the way jQM works. And if I have the 'force refresh' option turned on, simply clicking the tabbar icon for the screen doesn't reload the local file with javascript. Instead, I have to include a back button and a refresh button, hoping users will click the back button and then click the refresh button. Obviously, this is not ideal. Is there a better solution? Thanks!

GoNorthWest buzztouch Evangelist Posts: 8197 Reg: Jun 24, 2011 Oro Valley, AZ 1,000,000	09/20/12 11:36 AM (13 years ago) Hi Chris, I think the intention of the Custom URL screen is that you would use it to load any type of online activity that can be accessed via a URL, including standard HTML documents, while the HTML Doc screen is intended (I'm guessing) to be used just for HTML docs, and can provide online and offline access to the resource. For any resource that is accessed via a URL, Force Refresh is automatically used, whether you turn it on or off. The reason for that is that getting the data requires a call to the URL, which naturally brings down the most latest version of that resource. The device will also cache it so it should be available in an offline mode. Not sure why you would want to force refresh a local file, because only one version of it would exist until you update the app with new content. Or am I not understanding you correct? Mark Comments Hi Chris, I think the intention of the Custom URL screen is that you would use it to load any type of online activity that can be accessed via a URL, including standard HTML documents, while the HTML Doc screen is intended (I'm guessing) to be used just for HTML docs, and can provide online and offline access to the resource. For any resource that is accessed via a URL, Force Refresh is automatically used, whether you turn it on or off. The reason for that is that getting the data requires a call to the URL, which naturally brings down the most latest version of that resource. The device will also cache it so it should be available in an offline mode. Not sure why you would want to force refresh a local file, because only one version of it would exist until you update the app with new content. Or am I not understanding you correct? Mark

chris1 Code is Art Posts: 3862 Reg: Aug 10, 2012 Austin, TX 50,120	09/20/12 12:22 PM (13 years ago) Mark - thanks for the response. From what I understand of your response, it would seem that the URL option of the 'HTML doc' plugin is a duplication of efforts of the 'custom url' plugin - just with more limited functionality. As for the more important question, the reason I need to refresh a local file is to run the javascript contained therein to altar certain page elements. If the file were on the webserver, I could create a back button that is an anchor link with rel="external" to force loading of javascript. But since I'm using a local file, I don't know how to do this. (Also note that I need to use the local file option due to the way my app handles localStorage info for this screen and others). Comments Mark - thanks for the response. From what I understand of your response, it would seem that the URL option of the 'HTML doc' plugin is a duplication of efforts of the 'custom url' plugin - just with more limited functionality. As for the more important question, the reason I need to refresh a local file is to run the javascript contained therein to altar certain page elements. If the file were on the webserver, I could create a back button that is an anchor link with rel="external" to force loading of javascript. But since I'm using a local file, I don't know how to do this. (Also note that I need to use the local file option due to the way my app handles localStorage info for this screen and others).

AlanMac Aspiring developer Posts: 2612 Reg: Mar 05, 2012 Esher, UK 37,120	09/20/12 01:32 PM (13 years ago) On your second question, I also use an html form stored in an app as a local text/html page, which 'posts' to a server side script. I use the navbar on the form page which has a back button & when the form is sent I have a success page. When I hit the back button on the page, it goes back to the menu that the form is called from, not the form itself. That is because the BT page itself hasn't changed, but the content has and the navbar back button takes you back from the BT page - it isn't an html back button. From what I know, I think that is probably the best you could do here. On the other hand, if your html form was remotely hosted, you could probably use html navigation to get back to the form, if I understand your scenario. Comments On your second question, I also use an html form stored in an app as a local text/html page, which 'posts' to a server side script. I use the navbar on the form page which has a back button & when the form is sent I have a success page. When I hit the back button on the page, it goes back to the menu that the form is called from, not the form itself. That is because the BT page itself hasn't changed, but the content has and the navbar back button takes you back from the BT page - it isn't an html back button. From what I know, I think that is probably the best you could do here. On the other hand, if your html form was remotely hosted, you could probably use html navigation to get back to the form, if I understand your scenario.

GoNorthWest buzztouch Evangelist Posts: 8197 Reg: Jun 24, 2011 Oro Valley, AZ 1,000,000	09/20/12 02:53 PM (13 years ago) Hi Chris, Yep, I think you're right about the two different types of screens. But, they're not my creation, so I'm not entirely sure. I do know that I typically use the Custom HTML screen for accessing a particular website, and the other screen for HTML that I create myself. As for your second question...not sure what to suggest! @AlanMac has some good ideas...hopefully others will chime in also. Mark Comments Hi Chris, Yep, I think you're right about the two different types of screens. But, they're not my creation, so I'm not entirely sure. I do know that I typically use the Custom HTML screen for accessing a particular website, and the other screen for HTML that I create myself. As for your second question...not sure what to suggest! @AlanMac has some good ideas...hopefully others will chime in also. Mark

chris1 Code is Art Posts: 3862 Reg: Aug 10, 2012 Austin, TX 50,120	09/20/12 03:18 PM (13 years ago) ok I figured out a hack to do this. It involves multiple files. Here's the setup: ******************** file1.html (locally hosted) <!DOCTYPE html> <html> <head> <script type="text/javascript" src="http://code.jquery.com/jquery-1.6.3.min.js"></script> <script type="text/javascript"> $(document).ready(function(){ window.location.href="file2.html" }); </script> </head> <body> </body> </html> ****************** file2.html (locally hosted) contains webform to send to webform.php ****************** webform.php (server hosted) <?php some php here ?> <html> <head> <script type="text/javascript"> window.location.href="file3.html" </script> ******************** file3.html (server hosted) <!DOCTYPE html> <html> <head> <script type="text/javascript" src="http://code.jquery.com/jquery-1.6.3.min.js"></script> <script type="text/javascript"> $(document).ready(function(){ $historyl = window.history.length * -1 + 1; // alert ($historyl); window.history.go($historyl); }); </script> </head> <body> </body> </html> Comments ok I figured out a hack to do this. It involves multiple files. Here's the setup: ******************** file1.html (locally hosted) <!DOCTYPE html> <html> <head> <script type="text/javascript" src="http://code.jquery.com/jquery-1.6.3.min.js"></script> <script type="text/javascript"> $(document).ready(function(){ window.location.href="file2.html" }); </script> </head> <body> </body> </html> ****************** file2.html (locally hosted) contains webform to send to webform.php ****************** webform.php (server hosted) <?php some php here ?> <html> <head> <script type="text/javascript"> window.location.href="file3.html" </script> ******************** file3.html (server hosted) <!DOCTYPE html> <html> <head> <script type="text/javascript" src="http://code.jquery.com/jquery-1.6.3.min.js"></script> <script type="text/javascript"> $(document).ready(function(){ $historyl = window.history.length * -1 + 1; // alert ($historyl); window.history.go($historyl); }); </script> </head> <body> </body> </html>

David @ buzztouch buzztouch Evangelist Posts: 6866 Reg: Jan 01, 2010 Monterey, CA 78,840	09/21/12 03:38 AM (13 years ago) @chris1: Just a quick comment...Yes, there is some duplicate functionality across some of the screen types. But, there are cases where subtle differences become important. Generally speaking, HTML docs and Custom Text / HTML screens are best for quick and SIMPLE screens, nothing too complex. More times than not, complex HTML with external .css, .js and other resources are very tough to put together in the app's binary without a deeper understanding of how it's all connected. For this reason, if it's complex, a remote URL is better. Speaking of complexity: Using HTML to create complex UI's in a native mobile app isn't generally the best approach. It's easy, that's for sure, but it's not ideal sometimes. Most end users and app stores appreciate native functionality and it's tough to craft HTML that doesn't feel "webby." It sounds like you're working with forms and need to gather some input. HTML of course does this well and we're all very comfortable using it (devs) and interacting with it (end users) Because you seem to have a good grip on technology, you may be well served by experimenting with creating your own UIViewController with native form inputs and controls. You'll be surprised at how quickly you can pull this off and the end result can sometimes be much better. It all depends on how interested you are in "creating" vs. just "getting it done." Love the hack in the previous post! Comments @chris1: Just a quick comment...Yes, there is some duplicate functionality across some of the screen types. But, there are cases where subtle differences become important. Generally speaking, HTML docs and Custom Text / HTML screens are best for quick and SIMPLE screens, nothing too complex. More times than not, complex HTML with external .css, .js and other resources are very tough to put together in the app's binary without a deeper understanding of how it's all connected. For this reason, if it's complex, a remote URL is better. Speaking of complexity: Using HTML to create complex UI's in a native mobile app isn't generally the best approach. It's easy, that's for sure, but it's not ideal sometimes. Most end users and app stores appreciate native functionality and it's tough to craft HTML that doesn't feel "webby." It sounds like you're working with forms and need to gather some input. HTML of course does this well and we're all very comfortable using it (devs) and interacting with it (end users) Because you seem to have a good grip on technology, you may be well served by experimenting with creating your own UIViewController with native form inputs and controls. You'll be surprised at how quickly you can pull this off and the end result can sometimes be much better. It all depends on how interested you are in "creating" vs. just "getting it done." Love the hack in the previous post!

Login + Screen Name Required to Post Login to participate so you can start earning points. Once you're logged in (and have a screen name entered in your profile), you can subscribe to topics, follow users, and start learning how to make apps like the pros.