I'm working on a Flash based networked game. I have to choose between ActionScript sockets and WebSockets (or more specifically socket.io). I'm wondering which is the better choice. I'm leaning toward ActionScript sockets since it (should) will be standard across all browsers. With socket.io, WebSockets can only be used in HTML5 and it can even result to polling for some older browsers which is a big issue.
Would you guys say that ActionScript sockets is the better choice?
Thank you very much!
The world is moving towards WebSockets (and HTML5, in general).
Flash is becoming more challenging than ever, given that many tablets, smartphones (and even IE10 in Metro style) don't support plugins. Adobe announced that they will stop developing Flash for mobile browsers. Flash may be OK for the purposes of your application, but it's pretty clear that at this point HTML5 is way more "future proof" than Flash.
As for the browser support for HTML5 and specifically WebSockets: some of the WebSocket servers provide very clever emulation techniques that on one hand allow the developer to code against the WebSocket APIs, on the other hand automatically select the best transport layer under the given circumstances (browser, platform, proxies, routers, and other intermediaries). For example, the Kaazing WebSocket Gateway [disclosure: I work for Kaazing] does emulation exceptionally well (check out this blog post if interested in WebSocket emulation using older browsers, including IE6).
And one more thing: if Flash is a technology you're familiar with and need to use for development, Kaazing has WebSocket APIs for Flash, Flex, Air (as well as Java, .Net, and obviously JavaScript) as well.
Overall, I'd definitely go the WebSockets route today.
Related
WebRTC requires too much processing power on server so doing it massively will be cost-prohibitive.
For nearly all other platforms - both for Windows and Mac - Chrome, Safari desktop, even IE and Edge, and Android - there is a Media Source Extensions API (https://en.wikipedia.org/wiki/Media_Source_Extensions) which allows sending stream over websockets and play it, it works. Problem is just with iOS.
Is there anything better (lower latency) than HLS which would work for me?
If not, is there a WebRTC server which is free and better scalable/more stable than Kurento Media Server (https://github.com/Kurento/kurento-media-server)?
There is a jsmpeg player http://jsmpeg.com/ but it is MPEG-1 only so will require unacceptable amount of bandwidth. There is broadway.js but it does not support audio...
Is there anything better (lower latency) than HLS which would work for me?
HTTP Progressive is a fine technology for this. It can be ran at much lower latencies than a segmented technology like DASH or HLS, and requires very little in terms of server-side resources. Look into Icecast for your server, and FFmpeg as your source.
There's no point in sending video over Web Sockets, unless you're implementing a bi-directional protocol. This isn't uncommon for ABR support, but it's definitely not the most efficient or simple way to do it.
Since you don't want to implement webRTC by yourself and need lower latency than HLS, I would prefer a media server. There are many media servers available in the market. But if you are looking for free and open source media server, your options are limited to few.
I would suggest red5 media server which is free and open source. Please check this link to find more about red5. If you use free red 5 media server you need little knowledge of java. Red5 also has a paid version called red5 pro which has better webRTC support and higher capabilities. Red5 is mostly for rtmp with flash player pulgin and its fairly new for red 5 webRTC streaming.
Also you can use wowza streaming engine trail version with limited number of connections. So these are the easiest options for you.
For developing a video content heavy website like youtube which language/framework might be a better option from performance and support for video conversion/compression plugins point of view. Some points worth considering may be.
CPU vs I/O time
Support for compression/conversion plugin (existing mods/gems/libs)
Ease of learning is not very important though inputs are welcome
I know the question sounds a bit subjective however my intention is to understand the technicalities involved from someone who has had experience developing similar kind of site(s).
Unfortunately there isn't one or two APIs/Libraries/Frameworks you can knit together to produce a video serving website.
Invariably this will require heavy involvement on all levels of the stack:
Server back-end will require the following problems to be solved:
Video Encoding
FFMPEG or MPlayer experience for encoding any number of video formats to either FLV or more recent h264 for HTML5 supported formats
A reliable mechanism to transcode video in a background process; initially on one server but eventually on multiple servers as your services scales
Video resizing
Bandwidth Management to throttle connection just enough so that the video trickles down to the user
Storing video files and a file sharding and naming mechanism
API Server - Something like Rails, Django or NodeJS Express to serve as a JSON service layer between web clients and the video encoding/serving service.
Front end will require the following issues to be solved:
Playing back the video reliably across multiple OSes (Windows, OSX, Linux, Tablets, Mobile) and Platforms (IE, Chrome/Safari, Firefox, Opera) with fallback support for older browsers
DRM - are your videos free or commercial? If the latter, this is another issue that needs to be addressed
I'd strongly recommend an Event Driven system on your back-end as it is much easier to develop code that supports concurrency. NodeJS would be a good pick. It is worth looking at node-fluent-ffmpeg module for NodeJS as a good starting point.
As for your front-end I'd recommend frameworks such as Backbone.js or AngularJS to develop you web-app.
It was a fun and challenging journey when I attempted something similar a few years ago. I wish you good fortune in your journey.
For a site like that, I guess will need to choose several tools to do the job.
For the web, you could use any framework, so rails would be OK, to deal with videos you'll need something like ffmpeg or transconding to convert the videos.
For streaming, if you can use HTML5 check this question otherwise you'll need a player whith flash fallback.
Remember that the heavy part in terms of storage and CPU is video compressing/conversion.
Can you advice something in building a Rails app that would nicely communicate with Flex via sockets. Currently I found only two ways of communication: Simple HttpRequest, RemoteObject. But I need something "multiplayer" style. I need Flex to talk to sockets and Rails app to grab data from those sockets do some job and push something back to a socket so Flex could read it "on the fly".
Any poor design flow? :) Thx in advance.
Depends on what exactly you need it to do and how responsive you need it. You can look into the Ruby AMF plugin which is a native type for Flash, which makes transferring classes a breeze. The Java implementation has a streaming server built in, not sure if the Ruby version does.
Other than that, if you want it to be really responsive, you could 2 different approaches: an RTMP server (SmartFoxServer, Wowza, Red5, LCDS, etc - all Java based) or you could try to do p2p (Adobe calls it Cirrus - and it's still in pre-production). If you do use the p2p route, you still need a fallback in case something goes funky.
This is kind of a dumb question but I've aware of classic style JDE development for Blackberry but I've never tried using WebWorks. BB website says that it's possible to build applications for both smartphones (OS 6.0+) and tablets - sounds fantastic, but what's the price?
Is here anyone using WebWorks on a daily basis and capable of describing pros and cons?
Thanks in advance
I would suggest using it if you build webOS applications before hand. It make porting to the blackberry a breeze.
Use WebWorks if you know html5, Css3 and javascript over Java and C++.
I haven't ran into any issues with the webWorks, ported two applications without running into any issues. Its your standard html5, css3 and javascript you love with blackberry APIs
WebWorks is a good development choice, particularly as it allows easy migration from earlier BB OSes to BB10. It's mostly standard web technologies (HTML5, CSS3, etc.) and the team seems focused on making it perform well (e.g. hardware accelerated WebGL graphics) while at the same time providing BlackBerry-specific APIs to make WebWork apps capable and with good UX (e.g. you can make it look like a native app).
For native apps, you should look into Cascades. This is a modern development environment with good tooling, accelerated graphics, and APIs for building snazzy apps. It's the one that will most be a "BlackBerry app".
AIR remains an option, but I would recommend WebWorks over AIR, as even Adobe is migrating from Flash to web technologies. Likewise, you can develop Android apps on BB10, but unless you are keen on Java programming, you will get more cross-platform support from WebWorks (or even AIR) so there's no particular reason to go the Android route.
WebWorks API is limited, for example it does not have socket, so you cannot port a VNC (UltaVNC, tightVNC ..) to it but you can do it with JDE.
For UI, WebWorks allowed me to write UI of acceptable quality quickly and easily, a thing that I have never succeeded with JDE.
Still on the UI side, I can make use of multi-touch (PlayBook), I don't think this one is possible with JDE.
So depending on your needs you should go either WebWorks or Native, having heard that Java may not be supported in BB10, and Air may not be future proof (Adobe favors HTML5 instead of Flash). Android appli has some lag on start up when it is run on PlayBook, some customers are sensitive to the initial even just one time slow response time.
I'm a huge proponent of Webworks. Ever since I've started using it, it quickly became the default option for my apps going forward. Especially for someone like me who is just writing a few apps on the side, I don't have the time to do it in c++.
The apps I'm writing revolve around home automation. They are client/server based from the get go.
Here's why I like it:
First and foremost, native API support. I can very easily create my own active frames, import invocation from other apps (think camera, stuff like that). I can export portions of my webworks app as an invocation card! Which means I can write say 3 unique apps (in this case home automation, lights, thermostat, security cameras). And I can very easily pull features from each app into the other. Maybe I want to turn my lights on in the living room, I can also import the camera card from my IPcam app and view the results, without having to add that code into my lights app and maintain two separate code lines.
Rapid design. Since I've been dabbling in html since I was a kid, it's now very easy for me to whip up an appealing UI in little time. Because web engines these days offer good performance in terms of graphics capability, I also can make apps that behave very fluid.
Considering the time to make something beautiful, it's hard for me to leave webworks and go for something in c++. Also the big plus is often these apps I'm making are intended for multiple devices, namely an app on my phone and being hosted on my personal website. By maintaining two slightly different css files, most of the time I need no code changes, just load a different css depending on if it's a phone or a pc. (Exactly what you'd do if you were developing a regular old website).
For that matter, I actually don't put my code on the device, I host all of my html and javascript, images etc on my server. The webworks app is just the config.xml pointing it's source to my server, and an icon. A glorified website bookmark on the homescreen, only difference is I can use native API and there's no browser bar in the app.
Also, this way I can still continue to edit the same single codeline on my server, and instantly apply changes to the in-browser app and the on-device app.
This is especially cool if you're designing an app where all of it's data is out in the "cloud", say you work for a publication and you want to write a magazine app which pulls content from your servers on the net.
I'd like my Blackberry devices to get and possibly set data to the server, and am a little confused by all the options:
RIM-Push/Pap-Push. Use any library that is able to compose a HTTP GET request to the MDS-CS service (not MDS-IS). This is a one way operation from the server to the device.
RIM-Push (Push a URL and or shorcut to a device for possible offline viewing)
PAP-Push (Same as above, BUT allows for message confirmation of delivery)
WebServices: Use Visual Studio 2008 to create a Web Services only project. I'm unclear if this is supported anymore, or if MDS-IS is used. This is a 2 way operation.
MDS-IS: Use Eclipse to develop the applications and Java is required, I am unsure of what client libraries are able to do (2 way operation).
Let me know if missing any option, or if I need to revise my understanding of the basics
This is actually quite a broad question - there are a lot of ways for a BlackBerry device to interact with a server, and the ideal way depends heavily on your specific application.
Generally:
MDS Studio: the Visual Studio 2008 method is no longer actively supported. It was a mostly visual forms designer, but not a great solution for a lot of reasons. Basically, don't use it.
Mobile Web: Depending on what you need to do, this might work. Everything server side. The thing to be aware of (and why this doesn't work for a lot of problems) is that prior to BlackBerry 6 the browser wasn't very capable, either in terms of HTML support or JavaScript support. You can, however, create shortcuts to mobile web sites which appear as icons on the BlackBerry homescreen. And you can use BlackBerry Web Signals: http://na.blackberry.com/eng/developers/browserdev/websignals.jsp to push changes to mobile web pages to devices
Widgets: Supported in BlackBerry OS 5 and higher. http://na.blackberry.com/eng/developers/browserdev/widgetsdk.jsp These are packaged much like 'native' BlackBerry apps, but written using HTML and JavaScript. Can be a good option for rapid development if you're ok with just targeting OS 5, and with the limitations of the BlackBerry Browser. Lots of JavaScript hooks to system functions, so they give you more functionality than pure mobile web, and you can distribute them through App World and the like.
Java Apps: Most development work, but you get potentially the best user experience, and the most functionality. Too broad a topic to cover adequately here, but there are a lot of questions related to these on SO and elsewhere. A good starting point is the BlackBerry developer zone: http://www.blackberry.com/developers RIM Push and PAP Push both fall into this category, as they interact with Java apps, though there are other methods that you can use to achieve similar results (client polling, or I've even seen SMS or email used to push info or wake up a client, though this isn't recommended by RIM).
For a deeper overview of the options I'd recommend a book by my friend John Wargo, called BlackBerry Development Fundamentals. He covers the various options pretty well.