Our business Xojo Web Application runs quite good. Now we wanted to do a desktop app for mac and pc that runs the web app in a browser, so we can pass some parameters, basically for security purposes. It will be basically a dedicated browser. At this point we use chrome or safari to use the web app. There is nothing special added like javascript or external plugins.
But it seems that the HTMLviewer component has not been updated for a while. When I call the web app from the Xojo app, it says:
Your browser is not supported. Please try using one of these other browsers:
Mozilla Firefox 17 or later
Google Chrome 37 or later
Apple Safari 6.1 or later
or Microsoft Internet Explorer 9 or later.
What it actually surprises me is that the HTMLviewer functionality is detected as less than those old browsers.
As a quick and dirty solution I faked the user agent like so: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/601.6.17 (KHTML, like Gecko) Version/9.1.1 Safari/601.6.17
But there should be no need to do it. Please update the component!
Or handle the unsupported browser in your web app
Then you can set your own custom user agent so you know its your desktop app and not something spoofing Safari
You may even use that for custom code for your desktop app
There’s a Feedback case for updating the component somewhere.
If you don’t want to fake the UserAgent string, you can also use the AllowUnsupportedBrowsers event on your web app.
Best would be to do both, use a special custom user agent string for your desktop app and allow just that unsupported browser on your web app. That way if issues occur specifically due to the HTML Viewer you’ll be able to know.
I think you are being a little unfair. I don’t see this as a component not being updated issue as much as you need to update your web app to allow unsupported browsers.
Exactly what user-agent should the HTMLViewer be using in the desktop app? It’s not Safari, nor Chrome, nor FireFox, nor Internet Explorer. The Web app framework naturally accepts a limited number of browser types because those are standard. If you allow unsupported browsers (as Norman said) you can accept whatever connects to it.
The thing is that for another project, I am working on a desktop app that runs an HTML5 web application, not developed on xojo but in pure javascript. And there is where am worried that some issues could come. The user agent string gives just a hint of what are the internal rendering capabilities of the component are. The javascript engines are tuned for not so old browsers.
I wouldn’t be super concerned. Unless your HTML 5 web app is running super complex new age features (like WebGL) you shouldn’t see issues.
By the way, if all you’re doing is wrapping web apps in a HTML Viewer you can find tutorials on how to do that in Xcode with a quick google search (really not hard.) That way you can have access to the latest renderer.
Yes, is uses WebGL. They are game applications. Sound, effects, Etc.
Also have visual studio with chromium web viewer for windows and Xcode with wrapped webapp for mac.
But wanted to use Xojo since a), I already paid the license and b) it is easier to maintain a single xojo app.
Just because you paid for a tool doesn’t mean it’s the one best suited for the job.
I can’t find the Feedback case I thought there was for updating WebKit, so you should make one.
Well we didn’t paid the Xojo License for the html wrapper specifically. The main use we have is the web application that handles our database. It has worked fine, but even there I had to create a lot of php modules for more dynamic updating and features. And you are right, not need to be paid to be good. Personally have been using Visual Studio and Xamarin for cross platform apps. Xcode is free as well.