Considering the simple-graphic turn-based games such as card games, backgammon, ... we can see most of them are still developed using Flash or other plugin-based solutions instead of pure JavaScript (Ajax/WebSocket).
I want to know what is the reason? Is the connectivity between a flash game and the server more reliable than the connectivity between JavaScript API (Ajax/WebSocket) and the server?
If no, why is the reason that still most of the card games (let say those we can see on Facebook) are developed using Flash?
The target audience of Facebook-games is very wide, from people with the latest and greatest technology to people who are still using Windows XP with IE8.
As you will almost definitely know, IE8 does not support newer technologies such as websockets/HTML5. It is even troublesome in IE9. Thus, the developers of the Facebook games build their games in Flash as that is a technology which will run in both older versions of IE and in the latest versions of Google Chrome. They can target a much bigger audience using Flash as when they were using HTML5.
Related
I am experiencing a unique issue where a user on Safari would automatically lose its voice after 5-10 mins.
I am using Agora SDK NG and see that it is 1 of known safari bugs (https://docs.agora.io/en/faq/browser_support#safari).
However, this is not rare and keep occurring consistently. This doesn't ever happen for chrome users.
Is it something missing in Safari or limitation by Agora?
If it is webrtc's limitation on safari then would other platforms like Jitsi should also have the same issue
Agora's Web SDK (current and NG) are based on WebRTC and leverage browsers' support for WebRTC in order to function without needing any specialized plugins.
While Safari does support WebRTC functionality, it offers minimal feature support when compared to Chrome and Firefox browsers. If you are seeing different behavior in Safari as compared to Chrome/Firefox when using the same code, then it's most likely caused by a limitation within Safari with respect to WebRTC support.
Recently I have worked using WebRTC and I'm wondering if it would make more sense to implement a Real Time Communication open standard at a native level.
Let's say that instead of a web browser API we have a native API that any native app, including the browser can leverage.
Part of the promise of WebRTC is to have RTC on the browser without plugins but why stop there, why not have RTC on any device with media capabilities without plugins. There are many devices with media capabilities that will not run a web browser, e.g., wearables. It seems to me that the browser itself has become the plugin and I think we need to get rid of it as far as RTC is concerned.
It sounds like OpenWebRTC is going in a similar direction but so far they are only working inside the browser.
Are there open standards for native RTC? So far it looks like RTCWeb is only concerned about the browser.
Are there any projects/initiatives for native implementations of an open standard for RTC?
webrtc definition. webrtc is stuck into two parts, complementary but separated. the W3C consortium is standardizing a JS API for browsers named webRTC. The IETF is standardizing the underlying protocols and what happen on the wire for interoperability, it is named rtcweb.
the IETF's rtcweb group defines everything you need to interoperate with a browser, without being a browser yourself, i.e. for gateways, devices, .... It has been made explicit at the latest meeting in hawaii last november, and there is for example a corresponding draft.
On the client side, the implementation of webRTC JS API is done on top of c/C++ implementations. Those "native" (as in non-browser, C/C++) APIs can be use directly for servers, embeddable devices, gateway, ect, or can also be wrapped in different languages (obj-c, java) to provide "native" (as in mobile native) APIs.
Note that BOTH openWebrtc.io and webrtc.org have a full implementation of webRTC in C/C++ that you can use. openWebrtc provides iOS wrappers, and webkit wrappers (for safari), but do not provide data channel support, ORTC API support, nor compile under windows. webrtc.org supports all desktop OSes, and provide wrappers for both iOS and Android. The build tools are specific to google's chrome though, unlike openWebRTC which uses standard auto tools, github, ...
HTH
Currently there is no effort in this direction. The guys in the webrtc standardization committee have their hands full standardizing just the javascript API. As you know the current spec is not final and is currently still worked on. And now ORTC will generate even more work.
There are many reasons why no one is currently trying to standardize any form of native RTC. Here are some that come to my mind:
What exactly is native? Javascript is native for the browsers. The chrome version of webrtc is in C++ but the OpnWebRTC one is in C. Android developers use mostedly Java, iOS developers use ObjectiveC. Should there be standards for all these languages? That's going to take forever.
As I said standardization committee already have their hands full.
There is still quite a lot of experimentation that goes on with WebRTC. Standardization may prevent this.
The API of the native libraries tend to be very similar to the JS API.
at first i thought with Titanium, i can develop for Mobile and Desktop over AIR on Desktop only, but a quick look at the AIR Site, i guess i am wrong.
Benefit from a consistent, flexible,
and visual development environment for
applications on multiple platforms and
devices such as smartphones,
smartbooks, tablets, netbooks, and
PCs.
so my question is are there any major differences of titanium over air that i shld be aware of?
if no, i guess now air maybe better documented and has the backing of a more recognized company? after working with titanium desktop for a while i felt abit helpless and the docs are not really helping much
There are a lot of subtle differences, of course, and there are advantages and disadvantages to working in either, but the largest difference is that Titanium can produce apps for the iPhone/iPad, and AIR can't (well, at least not conveniently).
AIR can produce iPhone apps that you can deploy using the ad-hoc provisioning, but you can't distribute via the app store.
I've got desktop apps on both and am making a mobile app right now. Titanium desktop will cut your dev time to 1/3 of the time you'll take jumping through AIRs various sandboxes and security measures. Best yet, the code I wrote for my Ti desktop app is all javascript with about 3 Ti API calls and can be taken anywhere. The AIR app is all mangled by the wild structure you have to use with AIR apps and 1 million api calls.
The downside to Ti desktop is the API isn't as fully featured, and the Ti team pushes 4 times as many updates for the mobile API as the desktop API. Also, you won't be able to port your app from desktop to mobile easily as they are two different structures and APIs.
That said, developing for iPhone and Android on Ti is the same exact process and that won't happen on AIR.
Lots to weigh, but for my money it's Ti over AIR.
Hope this helps.
I'm curious what "features" are in Adobe AIR that makes it unique from browsers. I've heard that it has SQLlite on board, but what else makes it any different from Chrome's application mode (get the same functionality using Firefox's Prism plugin)
Is it fair to call it a browser?
AIR is technically a runtime much like Prism, and Silverlight (dunno about Chrome) for RIAs. They try to bridge the gap between the desktop applications and the browser. Browsers typically do not have disk access.
I'd suggest you go through this link.
Adobe Air is sort of like having a web application run on your desktop as if it was a windows/mac application. It is the answer from Adobe to Microsoft Silverlight out of browser experience. There are some technical differences; for one you need to install a seperate piece of software before you can use it while the Silverlight one comes with the Silverlight runtime. Another difference is applications running on Adobe Air have much higher permissions on your system than Silverlight ones.
Is anyone out there aware of any good or even reasonable tools for automated testing on the Windows CE / mobile platforms. Potential tools that I am aware of include TestQuest, Countdown, SOTI pocket controller, and Eggplant. Are there any more that I have missed?
Alternatively, is anyone aware of a VNC or remote display tool for Windows mobile that replicates the Windows visual object hierarchy on the PC, rather than displaying the entire device as a single bitmap? If this could be done, mainstream desktop automation tools could be applied to Windows mobile.
N.B. I have already read this related question which is useful, but am looking for a viable off the shelf alternative. This post is following up on a number of related posts in the PDA/Embedded section of SQAforums.
I realize that your question is directly "are there tools to do the automated testing on CE", but have you considered perhaps aiming your automation at a version of the app which can be accessed from a standard desktop environment? In this way, you are open to all of the standard automation tools.
For example, I have worked on a few projects where we needed to perform automated testing for the device. In all cases, the RF device was really just a web browser connecting to a web based app. The same URL and simple forms could be plugged into a standard desktop browser and be automated by any of the usual automation toolsets. Automation never replaces manual testing, so what we did on those projects was automate regression testing of the same web interface that was used by the RF devices, but still do some sanity manual testing directly on the devices.
Also, with regards to the VNC/bitmap issue, I've been down that road before and agree that it is a nightmare. Using standard desktop UI automation on a VNC bitmap is not only unreliable and unmaintainable, but slow - in most tools, the CPU churns away searching the entire bitmap from top left to bottom right for the desired image. Really really slow.
Check Hopper, a test tool for Windows Mobile.