I have set up an ASP.NET MVC5 video upload-conversion-watching site, and I need it to function on iPhone. The two formats I support are webm and flv;
I am NOT implementing .mp4 format due to the licensing requirements.
Is there an iPhone app, JavaScript library, or an extension that will allow the video to be played programmatically by my site, or an external iPhone application that can do it. The potential user base varies wildly in terms of technical experience, so any method will need to be relatively simple to follow. It would obviously be best if there were a way I could do it automatically, but I will take anything at this point.
Related
Many modern web applications have a mobile/tablet friendly version. There's a convention I've seen many times to have the address http://m.somedomain.com as the mobile version of the http://www.somedomain.com. However from a .NET perspective this implies that these are created as different projects which can create overhead in terms of testing, deployment and often hosting costs.
When is it advisable to use a separate project for your mobile site and when should a folder within your project be used?
I think that's a common solution for websites that doesn't support responsive design or we could say legacy pc websites, that's a common approach create a new website and do a "separate" web site for a mobile / tablet device.
Other reason could be that they may want to be mobileOK in this case the page is analized by several tests that may include HTML / CSS / and many other specifications for mobile devices, you can take a look to mobileOK checker by W3C I think that a responsive design isn't going to pass that test.
Aiming to feature phones instead smartphones you can tailor a very basic plain vanilla HTML/CSS website that could support older devices, remember that some old devices may not support javascript, CSS3 or HTML5
CONS:
you need to intercept the request at a web server level and do a
redirect depending on the user agent
Double effort on SEO you need to mark the mobile urls as cannonical to avoid a duplicated content
Double effort by measuring the traffic (mobile and desktop/laptop)
Double effort by developing and doing the maintenance of the website
All depends on what you need, if you have the chance to do a responsive design I'd suggest to follow that path.
It depends a lot on the design of the website.
Most web developers and designers are creating their websites using Responsive Web Design, which allows to show the same content of the website, on many different sizes, like phones, tablets, or desktops.
This is done through a CSS3 module called Media Query, and it haves to be implemented on the same project. This avoid the use of subdomains or different projects to show specific versions of the site. You can see a lot of examples on http://mediaqueri.es/.
In other side, if you can't implement Responsive Design to your site, you will have to create a new project, pointed from a subdomain (like http://m.somedomain.com), or called from a different route (like http://www.somedomain.com/m/). It is safe to have this new version on a folder within your project, and I would prefer this to reduce hosting costs.
I have a website that displays videos. It seems to work OK with 5 minute "webm" and "mp4" videos that are referenced by the HTML5 video tag. But if I ever use long videos, I'm worried that the website would be overwhelmed. The website uses ASP.net, and I did find an article on the topic of progressive download of large files with asp.net. However, I don't know if getting small packets of files interferes with the user doing a "seek" (e.g. dragging the control bar position to a point he is interested in, for instance). I also don't know if it would stream pages that don't need to be streamed.
Is there any way to solve the problem of too much video data being sent over the internet at once, and overwhelming either my server or the user's PC?
This should help you: Streaming MP4 video through .NET HTML5
Seeking and buffering is handled by the player itself, and yes when you seek to a new point in the video it will automatically just request those parts of the video.
There isn't a way to do adaptive streaming of HTML5 videos, but you shouldn't have to worry about seeking in long videos. Modern web servers allow browsers to request chunks of a file, so if a user is watching a very long video and skips right to the middle, the browser will stop downloading from the beginning and start retrieving the video file from the spot they skipped to. Contrast this with the early days of Flash video, when you have to wait for the whole beginning of a video file to download in sequence to get to the middle part you want to watch.
There are, however, a few things you can do to conserve bandwidth and keep your server happy.
First, if a user has started watching a video and is done with it, you can make sure the browser doesn't continue to download the rest of that large file. For example, this may happen if you're switching through multiple videos on a single page or if you're using a framework like Ember.js or Backbone to navigate through multiple "pages" without actually point your browser to a new URL.
If you pause a video and remove it from the DOM, the browser might still be downloading it. But you can stop that with code like this:
video.src = "";
video.load();
Also, consider storing your video files on a CDN. That way, the server that's running your ASP scripts, communicating with your database and handling other related logic is not also responsible for serving up those large files. There are other benefits as well, like having separate and more efficient headers and having servers in multiple locations that are geographically closer to your users.
HTML5 introduces the MediaStream API, which is meant to capture and stream video and audio data, primarily intented to get access to local media devices, e.g. a webcam. But using the MediaStream object concatenated with XHR you should be able to provide video streaming without further plugins. The browser support is not widspread right now and in not-up-to-date versions of Firefox and Chromium, you have to enable it via some sort of setting (e.g. about:flags in Chromium).
I don't know of any working implementation for streaming video from a server, I just played around with webcam data recently. I think that it is possible (somewhen even with broad browser support ;-). Be aware that HTML5 consists of many different API's most of which you would normally use via JS.
See also: http://www.html5rocks.com/en/tutorials/webrtc/basics/?redirect_from_locale=de#toc-mediastream
I'm looking for a simple mp3 control, my project is an ASP.NET web site (VS2008/C#), I've searched a lot but there was no luck, how can I give my users a small mp3 player control which enables them to pause/stop/change music? I want it to be usable in all major browsers, and of course no Silverlight as SL is still not widely supported, what are my options?
thanks
Without knowing more details here is my suggestion.
You can use one of the many open source flash players available. These players can play MP3's. Flash is installed by more than 90% of all browsers. You could also use a service like HulkShare that will allow you to upload your files then give you the HTML required to embed it into your site.
After getting pretty far along with a jQTouch web application for our website, my boss and I decided we may as well just make a true iPhone app instead of struggling with sloppy flickering animations and login authentication issues. We currently have a fully functional web site with some SOAP web services, but we are looking at rewriting these in order to make it easier for the iPhone to call the web methods (for displaying search results, categories, and article) for our app. I have not started anything on the iPhone yet as I am not sure which direction I should be taking.
For a developer that is somewhat unfamiliar with Objective-C (I understand the basics and the syntax), what tools do you recommend to create an iPhone app that uses data from ASP.NET web methods? If everything I need is provided in the iPhone SDK, where do I start?
If you are looking to use the SOAP methods from your ASP.NET site, then use Sudzc (http://sudzc.com/).
It will generate a package with all the Objective-C source code and classes written for you, to talk to your SOAP web services. You can drop it in your iPhone project and you're good to go.
You can tweak the generated code. Huge time saver :)
I am considering creating a website with the complexity of Facebook that should be able to scale into the millions of users. My question is: Is there any reason not to use Adobe Flex for such large project apart from the obvious point of requiring everyone to have Flash installed and not having to rely on Adobe? In my view Adobe Flex would reduce the server load for Facebook, because more of the work could me done on the client side. Do you agree?
Of course Facebook could have been implemented in Flash. But then the question is would it have succeeded? There are reasons big web companies like Google, Facebook and Yahoo only use Flash as sparingly as possible.
The thing I would fear most is alienating users. The Flash plugin isn't the best piece of software out there. It is slow and likely to crash once in a while. If your app gets bigger you might get some loading times that might not be acceptable to your users. Also in my opinion full Flash sites just don't feel right because they behave differently from HTML websites. All great websites like Google, Flickr, Stackoverflow or Facebook feel very light and slick which is very elegant makes up for great usability.
And then HTML and JavaScript are a lot more flexible. Do you want your website to be available on smartphonse? The iPhone has no Flash and even with phones that do you have the problem that users will very likely hate a full Flash site since those phones don't necessarily scale Flash as nicely as they scale HTML and Flash draws battery like crazy. If someone comes up with another revolution like smartphones you can be sure it supports HTML and JavaScript but you can't be so sure about Flash.
Then the question is how would you gain any efficiency? Of course you can write your UI with Flex and just call very lightweight webservices like you would use them for AJAX and you can even cache some of the content of the site locally so that you don't transmit more data as necessary for user interaction (the UI is transmitted only once). But you can also do that with JavaScript. You can write your UI in HTML and JavaScript, load it once and then just pull the naked JSON data from the servers and render it using JavaScript. You can also fetch lots of this data in advance to get the number of requests down. But still such an approach has its cons. Did you ever notice that when you type an answer on stackoverflow and someone else submits an answer you get notified while typing your answer. Such real time features are very cool and you might want this at some point in time which means more server interaction.
But whatever you do your servers still have to scale if your site grows. Even if you minimize the number of GET requests that hit your servers they will still grow a lot when your site gets popular and you will need a lot of servers to handle you will just improve your users/servers ratio.
The most interesting point though is that Flex is much easier to program than AJAX (think about browser incompatibilities for instance) and still AJAX was not only invented but the whole world messes with all those problems that come with it instead of using Flex. I think this tells a lot about of the value of the result you get when creating a full website in Flash.
Go to facebook and do view source...do you see all that JavaScript? That all runs client side
Johannes is right to point out the difference for server vs. client. The server side stuff is what needs to scale.
As an example, the Microsoft Silverlight team has assembled a facebook client app in silverlight (using the Facebook public API). My point is, using todays technologies, it is entirely possible to write a web application targeting many different kinds of client technologies: classic web browsers (HTML/javascript), 'rich internet applications' (flex, silverlight), ...
See also the myriad of Twitter clients out there.
The company I work for has a large app in Flash that is used by Governments. It is very hard to maintain and does fail sometimes. The problem is all of the .fla and .as files that have to be altered just to make a small change. Yes, the app could have been built better but even so, it is still harder to maintain than an HTML/JavaScript front end.
While I love writing Flash/Flex apps, I believe they should complement a site and not be the site.
Using a good JavaScript framework like jQuery takes the Browser compatibility question out of the picture (for the most part) and allows a lot of functionality.
Flex is the GUI for the client. You still need server-side storage and that's what has to scale. The user interface could be in Flex, while most of your users won't like such interfaces.
You will have to do a custom version of your site for the iPad/iPhone.
There are other ways of moving load to the client side. Javascript will give you porting headaches, but less than moving away from the entire architecture like Flex.
OTOH when you get a million users you'll have the resources to reimplement your site.
I don't think you would see a performance advantage with a site like Facebook, because the content is highly dynamic, comes from many different places, and is created by many independent entities. Flash (and therefore Flex) is better for monolithic apps from a single source that don't need to change very often.
The default in Flash is to build everything into a single .swf file that holds everything. It is possible to break out of this default behavior, of course. You can make web service calls, pull in external components via the SWC mechanism, load static content via HTTP, etc. Nevertheless, it's not the default pattern, which affects how Flash development libraries and tools work. Besides, the more of this you do, the less of the "run everything we possibly can on the client side" benefit you get. It gets soaked up in HTTP connection overhead.
The default on the plain old standards-based web is to store all assets separately and assemble them dynamically at the client. This is one reason the web is slow -- again, all that HTTP connection overhead -- but also why it is flexible and dynamic. It mates well with a site like Facebook which requires constant evolution by a lot of independent developers.
I say this having developed a Flex app, which I am happy with. Only one person -- me -- has to maintain it, and it's naturally a monolithic app. It plays right into Flex's strengths.