Does anyone know of a way to target only iOS devices using media queries? I'm looking for a way to give an iPhone (1,3G,3GS,4,4S,5) user one experience, an iPad (1,2,3,mini) user another, and everybody else (desktop, android, windows phone, bb) the default experience.
I feel like my options are limited since many phones share similar widths and parameters. Does anyone know of anything to use in media queries that are specific to iPhones and specific to iPads?
I've so far locked down iPhone 5 with the following code:
#media screen and (device-aspect-ratio: 40/71){}
and iPhone 4 and 4S with:
#media
only screen and (-webkit-min-device-pixel-ratio : 2) and (orientation:portrait),
only screen and (min-device-pixel-ratio : 2) and (orientation:portrait){}
#media screen and (-webkit-min-device-pixel-ratio : 2) and (orientation:landscape), screen and (min-device-pixel-ratio : 2) and (orientation:landscape){}
I've seen similar questions to this on here, but haven't found one that has addressed this specific use case.
This is for use in an email so I'm unable to use javascript. Media Queries only...
Thanks
Media queries can only infer a few media features, and are designed to serve different content based on features, not brand or model.
Probably best you could do is to target the exact device-width for each device listed: someone here has already provided, as an indication, how to specifically match the iPad's dimensions.
The problem is that out of the huge range of devices out there, some feature the same dimensions (and the webkit browser — which can be inferred via hacks). All in all, CSS is even worse than JS at determining esoteric brand or OS features of the device in question.
Related
Thinking from a mobile first perspective with phablets in play and Microsoft Surface, should I stick to the standard breakpoints or go with more of:
#media only screen
and(max-width: 414px)
and (max-width: 736px)
and (-webkit-min-device-pixel-ratio: 2) {
}
This is what I am thinking. If I do it like that for hand held devices and just develop fluid, would it be better? Or should I use what was mentioned here:
stackoverflow iPhone media queriews
I think targeting specific devices has is its place, though I don't think it's a good starting point.
As a more general approach to mobile design, have you considered begining with a responsive design, there are a host of frameworks available to get you started quickly.
Then test your site at different viewports and add your own media queries that are specific to your design. For example maybe the layout of your header works best if it changes at 800px instead of your framework preset of say 768px.
As a final step, test your site on as many devices as you can and only then write device specific media queries, and only if they are really necessary.
Ideally you want your mobile site design to work well for current and future mobile devices, and so the more general your approach is at the start, the more you'll future-proof your design.
Good luck!
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.
I'm trying to figure out a way to mirror an iPad screen to other iPads. This doesn't seem to be supported on the platform though.
Basically, a teacher would have an iPad, then the students would have iPads and see everything that is happening on the teachers screen, but on their screens.
Thoughts?
I have been attempting to find a solution to this problem myself. I have not found any apps that can mirror exactly what is happening on another IPAD, but some come close.
RabbleBrowser and Ideaflight both had potential. Ideaflight appears to be more for business. RabbleBrowser appears to allow the mirroring, except it only works as a browser and a file/picture mirroring.
Both iPads are linked to the same wifi and when you join a session, they will mirror the iPad that started session. Also allows chat (controlled by session starter).
It does NOT continue to mirror if you move out of browser and into another app however. I had dreams of leading a class through a a lesson on google earth, but no go .:(
Another option is attaching a laptop to a projector. Then you download Airserver on the laptop. Go to the menu bar at bottom of iPad and turn on AirPlay. The laptop will mirror the iPad perfectly and project it! It's wireless and works well. I tried the HDMI connector to laptop but it gives a poor quality, shaky image.
Hope they allow mirroring in future updates. The capability is there, don't know why they don't! Guess trying to sell more appletv!
A similar question was asked on the Apple forum (https://discussions.apple.com/thread/3118281?start=0&tstart=0), and the following app seemed to help them or answer their question.
Have a look at Replicate Pro on the app store:
http://itunes.apple.com/us/app/replicate-pro-for-ipad/id363286515?mt=8
One feature listed in the notes:
Share files between two iPads/iPhones that are running this app. (Pro
version only)
I'm not sure if this will cover multiple devices or simply between two, but it may be worth a look. Sadly, the only way to try would be to spend $5.99.
You'll need to create an application for the student iPad that emulates the screen of the teachers iPad. I would suggest that, although i dont know if its possible, the teacher somehow starts up and app that emulates their entire iPad. Meaning, from within the app named "teacher share" (or whatever it is), they can access the music, settings, notes and other apps found on their ipad. Then that information could be sent over a network to the students.
Nearpod is an app that will allow you to mirror a presentation on several iPads. I have had up to 9 at one time. Through the Nearpod program you can make a presentation similar to PowerPoint, and also incorporate interactive questions, which can be multiple choice, short answer, and even drawings. The only drawback is the full version costs $10/month. The free version is still good, you are just limited on the size of the presentation.
After doing lots of research, I found one app which shares iPhone device into another iPhone device. Really great logic they have applied for screen mirroring.
No idea about detailed how they have implemented but after installing and checking the app I came to know that I think they have used iPhone Screen Recording and broadcasting it on to their server and then on another device they are syncing from the same URL.
OliOli a free and simple screen sharing app for iOS.
iOS App: https://itunes.apple.com/us/app/olioli-screen-sharing/id1382253993?mt=8
WebSite: https://olioli.io/
We have in store an app which displays a series of videos through HTTP Live Streaming. Due to the nature of this videos, and the screensize of the iPhone/iPod device, we have decided to leave behind everything that does not have retina display.
The reason? Well, this videos are encoded in high resolution, and even that we have encoded them in lower resolution, those videos are still a bit pixelated. Since is is a paid app, we don't want to charge iPhone 3G/s users for an app they're not gonna enjoy at most.
The problem now is that we have decided to make the app universal, so iPad users can enjoy the app without that crappy upscaling from emulation. The problem goes like this.
In order to leave behind iPhone 3G/s users from buying the app, we have set as required the front facing camera, but we do not use it, of course. Why? front facing camera = retina display ;) . The problem is with the iPad. We can do the same with the iPad 2, but not with the iPad 1.
So the question is...is there anyway so we can submit the app to be available to everyone except iPhone 3G/s (or iPod)??
You can put constraints on the App in the store, informing of the need for retina display or whatever device capability it needs (i.e., Camera [not on old iPod Touch], GPS, etc.). It does lead to bad reviews, but you cannot stop idiots in the world from buying a product. There have been plenty of cases brought to court where the plantiff is suing a home owner for being injured while breaking in or robbing the house and they won...I mean really?...don't let users who don't have common sense deter you from putting out a product.
To drop the iPhone 3G, you could add the magnometer as a required capability.
That still doesn't take care of the 3GS though...
You can make your app Universal, while maintaining the requirements. You should check two things:
The device is an iPad/iPad 2?
If not, does it have a camera?
Merging these two tests you can determine if the app is running on an iPad (2) or on a retina-display-powered device. It will just require a couple of lines of code more. Eg. test for:
UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad
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.