Although I don't have an iPhone to test this out, my colleague told me that embedded
media files such as the one in the snippet below, only works when the iphone is connected over the
WLAN connection or 3G, and does not work when connecting via GPRS.
<html><body>
<object data="http://joliclic.free.fr/html/object-tag/en/data/test.mp3" type="audio/mpeg">
<p>alternate text</p>
</object>
</body></html>
Is there an example URL with a media file, that will play in an iPhone browser
when the iphone connects using GPRS (not 3G)?
The iPhone YouTube application automatically downloads lower quality video when connected via EDGE than when connected via Wi-Fi, because the network is much slower. That fact leads me to believe Apple would make the design decision to not bother downloading an MP3 over EDGE. The browser has no way to know in advance if the bit rate is low enough, and chances are, it won't be. So rather than frustrate the users with a sound file that takes too long to play (and prevents thems from receiving a call while downloading), it's better to spare them the grief and encourage them to find a Wi-Fi hotspot.
Try something like this, it works on a web page. This is actually a 320kps mp3 but it is only 30 seconds long. You can use a program called LAME to convert mp3's to a bitrate you
that will work for you.
<div class="music">
<p>Pachelbel's Canon</p>
<!--[if !IE]>-->
<object id="Cannon" type="audio/mpeg" data="http://calgarydj.ca/sound%20files/Pachebels%20Cannon.mp3" width="250" height="16">
<param name="autoplay" value="false" />
<param name="src" value="http://calgarydj.ca/sound%20files/Pachebels%20Cannon.mp3" />
<!--<![endif]-->
<object id="Cannon" classid="CLSID:6BF52A52-394A-11d3-B153-00C04F79FAA6" width="250" height="60">
<param name="autostart" value="false" />
<param name="url" value="http://calgarydj.ca/sound%20files/Pachebels%20Cannon.mp3" />
<param name="showcontrols" value="true" />
<param name="volume" value="100" />
<!--[if !IE]>--></object><!--<![endif]-->
</object>
</div><!-- end of control -->
I wasn't aware of that limitation. Although it does make sense to disable potentially data-hefty OBJECT or EMBED tags when on the cellular data service for which your provider may be charging by the byte, if that were the reason it wouldn't make sense that it would still work on 3G and only not on GPRS.
Perhaps the problem is one of basic data throughput? Not having an iPhone yourself (or myself) makes it difficult to test your colleague's statement.
Remember that GPRS is much slower than Wi-Fi or 3G. According to Wikipedia, GPRS will provide between 56 and 114 kbps of total duplex throughput, not all of which is in the download direction. You can already see that's not fast enough to instantly stream a typical 128 kbps mp3, even if you were getting the optimal throughput and getting it all as download speed.
Looking at this forum discussion as an example that came up on Google, the GPRS customers (the ones not using Telestra, which is an EDGE provider in that area) are getting around 40 kbps. So if as the question implies, you're stuck in EDGEland, NOT 3Gland or anything inbetween, it's going to take about 20 seconds of buffering to play a 30 second mp3. And when you use a behaviour-ambiguous tag like OBJECT or EMBED, there's no guarantee in how the browser will interpret it and whether it's going to try to intelligently stream the file rather than having to download the whole thing before starting it.
So, it's quite possible your colleague just didn't wait long enough to see if whatever embedded media he chose as a test started to play (assuming he wasn't using your 17KB test mp3 there). It's also possible that the iPhone does indeed have this limitation, though I'd think Google would be more forthcoming with it than my quick search uncovered, since people have been vocal enough with other things they don't like about iPhone. Another possibility would be that it's a limitation in the build of Safari that currently ships with the iPhone which might be changed in future versions or in another browser.
Ultimately though, the question is, what kind of user experience do you really want? Embedded audio on GPRS is going to take a long time to load, and users aren't going to enjoy the experience, or potentially even experience it at all if it's supposed to start playing on page visit and it doesn't load before they navigate away. It might not be a goal worth striving towards in that case.
Related
My boss has asked me to create the technical requirements for a design consultancy who are going to be tasked with creating a demo of our website.
To be honest I don't any more about Flash than your typical Youtube user, so I'm floundering a bit!
The website to be demo'd is is designed to run at a minimum res of 1024x768. We'd like to be able to show it on any device, but I suspect text would be unreadable on any mobile devices, so they're probably out of the equation...(?)
So far, I've got these requirements, but I suspect some of them are redundant, or too open to make any odds... do you have any suggestions?
FLV file
Player version:
Adobe Flash Player v6+
Adobe Flash Lite v3+
Browser compliance:
IE6,7,8
Firefox 3,4
Chrome, Safari, Opera latest versions
OS compliance:
Windows 2000, XP, Vista, Win7
Mac OS X
Linux (?)
Mobile:
?
Web compliance:
(our wesbite is
!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd")
Security
Flash cookies: no
Any help would be much appreciated!
Flash V6 is really a tough requirement. It's 8 years old!
IE6 is also quite hard to meet without (useless) additional development costs.
If you want to exclude mobile devices, you should also exclude FlashLite and ask for a more recent version of Flash.
In general, if you have no reason for sticking to one version, don't stick to it.
Flash 10, IE7, FF3, Chrome, Safari, Opera.
OS requirement is useless since it doesn't change anything to the browsing interpretation and experience.
Web compliance is a matter you want to consider for Search Engine Optimization, accessibility, compatibility...
For the flash version, you're safe targetting FP10, and you could even bump for 10.1: http://www.adobe.com/products/player_census/flashplayer/version_penetration.html
I'd specify AS3, as any design company still using AS2 for their flash needs as so far behind the curve that I wouldn't have confidence in their abilities.
Ignore browser compliance: it's flash, it just works.
Ignore OS compliance: it's flash, it just works (At the very least they should test it though).
Mobile: For the most part, if the phone supports flash, you should be fine. Where this is important though is optimisation (small file size for SWF and assets, good memory management, good speed, throttling the frame rate when it's not needed...). Depending on your site and what you do, take care with video etc. Basically, anything you see on Flash Site of the Day (http://www.thefwa.com/) is probably going to brick your phone, so it's really how important this is to you.
Web compliance: if you want your site to be indexable by Google etc, it takes extra work
Accessibility: if you want your site to be usable by special needs users (screen readers, keyboard-only navigation etc), it takes extra work.
Security flash cookies: not sure what you mean by this, but cookies are standard and probably done at a browser level rather than flash level (unless you're using shared objects for storing settings etc). In any case, it's not really a problem
Depending on how much flash is in the site (i.e. if it's a full flash site, or a html site with flash elements) these points become stronger or weaker - if you're including html in the bargain then you've different elements to look for. For the most part, the company should know all this stuff if they're any good.
Depending on how much content you have in your site, it may need an internal search (takes more work), or work with internal pages (i.e. it's possible to go to mysite.com/shop/item#blah and not be only able to go to mysite.com and have to manually navigate to the page every time)
A final point I'd put in is to make sure it's actually useful. Full flash sites that are just flashgasm intros and 20 minute long transitions betweens pages etc really suck. Hard. It might look cool but you'll hurt your business as for most people your site is useful if it's convenient.
My web site has a different mobile version that's suited for iPhone/Android devices. The problem, however, seems to be in the site's performance. It's really slow and heavy, even though I'm not loading any images.
On the other hand, when I use Gmail's or YouTube's mobile version, they're so fast they almost perform like a native mobile application.
How do they do that?
Your help is much appreciated :)
See my comment. Also, if the slowness you perceive is when interacting with the site it could be that it lacks the ability to accept touch events. On mobile web, if you have not wired up the UI for js touch events the experience will seem slower because the device browser has to fall back to standard click and other mouseevents which are not optimal. Frameworks such as mootools and jquerymobile/jqtouch have these events baked in. Take a look at the mootools solution which has quite a good write up: http://davidwalsh.name/mootools-touch
They probably making use of local storage http://dev.w3.org/html5/webstorage/
Are your pages too large? Try to use gzip and/or reduce output
Your server's connection speed may also be responsible of slowness
Well, You don't need to include any javascript framework to make it fast clickable.
By implementing some JavaScript you can achieve that. Google has released a solution for that
https://developers.google.com/mobile/articles/fast_buttons
This will allow visitor to interact with application native way. From Android 4 (as far as I remember) version by setting viewport meta tag the browser will automatically apply the fast click functionality.
For the animation issue always use Hardware accelerated animation with a fall back for older mobile browser. Using hardware accelerated animation it will make your application smooth as silk.
Follow this guideline and you can make your application as fast as gmail / youtube mobile version.
http://www.html5rocks.com/en/tutorials/speed/html5/
Best of luck.
Your webapp is consuming too much RAM. Don't use so many libraries and don't attach so many event handlers.
Does apple support mirroring of ipad on tv can any one give me some idea
Read this article:
There’s been a lot of confusion about how the iPad VGA Adapter works. I received mine today, and I thought I’d try to clear things up a little (and give you some code to play with, if you’re an iPad developer with a VGA adapter of your own).
The first thing to understand is that the adapter does not mirror your iPad screen. You can’t plug your iPad into your TV or monitor and see all your apps on the big screen, like Steve Jobs does when he’s giving a demo.
Apps that want to support external display via the adapter must explicitly do so; the developer has to write code to support it. There are some standard iPhone OS-supplied APIs which will automatically do the right thing (such as video playback via standard controllers), but generally you won’t see anything on your external display unless the app you’re using has taken steps to put something there. That’s the “bad” (though surely not surprising) news.
The good news is that it’s trivially easy to support external display from your app if you’re a developer; the connected display just shows up as another UIScreen object. I made a sample project (which you can download as a zip archive here) that shows how to do it.
It’s basically just a nib with two windows (one for showing on the iPad, and one for showing on the connected external display), and a tiny bit of code to make it work.
My wish is to know how I can program a mobile website, that fit to all mobile phones.
Are there any special approaches to recognize a device and render the code according to it?
Which tools and coding languages are required?
My first thought was to hold the website in XML, which would be parsed depending on the device.
You have to consider old phones, even devices with only wap support.
For example: The mobile website has to recognize Nokia N75 and render/send the code that looks optimal for this device. Same thing with an iPhone or a Motorola Razr.
There are all sorts of problems associated with developing mobile websites. Doing it well takes a lot of time and effort, as phones have such varying support of web standards. There are tools that do it for you, such as the Mobile Web Toolkit and Vodafone's PartnerMl. These tend to force you to write your pages using dedicated XML tags which describe a limited set of elements and styles that can be rendered on the page. The phone requests these xml pages, and the server side software intercepts the request, examines the type of phone (the User Agent), and serves back markup appropriate to that phone. The disadvantage of this system is that it is very inflexible; you are limited to the set of XML elements that the tool supplies, rather than the full flexibility of HTML.
If you want to do it yourself, essentially, you have to do the following.
Using server-side code, examine the User Agent in the Http Header. This tells you what kind of phone/browser made the request
Output appropriate markup and CSS for that user agent.
Useful tools are the User Agent Switcher add-in for Firefox. Using this, you can, for instance, visit the BBC's website, pretending to be various devices. You will see that the BBC outputs 3 or 4 versions of its markup, as well as 3 or 4 different versions of the CSS, depending on the user agent.
mobiForge contains useful information. WURFL and DeviceAtlas are databases that allow you to determine the capabilities of the device that has made the request.
You will quickly realise that you will have to keep your design simple, and it's best not to rely on Javascript, as only the most modern phones can handle it well.
XML is the way to go.
From there, you mosey on to parsing out and acting upon the Agent tags in the request.
From there you can choose (assuming the device supports it), having the device render it via XSLT, or you can apply the XSLT on your end and stream down the appropriate markup language for the device.
In the end, you end up with a specific "rendering" per device. Ideally, the more compatible the devices are with normal browsers, the close the final XSLT is to each other. But you'll still likely have a version for each device that you support.
The beauty of this is that you can add devices incrementally, as time and demand permits. And as devices converge, you gain value by being able to converge your renderings. Also, your back end stays the same no matter what.
Finally, it also works great for non-mobile as well.
Yea, it's a burden to support the different devices, but that's just a truth of the marketplace.
One way is to use strict html with very clear semantics and minimum of css tricking. Do only use relative measures (for example em and %). Trust the browsers default values, because they are in one way optimal for every device, more or less.
Nowadays there isn't exist good tools to do this.
A good practice is to respect the different W3C standards about the accessibility (like the WCAG, the XHTML, etc).
If you made your web site the most accessible as possible it'll be more adaptable. (independently from device, screen size, with or without screen touch...)
If you want more information you can read one of my article about the web accessibility here if you want: Guideline to move a website on a mobile device.
However you can use some meta tags to allow the web browser of the phone to adjust the content like this for the iPhone:
<meta name="viewport" content="width=device-width">
You might wanna check out WURFL
Our lovely app that downloads mp3s from our server into a local file on the phone then plays from that file was rejected for using too much bandwidth.
I understand the rejection (we are downloading rather than streaming) and don't quibble with their decision... our first priority was quality of user experience.
I am just wondering... what do I do now?
There are no hard and fast rules... Apple just says, "Must not in Apple's reasonable judgment excessively use or unduly burden network capacity or bandwidth".
Anyone have data on what Apple considers reasonable data transfer rates?
Should I fill up the buffer file in short spurts? Should stream the file at a constant rate (and how would I limit the transfer rate from within the app?)
Any and all suggestions are welcome.
Thanks
I have talked with Apple Developer support, and just FYI. You are only allowed to stream 1 MB per minute over the Cellular network. Support suggest that you test your app in the following way:
"The basic measurement methodology is to turn off all background updating (particularly Mail's automatic mail downloads and Calendar updates), reset the transfer statistics in "Settings:General:Usage:", and then launch your application. Let it run for a fixed amount of time (five minutes is reasonable), and then exit your application. Once you've finished the test, the numbers listed under "Cellular Network Data" in "Settings:General:Usage:" are what you should focus on reducing.
Using what I just described, I'd suggest 4.8 MB every 5 minutes as the guideline you use to ensure your application stays within our bandwidth requirements."
Hope that helps at least a little.
Have you considered HTTP Live Streaming? It's built into OS 3.0.
Basically, you split your media into small (say, 10 second) snippets and put it on a standard web-server. Then you create little text 'meta-descriptor' files in EXTM3U format that point out where the bits are. The interesting thing is that you can create multiple versions of each snippet at different bit-rates. So if your bandwidth is good, the iPhone player dynamically chooses the higher bit-rates but when it's low it automatically switches to the lower bit-rate version of the snippet. It does this on-the-fly to adapt to changing conditions.
So if you split your MP3 into multiple 10-second bits at say, 3 different bit-rates then when the user is connected through WiFi they get the high-quality stuff but if they're on 3G or EDGE they get progressively lower-quality (and smaller sized) content.
If this violates your downloadable media concept, then perhaps you can use the same trick and keep multiple size files for each connection type. Then if you're on WiFi (or get a fast turnaround on a heartbeat ping to the server) download the big file vs. medium or small size ones.
Here's a decent step-by-step on segmenting content. They focus on video but it should work with audio content as well.
I would suggest throttling the bandwidth on the network/http request when connected to cellular, and having no throttle on wifi.
A combo of using Reachability to detect the network status, and implementing your http request using CFNetwork with a sleep until the next second whenever you have already downloaded as much as allowed per second should get you there.
You should check out this project, either to use, or just to see an example of how to code this well:
http://allseeing-i.com/ASIHTTPRequest
The ASIHTTPRequest class implements this, using either the old or 2.0 version of Reachability, and also provides a class level throttle, so even if you have multiple concurrent downloads and uploads, so long as all of them go through ASIHTTPRequest, they will be properly taken together and throttled properly.
A bit more on how to use this here:
http://allseeing-i.com/ASIHTTPRequest/How-to-use#bandwidth_throttling
Lots of good stuff in this (and no, I am not the author of any of it).
On a more serious note, what is it trying to do? There are many markets for iPhone outside of the US which don't have good download rates for phones, nor are the download cap sizes good, so having an app do lots of downloading isn't a good thing.
Could you possibly drop the data rate on your mp3 or some such? Make it optional to do the downloading with a warning that it will use your download?
YOu could not download the mp3 unless you are on wireless, and inform them of that. If you the mp3 are too important, then just tell them it only works on wireless, or include a few mp3 on the device. But 30min of mp3 is ridiculous, that is about what, 30meg.... think about it, 30 meg is just too much.