Trying to figure out if Unity's LWRP could run in AirConsole build.
Apparently LWRP is supported in WebGL2 builds, so the question is - does AirConsole themselves fully support it? If not fully - what features are and what are not supported?
I am not very familiar with Unity nor LWRP, but to clarify:
AirConsole and it's games always run in a browser (except on AndroidTV where it may run as a native game). In the end AirConsole is "just" a website or Javascript API. Consequently if the browser supports WebGL 2.0, then it also works with AirConsole.
However, Web GL 2 support seems to be missing on e.g. Safari, which is one of the platforms supported by AirConsole. A game should run on all major browsers.
https://caniuse.com/#feat=webgl2
I hope this explanation helps you.
Related
On the FAQ page for Fluid Framework https://fluidframework.com/docs/faq/#what-browsers-are-supported it says that Fluid will only work on Safari for Mac. To me this means that it will not work on iOS or the iPadOS. I don't think I need to explain why this is a problem for adoption.
So, why won't Fluid Framework work on iOS or iPadOS and is there anything that can be done about it?
Fluid Framework does work on iOS and iPadOS, but the framework doesn't get significant test coverage on those browsers. I just tested a few examples on iOS and they worked (DraftJS, brainstorm.) That language in the FAQ should be changed to reflect that there is no automated testing for iOS, but the team intends for Fluid to work.
In fact, Fluid should work in any JavaScript engine. The requirement is that the JS runtime can load the client libraries (written in JS/TS), load the container, and make a connection to the service.
There are even some (fairly hidden) Node examples in the repo, although there isn't automated testing on those examples yet either.
Full Disclosure: I work on the Fluid team
Is there a good and reliable library or method, or whatever, that can detect if the request is coming from a mobile environment?
I found a few packages, but non seems to work properly. I am looking for a basic/simple one that is able to detect just this: isMobile; isDesktop. Needs to be reliable, up to date and working.
If there is none free, even payed solutions would be acceptable. I am not looking for 100% detection, but I expect that top most popular devices to be detected without problem.
I am looking for a nodejs (express) solution, and/or a PHP one.
For PHP you can use Mobile-detect. According to its official description in Github, Mobile_Detect is a lightweight PHP class for detecting mobile devices.
For node.js you can use mobile-detect.js. It's a port of Mobile-detect to javascript.
DeviceAtlas has a good article:
How to detect a mobile browser by Pawel Piejko.
They have examples with PHP, Java and Python and they have API to use. It is a a paid service but with free trial.
Mobile detection is a complicated problem. Of course it's easy to detect an iPhone with some client-side JavaScript, but mobile devices are not only iPhones or Android phones. And if you want to detect it before running client-side JavaScript like you need here then you cannot rely only on client-side JavaScript.
More options
General options:
WURFL, 51Degrees, OpenDDR, MobileESP, ua-parser, Detect Mobile Browsers.
Node modules:
mobile-detect,
device-detect,
detect-mobile-browser,
sniffr,
dagent,
device-detective,
ismobilejs.
I'm a Microsoft stack developer most familiar with Windows Forms and WPF, but have a need to develop a Linux desktop application that can display some web apps in a modern browser that offers very recent HTML 5, CSS 3, SVG, etc.
I'm thinking GtkSharp running on top of Mono is probably the replacement for WinForms/WPF running on top of .NET which will best leverage what I already know. As for the embedded browser control, I have other requirements strongly advocating CEF over any other solution (although I'm still open to strong suggestions to do otherwise).
Anyone have experience with any of this?
Try looking at CefGlue, it has a CefGlue.Demo.GtkSharp project which would indicate it's possible.
https://bitbucket.org/xilium/xilium.cefglue/
https://bitbucket.org/xilium/xilium.cefglue/issues/108/linux-support
Personally I've never used CefGlue so I cannot say more than I've seen in passing.
Google has taken up the implementation of WebRTC in Chrome very seriously as indicated by the frequent updates in the Canary and Beta channel of Chrome. Are there any other browsers who are upto implementing this?
Firefox/IE/Opera are working on it. No word from Apple/Safari or Microsoft/IE, although IE is unlikely at best, because they're working on their own standard unfortunately. Crazier things have happened, but I wouldn't count on it. Apple has been fairly mum on the subject.
If you want support for those other browsers, we built a solution for it # Frozen Mountain (I work there) using IceLink.
Opera Mobile does offer support to WebRTC. And according to this article, Mozilla isn't all that far behind either. Ericsson Labs has their own custom browser which supports WebRTC. But it runs only on Ubuntu as of now. WebRTC itself is still under development and I'm sure that we can see complete support from all major browsers in some time.
Mozilla is far along in implementing WebRTC, and we're leading the design and implementation of DataChannels within WebRTC, as well as Identity work. We're working on a project-specific repo right now (alder), but pieces have already moved over into mozilla-central, such as initial support for getUserMedia.
I would like to know what the members of this great community think of developing and adjusting their web apps and sites in general to recent Google Chrome beta browsers on Linux and Mac OS X and of course Google ChromeOS.
Do you think it's too early and I shouldn't waste my time adjusting myself to something that might change due to bugs resolutions?
Thank you.
Since Google Chrome uses Webkit you could also (as an alternative) test against Safari or Konqueror instead. Chances are your test results will be very portable across these browsers.
I think you answered your own question. While it is good to test against multiple browsers, there is very little point in testing against a beta browser - especially one with as little marketshare as Chrome.
With that said, the only reason I could see testing against a beta browser, is that you want your website to look good in it as soon as it is released and becomes mainstream. But, I really only see this need arising for the browsers that, again, are more popular.
Code against the standard, if you code it right the browsers will move toward you - rather than you constantly playing catchup.