I have an iPhone app that loads the following URL:
http://maps.google.com?q=Apple Stores&ll=37.331689,-122.030731&z=3
As expected, the google maps app loads on the phone, but zooms to the entire US. It does not appear to be respecting the z= parameter, or at least, not allowing a zoom level that shows stores in the area.
z=3 zooms to the country level. z=1 zooms to the "world" level. Larger numbers increase the zoom. Try something like z=8 or 9
http://maps.google.com?q=Apple+Stores&ll=37.331689,-122.030731&z=9
Edit: On second thought, 10 or 11 might be more appropriate. I guess it depends on how close you want the zoom. The maximum is 19
Related
We use the skmaps's(Skobbler) SDK in android and IOS,
Our function is to show one pin in skmaps, the other settings is default.
We can show the map on both android and IOS,
but the loading time is too long, it takes about 5~15 seconds.
I've been trying different Wifi network and different device(iphone 6s plus and HTC M9), but it's still slow.
Can anyone help me?
The SDK doesn’t seem to be slow at rendering.
So check the downloading process for the requested vector tiles.
How to improve it:
reduce the requested area - increase the zoom level so that as soon as some vector data becomes available something will get rendered (i.e. set the zoom level to 18 or 17)
reduce the size of the requested vector tiles - switch to using LightMaps (initMapSettings.setMapDetailLevel(SKMapsInitSetti ngs.SK_MAP_DETAIL_LIGHT) - the light maps contain fewer elements and thus are smaller and will be rendered faster
don't use pannable maps but use static maps when displaying the location of a certain POI - for this exact use case, showing a mini map associated with a POI most products use a static map (fixed png/jpg) as it renders instantly. This is especially relevant in scenarios when the POIs are in different parts of the world
According to Apple, the iPhone 4 has a new and better screen resolution:
3.5-inch (diagonal) widescreen Multi-Touch display
960-by-640-pixel resolution at 326 ppi
This little detail affects our apps in a heavy way. Most of the demo apps on the net have one thing in common: They position views in the believe that the screen has a fixed size of 320 x 480 pixels. So what most (if not all) developers do is: they designed everything in such a way, that a touchable area is (for example) 50 x 50 pixels big. Just enough to tap it. Things have been positioned relative to the upper left, to reach a specific position on screen - let's say the center, or somewhere at the bottom.
When we develop high-resolution apps, they probably won't work on older devices. And if they do, they would suffer a lot from 4-times the size of any image, having to scale them down in memory.
According to Supporting High-Resolution Screens In Views, from the Apple docs:
On devices with high-resolution screens, the imageNamed:,
imageWithContentsOfFile:, and
initWithContentsOfFile: methods
automatically looks for a version of
the requested image with the #2x
modifier in its name. It if finds one,
it loads that image instead. If you do
not provide a high-resolution version
of a given image, the image object
still loads a standard-resolution
image (if one exists) and scales it
during drawing.
When it loads an image, a UIImage object automatically sets the size and
scale properties to appropriate values
based on the suffix of the image file.
For standard resolution images, it
sets the scale property to 1.0 and
sets the size of the image to the
image’s pixel dimensions. For images
with the #2x suffix in the filename,
it sets the scale property to 2.0 and
halves the width and height values to
compensate for the scale factor. These
halved values correlate correctly to
the point-based dimensions you need to
use in the logical coordinate space to
render the image.
This is purely speculation, but if the resolution really is 960 x 640 - that's exactly twice as high a resolution as the current version. It would be trivially simple for the iPhone to check the apps build target and detect a legacy version of the app and simply scale it by 2. You'd never notice the difference.
Engadget's reporting of the keynote included the following transcript from Steve Jobs
...It makes it so your apps run
automatically on this, but it renders
your text and controls in the higher
resolution. Your apps look even
better, but if you do a little bit of
work, then they will look stunning. So
we suggest that you do that
So I infer from that, if you use existing APIs your app will get scaled up. If you take advantage of new iOS4 APIs, you can get all groovy with the new pixels.
It sounds like the display will be ok but I'm concerned about the logic in my game. Will touchesBegan positions return points in the new resolution? The screen bounds will be different, these types of things could potentially be problems for me.
Scaling to a double resolution for display purpose is straight forward, but will this scalling apply to all api's that input/output a screen coordinate? If not things are going to break aren't they?
Fair enough if it's been handled extensively throughout the framework.. I would imagine there are a lot of potential api's this effects.
For people who are coming to this thread looking for a solution to a mobile web interface, check out this post on the Webkit blog: http://webkit.org/blog/55/high-dpi-web-sites/
It seems that Webkit has solved this problem four years ago.
Yes it is true.
According to WWDC it appears that apple has build it some form of automatic conversion so that the resolution for applications will not be completely off. Think up-convert for dvd to HDTV's.
My guess would be that apple knows what most of the standards developers have been using and will already be using these for an immediate conversion. Of course if you are programming an application to take advantage of the new resolution it will look much nicer than whatever the result of apples auto-conversion is.
All of your labels and system buttons will be at 326dpi but your images will still be pixel doubled until you add the hi-res resources. I am currently updating my apps. If you build and run on the iPhone 4 sim then it is presented at 50%, go to Window > Scale > 100% to see the real difference! Labels are smooth, my images look shocking!
I have an App that is using MapKit. I am dropping pins and everything else, but when I zoom out to view the entire world, it does not let me go past the the middle of the Pacific Ocean. If I am viewing California and want to go to China, I have to scroll all the way East to view it.
Is there a setting that I need to turn on, or is this just the way it is?
I do note that this is how the actual Maps App works, so I might presume that this setting cannot be changed...
You are correct. It's just the way it is.
I need to create an iPhone simple view that, based on the location of the user in the world, points the person to a never-changing Long/Lat location.
Is it possible to know this from the iPhone API?
Any examples?
This is possible on the current (3GS) iPhone, but not on earlier versions (which did not have a compass). The APIs that you'll need to use are in the CoreLocation.framework.
Search the app store for "mecca" and you'll turn up many, many applications that do exactly what you're asking about. You'll also find several applications that let you drop a pin anywhere on the map and have the app point you to it.
I've recently written code that does almost exactly what you describe.
Here's what you ned to do:
Calculate a heading from your current location to your target location. You should use "great circle" calculations, so they show a correct heading even when the destination is over the horizon. I found code (in Javascript) at this link to show me how to do this:
http://www.movable-type.co.uk/scripts/latlong.html
You want the section titled "bearing"
That code uses javascript library routines like "math.sin(x)" You can pretty much just delete the "math." part, and the trig functions work as is.
That will give you your bearing in radians.
You then need to get your compass heading (if on a 3Gs phone), convert it to radians, and use the compass heading to correct for the orientation of the phone. If you're running on a 3G, you can skip the compass heading and show the bearing based on North being at the top of the phone, and let the user orient their phone towards North themselves.
Duncan C
I looking for options on how to track user zooming and panning on a page when viewed in Safari on an iPhone. Safari exposes move and gesture events, so theoretically I can keep a running tally of pan and zoom operations, but that seems like overkill since the browser must track that internally.
Is this information exposed through the Document Object Model?
When you zoom in, window.innerWidth is adjusted, but document.documentElement.clientWidth is not, therefore:
var zoom = document.documentElement.clientWidth / window.innerWidth;
(I've tested iOS4, without viewport <meta>).
However, I wouldn't rely on it for anything important. DOM viewport sizes/pixel sizes in mobile browsers are a complete mess.
On Mobile Safari and Android, here is an accurate way to measure how much the page has been zoomed.
Try it here: http://jsbin.com/cobucu/3 - change zoom then click measure.
Technique is to add a top level div:
<body>
<div id=measurer style="position:absolute;width:100%"></div>
and use the calculation:
function getZoom(){
return document.getElementById('measurer').offsetWidth / window.innerWidth;
}
The only problem is finding a tidy way to detect that the user has changed zoom (pinch, double tap, etc). Options:
webkitRequestAnimationFrame: very reliable, but likely to cause jankiness if using animations (due to performance hit)
setInterval: reliable but very ugly
touch events: look for two fingers or
double tap: ugly and maybe difficult to make 100% reliable
window.onresize + window.onorientationchange + window.onscroll: simple but totally unreliable (Edit: and onscroll can cause performance problems in WKWebView or Mobile Safari 8 or greater).
PS: Windows Phone needs a different solution (pinch-zoom doesn't change the viewport - pinch-zoom on Windows has its own separate viewport that is not visible to javascript).
Edit: Android Visual Viewport resize and scroll events may help? See https://developer.mozilla.org/en-US/docs/Web/API/VisualViewport#Events
According to the Safari Web Content Guide, zoom events (double tap) are not exposed, so I'm not sure how you can track this.
I do not believe this information is exposed through the DOM.
I actually think things might have moved on a little since Steve's answer, as having a look at the content guide link he provided I can see a section on Handling Multi-Touch Events and also Handling Gesture Events.
Haven't tried them yet but they look pretty promising. I'll provide an update once I've checked them out and have a demo link available...
I measure zoom this way (works on iOS only):
screenOrientedWidth = screen.width;
if (window.orientation == 90) {
screenOrientedWidth = screen.height;
}
return screenOrientedWidth / window.innerWidth;
It doesn't depend of how wide content is.
However, in iOS Safari window.innerWidth isn't correct inside a gestureend handler. You should defer such calculation for later execution. In GWT, I use scheduleDeferred, but I can't say how to implement this in pure JavaScript.
If you are using any elements with location:fixed this can get complicated, as the location:fixed coordinates are relative to the unzoomed window, where window coordinates are relative to the zoomed viewport. More info: How to position a fixed-location element on IOS browser when zoomed?