I just wonder if the devicePixelRatio related to the web-kit based browsers and Apple's device is really useful, Or it's just apple's private asset. You know, the web-kit engine is also belongs to apple inc. I think this kind of stuff was only meaningful for Apple's Retina screen, and i always think that the deference between the screen's resolution and OS's resolution should be handled properly by the OS, it's not our task.
If there are lots values of devicePixelRatio range from 0 to 1000000, how many pictures should i prepared for those screens.
Web browsing is the most popular activity for mobile device users and webpages themselves are served in a variety of shapes and sizes.
Apple and the various companies that followed them into the mobile hardware arena needed to make the web browsing experience as easy as possible in order to maximize the amount time spent using and relying on their devices. They needed to avoid having the user pinch and zoom and pan around a page in order to read content, so they exposed an API to web developers known as "meta viewport" which allowed them to serve with little extra effort a small screen adapted versions of their website.
Later they realized that scaling in such a manner made images look like absolute crap when scaled up in a higher dpi device like apple retina AND android devices like the galaxy sIII and nexus devices. So they made a variable devicePixelRatio and a corresponding CSS Media Query to enable web developers to detect that a given device needs higher resolution images in order for a website to look good after being scaled. No one expects website owners/developers to waste 2x the bandwidth serving bitmaps with subpixel data to EVERYONE just because 0.2% of their users happen to be using a device with 2x the usual amount of pixels for a given physical size. In order for a high dpi device to be successful they needed to make the web look good on it and the only way for the web to look good on it is to make it easy and worthwhile enough for a website owner/developer to opt into making their website look good on it.
its up to the website developer to weigh the cost and benefit of taking the extra time to selectively serve images so that a website will not look bad on high pixel density devices. If the web ever comes to a point where most websites are doing this, the consumer will be under the impression that YOUR website is of low quality, not due to some shortcomings in the hardware they are using.
and just to clarify:
apple only uses 1 and 2 for their devicePixelRatio.
google promotes use of 1, 1.5, and 2 (although they cannot always enforce this).
microsoft uses 96dpi (1) 144dpi (1.5) 192dpi (2) in their screen.deviceXDPI value
most people just serve one 2x resolution version of their assets to all devices above some sort of threshold like 1.3 and 1x versions to devices below that. For those web developers who understand what exactly all these device values mean and how to use "CSS Media Queries" or their respective javascript values, it is extremely easy and not as frustrating as I suspect you are imagining it to be.
Related
What will happen if I do the following:
I substitute all non-retina assets with the retina assets
I delete all retina assets in my project ( All the ...#2x.pngs etc.)
Why do I want to do this:
There will be less and less non-retina iPhones in the future (also due to minimal OS requirements etc.)
I get a lighter binary
I don't have so many "quasi-duplicate" files in my project which I have to maintain separately.
Now:
Will the iPhone 3GS scale down the image and display it properly (with a little bit of processing overhead of course)
Will a "retina-enabled" Phone be able to display the image properly even though it does no longer have the #2x suffix in the filename.
In 99% of cases this will work fine. However there are cases where images won't scale correctly (usually depending on the contentMode).
I worked with someone who did this exact thing and never noticed a problem, although I think it is terrible practice.
You will get a lighter binary, but you are asking the older devices (with less memory) to do more work. If you don't want to support these devices then don't, I think this is better than giving users a potentially broken app.
There are better ways to reduce the size of images in your app, reusing them wherever possible, stretching, tiling etc.
3GS and iPhone 4 will both display the image improperly.
The fact is 3GS won't scale down the image. So it won't display the image properly. iPhone 4 will scale the non-#2x image (scale it twice) so it won't display the image properly too.
Nothing will happen if you decide to do this. Older devices will try, but if you allow the device to even run your app, you will have quite a bit of work just to deal with the scaling issues. If you allow older devices to install your app, you will have to be prepared to get approved from Apple on older devices too. If the images don't work right on older devices, you won't get approved. You are also right that there are fewer and fewer retina displayed devices in service.
But... there are still quite a few non-retina devices still in service. Maintaining both is good for your users. Yes it adds a little extra heft to your binary, but with today's speeds on a variety of networks, that isn't the issue like it used to be.
While it is your right to choose which users to support, and there are many developers that share your sentiment, it is still up to you to decide which group of users you ultimately want to support. If you are fine drawing the line with retina displays, so be it.
I could finger-wag at you and tell you that you should support every single user, but I'm sure you've thought of that. If you are fine supporting retina devices only, go for it. If you are prepared to answer questions on why this one device is supported and another isn't, go for it. The good news is, no matter what you decide, you'll be right...eventually. Good luck.
We are going to redevelop one website we developed as an ASP.NET website to be a mobile one.
So, I'm wondering how does the development of a mobile website differ from a normal one?
Also, what is the best approach to do this taken in consideration that this mobile website will be browsed mainly from iPhone?
There are a number of differences between a mobile device and a standard computer.
The screens are much smaller (fewer pixels to display your page). You should put fewer elements on each page.
They are typically viewed in portrait mode (narrow display - narrow page). You should plan on using the full width of the screen instead of setting a fixed page width like most people do on standard web pages.
People use finger gestures to manipulate the page instead of a mouse (buttons/links should be larger)
They can include additional features such as geo-location, telephone, etc. that you can incorporate into your app to be easier to use. There are some libraries available to help you use these, such as jQuery Mobile.
Users are concerned about battery life plus the CPU tends to be slower. Make sure you keep animations and client side processing to a minimum.
Users are concerned about data usage. Keep ajax calls to a minimum (don't ask the server for data every few seconds!) and use graphics sparingly (it's better to use html/CSS to make the page attractive).
Flash isn't supported on iPhone and is not well supported on other devices. However, most mobile devices have decent support for HTML5, so you can typically use that instead.
Users on smartphones are used a different experience.
In addition to Brian's answer I'd add:
Screens are not resized but scrolled, however sides scrolling is not generally a good experience
Screens orientations can change, but the same scrolling rules apply
Consumers are used App like behaviour and as such less information with backwards and forwards between pages is common and between sites
Consumers generally have data concerns so data traffic needs to be minimised
Controls/buttons/selections/data entry need to optimised for hand gestures - for example think of what happens with the keyboard pops up to allow data entry, how much screen is available - can the see all their input easily if they need to?
I suggest that for developing a mobile website is to use the target smartphone for a few weeks to understand how the device is used in the real world.
I'm afraid you cannot use current asp-View to mobile especially for iPhone. There's special control set for iphone development - componentone.
If you web application is based on MVC or MVP patterns then moving will be not difficult.
Recently we have developed a site for iphone users, we are using asp.net/sql for normal site.
But when you look at mobile sites, mobile normally have small screens and some time optimization problem.
We use jqtouch for mobile development. A JQuery plugin for mobile web development on the iPhone,Android, iPod Touch, and other forward-thinking devices.
Learning Video
Getting started
Establish the context for the mobile site: is there subset of information that is more relevant to your mobile users? Maybe your regular site has apps that are irrelevant on mobile devices? Either way, you should create your mobile site separately in a mobile folder! You can then use a sub-domain to reach it: for example, http://m.mysite.com
You can use a combination of CSS Media Queries and 51degrees.Mobi to detect browser features and render the correct size layout depending on which type of device the user has.
http://html5boilerplate.com/
http://www.modernizr.com/ (this is included in HTM5 Boilerplate)
http://51degrees.codeplex.com/
Do not make the stupid mistake of following current fads like "Responsive Web Design" which attempts to squeeze a desktop version of a website into a mobile screen. Above links should get you started.
When i create web app for all mobile devices, what are all things need to follow,
Is it enough to create single html app for all device?
Or, create every single app for a device based on web browser?
Is there any Framework has overcome above mentioned issues?
Thanks in advance,
sri
No - different phone browser have different levels of HTML compliance. Compare iPhone/Android browser with, say, a 3 year old Nokia phone (that most corporate users probably have to use)
No - there are far too many browser/device/operator combinations for you to write individual web apps. This is known as the mobile web fragmentation problem.
Luckily yes - have a look at http://wurfl.sourceforge.net/ or http://deviceatlas.com/. These frameworks let you write one web app (within some limits). These frameworks will recognise the browser (through the User Agent) and output the most appropriate HTML for that device. They can also deal with issues like resizing images for lower end devices.
You need to be aware of the screen size as i think it's bad form to have to scroll left and right as well as up and down.
also, keep the page sizes small as your page may not be the only one open so you want to give users the ability to open more than a single page. also helps in speed and keeping the cost for the user down.
remember to have text size at a readable scale as mobiles are used not only stationary but also when in motion and being bumped around.
Following iPad's announcement and its SDK (iPhone SDK 3.2), porting apps to iPad becomes an important issue. What guidelines I should follow in my iPhone apps to ensure I can port it to iPad as seamlessly as possible?
The different resolution is particularly an important issue. While the iPad runs iPhone apps unmodified, it's not really the desirable behavior for a native app. How can we make our iPhone apps resolution-independent so that they can run gracefully on all resolutions like most desktop apps?
If you've been using IB and setting the resize behaviors of elements properly, and also coding frame coordinates all relative to each other you are half-way to having a UI that can potentially scale to a larger screen.
From the screen shots there are new kinds of action-sheets as well, potentially attached to UI elements instead of floating - if you use overlays today they will probably work about the same but you may want to consider changing placement from the center on larger display.
UPDATE:
Now the event is over, and registered developers can download the SDK - although we cannot talk about specific features here just yet, read through ALL of the documents related to the new OS version as there are a number of things aimed at helping you transition to supporting both platforms. Also before you start using custom libraries for things take a look through the API changes to see what new abilities might be supported that are not today.
Generally speaking, what I said above about IB holds true, and also you should start thinking about how your apps today could use more space to present more information at once instead of being split out over multiple screens. Also if you are doing any projects right now that use images, make sure to initially design the images large enough that you can also use them for higher resolution tablet applications.
It is far more reasonable to expect users to input text (and larger amounts of it) than with a non-iPad device.
Nothing, it appears. Although we don't have the SDK quite yet. It will all existing run iPhone app without an issue, albeit at reduced resolution.
It remains to be seen how much of the existing iPhone SDK is shared with the iPad SDK UI wise.
Judging by what has been said, absolutely nothing. You will have to adapt to the new screen size and better hardware all together, if you want to take advantage of the features that the improved device offers. The lack of a 3g module is also something to consider if your app(s) rely on that functionality.
I want to allow our main application to generate document files that can be easily read on the iphone, or other smart phones. The easiest way to do this, I think, is to create a simple HTML file and use javascript to show / hide different bits of it. For example, when the user clicks / touches "section 1", the section expands to show its full details; otherwise, it will remain collapsed to save space.
What guidelines should I follow when creating this file? I've done a little research and arrived at the following:
The iphone has a native resolution of 320x480, but only about 320x400 is visible for a web page.
Other smartphones have resolutions from 160x120 (probably not high enough to bother with) up to 320x240 and some even have 480x640.
These are useful for deciding how to style and arrange the HTML output, for example. Are there any other useful guidelines to work with? For example:
1) How big / small should I make things to let the user have a large enough 'target area'?
2) How can I get the file onto the iphone? Would the user have to drag and drop it via USB?
3) What size of fonts can I use before it gets too small to read?
etc etc. I don't actually have an iphone to test on, which makes this a little more problematic.
Thanks for your help!
I don't know about other smart phones, but the only way your file is going to get onto the iPhone is via the web browser, email, or a custom application that you write. There is no general mechanism for uploading files to the iPhone.
It's surprisingly easy to read even fairly small text on the iPhone, and the gesture-based zooming makes it very easy to zoom in and out.
If you're going to provide your documents through ASP.NET you might want to check this out:
http://mdbf.codeplex.com/.
It allows you to detect what kind of smartphone did the request, you can then check out the capabilities (screen-resolution, color-display, screen-pixels height... etc.)
Most mobile browsers render XHTML-MP (XHTML Mobile Profile). You can get away with rendering that.
iPhones (and other WebKit phones like Android) support the viewport meta tags which can make the experience more tailored to that phone screen size. You can learn about these in the iPhone web page creation docs from Apple.
If you are really interested in supporting a wide range of handsets, you should look at a "multi-serving" technology like WURFL, which will let you abstract a lot of the complexity away from supporting hundreds of handsets. It's sort of yesterday's technology though, since modern mobile browsers render most web pages just fine.
I'm not sure how current this is, but Yahoo says that one of the restrictions for an iPhone is that it won't cache files larger that 25k uncompressed. This doesn't affect your display necessarily, but it could affect your performance and so you may want to take it into consideration for your design.