Hey there, it seems that Chris is not around lately, sure hope he comes back soon! In the meantime the HTML Pro, which is for sure one of the most powerful plugins, does not work on Android 4.4.4 and probably beyond either. This is a major issue as I am probably not the only one using this plugin and many of my apps are not working anymore. Sooo, anyone here to fix this? Regards Leon

probably all about the change in Custom URL Handling: https://developer.android.com/guide/webapps/migrating.html Not sure how to do the changes though.

Hi @LeonG, I was commenting on another post in another thread about this. The "standard" URL plugin (the one I created forever ago) was reported to also "not work" on Andorid 4.4.4. This confuses me, I'm running a tablet with 4.4.4 on it and the URL plugin seems to work fine. Whatever the issue on Chris' is could surely be the same as the standard one. I think Chris' is based on my original work? https://www.buzztouch.com/forum/thread.php?tid=A5E2B1BA72B7BB3C3981EB7&currentPage=1 Because you've worked this far longer than the posters on the other thread, I'll ask you to clarify something. Please clarify that this project is compiled with Android 4.0 but running on a 4.4.4 device. Just making sure while we slueth this out.

Wow - looks like Google went and made an update to Android that wasn't backward compatible in certain circumstances (HTML Pro being one of them)! Great... Good news, there is a solution. Bad news, it's going to be a pain in the butt for anyone using my plugin. Essentially, all links have to conform to the URL standards that are in place. That means you can't have a link that looks like: <a href="someItemIdHere">link</a> Instead, it must look like: <a href="buzztouch:someItemIdHere">link</a> Easy enough to change the code of the plugin to handle these type of urls. I should have an update for you tonight. But, here's the challenging part: You (and everyone else) will need to update all the HTML documents they created in all their apps that use HTML Pro and then recompile using the updated plugin and then submit the updated apps to the App Stores.

Was just browing the Google document about the changes. I'm concluding that some Web Content (the HTML) will work fine, and some will not. This explains why my test works as expected. I'm not loading anything terribly complicated (css, javascript, special links, etc). It sounds to me like the does / doesn't work question will come up all the time - depending on the HTML people are trying to load. I've realized this forever now. The expectation when this plugin was created (and everything I've created actually) was that people would a) have control over the html they load in URL screens and b) Understand how HTML works. Meaning, the plugin was design to help people render their own content in their own app. Over the years it's become obvious that many many people load other peoples content in their apps. This means they don't have control over the HTML. This means they can't update / change / improve this HTML content on their own, they are dependent on the author's participation. This isn't good. Continuing to read and understand these changes and expect a ton of questions because of them.

Okay, just uploaded an update. Give it a good test because I haven't had a chance yet. Good news is iOS shouldn't need an update after all. It looks like I had already future-proofed that code, fortunately. *******NOTE: YOU MUST BEGIN THE LINK WITH "bt-app:", FOLLOWED BY THE ITEM ID OF THE SCREEN YOU WANT TO LOAD. "bt-app:" IS CASE SENSITIVE. ANDROID APPS WILL NOT WORK WITHOUT THIS. *******

THX guys! Will test it now and let you know if it works!

Works perfectly! Thx for this quick fix! PS: with Genymotion it is really easy to simulate all the 1 billion android systems :-)

only downside on this is that as we don't have a live/design mode anymore, all running devices don't work anymore as they have to update to the new version with the updated code. Bad :( David, if you read this, please do think how important it is to solve these kind of problems in the future. Always bad if suddenly published apps do not work anymore.

Glad it's working. Unfortunately, this isn't something David will likely be able to fix. It's not a config issue, it's an issue with the way Android now reads HTML documents. In other words, it's an issue between Google and you as the creator of the HTML files. One thing you could do is to make duplicate copies of the HTML files and make the changes in the copies. That way, the old apps could point to the old files and the new apps could point to the new files (using the live/design mode of Buzztouch). Would take a bit more work on your part, but should serve as a workaround. ----------------- Note to David: Along these lines it would be really great to have the bt_config.txt files archived on the server, and have the apps use the versionNumber property from the bundled BT_config.txt file to know which to get. Changes could be made at any time to the current version, but a user could increase the version and archive the old one, preserving it as a static txt file. That way, someone like Leon could archive the app before downloading an updated plugin and submitting to the app stores. Ideally, the bundled bt_config.txt file would automatically populate the versionNumber with the current version when the app project is downloaded.

workaround would certainly be good, but live/design mode is not working anymore since , puuh I don't know, almost 2 years now? Several threads about it, but nothing works! The config.txt solution would be good yes!

Live / Design It's my understanding (I may have this wrong, it's been awhile since I dug into it) that the Custom HTML screen does NOT honor the live / design mode changes like all the other plugins. In other words, the Custom URL plugin type does, the Custom HTML does not. Technical Explanation: Screen data is saved on the backend in a database system. Not a file system. There is an exception in the Custom HTML plugin where files are created on the backend, along with database settings. For this reason, the live / design mode does not honor the "changes" in the HTML creating using the Custom HTML plugin. Live / design mode is honored for all other plugin types. This means that if Chris' plugin allows users to create actual HTML (not use a URL but actually type / paste HTML) then the live / design mode won't work as expected, just like the standard Custom HTML screen. Chris brings up some good ideas about how to change this but doing so is a significant effort for a number of reasons, mostly due to the affect it would have on other complex processes. The idea of using the version number is sound, but also introduces new and other complicated issues. Heck, many users don't even know what the manually editable version number is for anyway. Most folks associate that version number (the one they can enter and change manually) with the iOS or Android version. Crazy I know but it's a major confusing piont about how all this works. It's my opinion that the live / design mode is far too complex to undertand for 99.9% of our users anyway and should be re-thought entirely. This is the biggest reason all the effort was not made to change lots and lots of things in order to support only one plugin type. I think you get the idea. For sure a solution is necessary and for sure @LeonG is right in that the live / design issue is important and should be thought about and addressed so ALL the screen types support it. It's not good that "one screen type" doesn't honor it while all the other do. Onwards and upwards...

totally agree and understand, but have to say that the live/design does not work at all! HTML never worked for that and is understandable but with a workaround all doable, using 2 html files, 1 old, 1 new. Fixing the original live/design mode would give you loads of time to think of something better ;-) Very happy you are back again David, feels like the old days, very motivating!!!

I think live/design used to work in V 2.1.8, but it broke when 3.0 came out.