If I had a webpage that had a square on it and if I was using push technology to update the coordinates of this square on the page, could I see these updates well in a mobile browser (how much in "real-time" would the responses be)? I want to use Sencha to make a board game and want to be able to use push messaging to update coordinates of items. Is this at all possible? If so how scalable would it be?
Yes and no.
It entirely depends on the specific browser on the mobile device. For example, the iPhone browser will most likely support more than one push tech, but something like Opera Mini or a simpler browser in an older phone might not.
Then again, older/less feature-rich browsers might not support "normal" Ajax either.
As for scalability, the type of the device used as the client does not have an effect on scalability.
Related
assume we have the following scenario:
We have an application which supports only firefox only. The applications uses GWT. Some customer requires that the application should also support chrome browser as well. New permutation was compiled for chrome as well.
Question: What should be tested to ensure that we have same functionality on the new browser and how? Should we just start application with the new browser and check page by page and function by function?
Like you say, you would need to check each page and function.
In my experience, when the app does not explicitly style a visual element, the browser's base style for that element is used, and in some cases that can differ a little between browsers, as each browser has a slightly different base CSS. So, depending on your app, you might find things sized or positioned or colored differently.
It shouldn't be necessary to test any differences.
From GWT's overview:
Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript.
So, unless you do some fancy things, all should work the same way, no matter which browser is used.
A service that I often use to see how well my efforts are shaping up in different browsers and OSs is BrowserStack. Does something of the same ilk exist for testing out the behavior of different mobile devices? Say for instance I want to check the behavior of a webapp on an iPad, a Galaxy Tab and a Surface. Is there a service in the cloud that can help me do this?
http://www.genuitec.com/mobile/ - try using for ipad/iphone/android. But I don't think it's ideal solution. Sometimes I use android SDK emulator as well.
I am in the process of updating my business website and I've decided to use HTML5/CSS3 (with some PHP) for the whole thing and it works fantastic in every new browser (IE9, FF6, O11, S5, C13) with or without JS.
Now I am not sure what I should do about every other browser version. I imagine I have a small amount of leeway with most of the browsers (atleast the previous version) except IE8 (I have the IE shiv, but it doesn't cover non-js browsers.). Most of the features degrade nicely, but there will always be issues with older browsers.
I know nonJS browsers are probably a minority, but it would be nice
to cover them as well
This list is ordered in the order of current preference to cover the
largest number of browsers(nonJS/JS) but time to implement hasn't been
considered.
Only considering web-browsers, plan is for a mobile site for mobile browsers
Here is the list:
Build a really dodge version of the site using tables^, etc. and redirect the users there if they have an old version of the browser (server-side) and have a warning on there about upgrading.
Use Javascript to fix up the bits they don't work (like the shiv). This doesn't really cover the nonJS browsers which as stated are probably a minority.
Build a static old browser page to redirect the old browser users to a page with links to upgrade download links. This is a real copout solutions, but is quick to implement
Assume the only users that have old browsers are IE users, and use conditional comments to implement one of the previous options. Assumptions are always bad
Pretend users have the most upto date browsers and make no attempt to fix the site at all. Not really a practical option
Rebuild the website for HTML4 and use it accross the site. Bit of a waste of current work. As well as it looks a bit dissappointing if a webdeveloper has a site using old technologies, which was the driving force for the upgrade
What are your thoughts/solutions to the HTML4/5 limbo? Is there anything you've done in current projects to combat this?
Cheers,
Steve.
P.S. Being a member of the 'I hate IE6 and don't care for it's existance' club, I'm pretending that IE6 (or less) never existed.
Update (to clarify)
^ - by tables, I mean are really slapped together version of the current website, using either a table/non-table based layout. But something that may not look pretty when the source is viewed, it's really just there to fill the compatibility void.
It's perfectly acceptable to have features in some browsers and no features for an older browser. See Here.
However, it should be noted that whenever a fix is doable, you should have it. Unless a website is a JavaScript based app, it should be working without JavaScript, note that working != working perfectly.
if you have a hover state with a cool transition, which Chrome 23423 will support, but IE7 won't, then you can either emulate it using Modernizr and jQuery, or leave it as is, and IE7 won't enjoy the goodness. BooHoo.
You must however, give older browser users a message to encourage them to upgrade to a better ones, especially talking about IE<=7.
You built the website in the wrong direction.
If you want to support older versions, instead of building a cutting edge website and then trying to get it to work in older browsers, you need to build a basic site that works everywhere, then use advanced CSS and Javascript feature detection to add features for the newest browsers.
I'm working on a quick page intended for mobile browsers. While there is little consistency between browsers on cell phones (the target audience), I have a phone number that I would like to be as easy as possible to dial from the users phone. A link seems the obvious choice; so I set up the following:
1-888-123-5467
This seems to work OK on more advanced browsers such as the Android & BlackBerry browsers, it's a lot less reliable on other phones. Any advice on making this link work consistently and or correctly will be greatly appreciated.
FYI, this is a toll free domestic US call, but I imagine that some devices may be looking for a more general format.
The approach you are using is the 'standard' way to do this (i.e follows RFC 3966). If a mobile browser does not interpret it correctly, the only obvious way to fix this would be to extend or modify the browsers behavior itself, which you probably do not want to do or have access to do.
I believe it is supported on Windows devices (mobile explorer), iPhone (safari), Symbian and from what you are saying Blackberry and Android.
Are you finding problems with theses devices or are you supporting other mobile phones also?
Note that others seem to be having the opposite problem with iPhone and iPad as the default browser (Safari) changes anything that looks like a phone number into a link:
http://www.darowski.com/tracesofinspiration/2009/03/31/stop-iphone-from-incorrectly-auto-linking-phone-numbers/
What I eventually came up with was a link that worked like this:
1-888-123-4567
This has worked on every phone tested so far, including Android, BlackBerry and some very clunky older phones. From what I gather, the structure of the link works like so:
WTAI references the Wireless Telephony Application Interface. The wp/ refers to the WTAPublic functions. The mc; is the makeCall function, and then of course you have the phone number. Similarly, you can do a link like this:
Add to addressbook: 1-888-123-4567
This is the same except mc; has been replaced by ap;, which refers to the addPBEntry function. This adds the phone number to your address book or similar stash of phone numbers.
These two sites were helpful in my research:
http://www.oreillynet.com/wireless/2004/02/06/mobile_browsing.html
http://www.informit.com/articles/article.aspx?p=22182&seqNum=4
I've seen big sites like yelp use a different method for accomplishing this, where they use vcard and tel classes:
http://microformats.org/wiki/hcard
<div class="vcard">
<span class="tel">(555) 555-5555</span>
</div>
I'm developing the CSS file for the mobile version of the website my group are working on for our web design coursework, and I was wondering if it was possible to design a site for touch based browsers using the currently ratified specification of HTML and CSS, as the other member are doing for the desktop variant, or am I going to have to use the draft specification of the new language. I'm not intending to use anything too elaborate, I'm only attempting to allow the user to navigate the site with their finger, and the current implementation allows me to activate a dropdown menu on the desktop, but when I try to navigate on my Android handset, nothing happens.
The menu button gets illuminated in the way that all links in my browser do when they get pressed, but nothing happens. The research I've done since this revelation has led me to the conclusion that I'm going to have to experiment with the new spec, though since this is coursework, I'd rather stick with current standards than experimental drafts of new ones.
P.S. I'm only developing an informative site, not an application.
Yes, you can use older versions of HTML. iPhone, Palm OS, Android, and recent versions of the Blackberry OS all use Webkit, which is the same rendering engine that Chrome and Safari use.
In fact, the very first page on the World Wide Web will work just fine.
We'd need to see your code for your navigation bar to troubleshoot, but it's probably something along the lines of using a hover event to display the navigation (touchscreens can't have a hover event).
I can browse to any site on my iphone using the touchscreen. The language is not the problem. Most mobile browsers on smartphones can handle html(4)/css(2) fine. You should be more worried how to show the content so it will be easy to navigate on the site using a (small) touchscreen. Usability testing is your friend here. Browsing a website made for desktop can be very frustrating (not impossible) on a small touch screen.
Also the size of images and stuff shouldn't be to big. Since loading those can be a pain. At least the t-mobile(Netherlands) g3 network is slow, if available at all.
Note that the 'currently ratified' version of CSS is CSS1 (from 1996), CSS2.1 isn't yet a W3C Recommendation. So from that point of view the standards your other members are using for the desktop variants are not much more ratified than HTML5 and CSS3.
For sure do it! just ensure links are larger for fingers. Also allow the site to resize.
Most mobile sites are HTML1.0.
You would be silly using html5 + css3 unless you knew that it was only going to be used on an iphone eg. webapps.
And don't forget you can still use JavaScript!
Go For It!