Reverse Geocode Design

Loading...

En provenance du cours de University of California, Irvine

Games, Sensors and Media

51 notes

University of California, Irvine

Games, Sensors and Media

51 notes

Cours 4 sur 6 dans Specialization iOS Development for Creative Entrepreneurs

You will learn to make fluid digital interactive experiences that are suitable for gaming and use the advanced sensor hardware built into the iPhone and iPad. This includes drawing 2D graphics, playing sounds and music, integrating with Game Center, the iOS physics engine and detecting device orientation and location. Upon completing this course, you will be able to: 1. Use the reverse geocode service to convert latitude and longitude to location names 2. Implement GeoFences to make an app efficiently monitor an iOS device’s location 3. Leverage the power of accelerometers, magnetometers and gyroscopes to orient a device in physical space 4. Create an app that responds to ambient light levels by using screen brightness as a proxy 5. Play sound effects and other media as audio 6. Make a game like Pong 7. Make a game like Breakout 8. Manipulate graphics in a game environment 9. Use the physics engine to create realistic game worlds 10. React to multi-touch events for complex interaction design 11. Detect and respond to collisions and contacts efficiently 12. Chain complex sequences of actions, animations and sounds with precision 13. Animate multi-frame sprites 14. Create particle systems to simulate fire, smoke and magic (and more!) 15. Interface with Game Center to create leaderboards and achievements that can be shared through social networks

À partir de la leçon

Location, Locomotion and Motion

In this week we are going to do a deep dive on the sensors in the iOS platform. Sensors are one of the aspects of smartphones that make them a unique platform and form a bridge between the digital and physical world. We will look at different ways of bridging that divide with location sensors (and street address look-ups via reverse geocoding), geofencing and motion sensors. This will give you the skills to write code that makes your apps aware of the world around them and possibly even react to a user’s physical movement.

Reverse Geocode Concept21:20

Reverse Geocode Design4:01

Reverse Geocode Case Study 0128:21

Reverse Geocode Case Study 0210:33

Rencontrer les enseignants

Don Patterson
Associate Professor
Informatics and Computer Science
Sam Kaufman
Partner at Gradient

[MUSIC]

All right, so what I want to do in this lecture is just to set us up for

our reverse geocode design, set us up for our case study, try and

understand what it is we're going to build.

The high-level idea is that we're going to have an application

that's roughly laid out like this.

We're going to have a map view that's at the top,

and that's going to fill up most of the screen.

That's that gray box there that has the cross hatches for streets.

We're going to have that take up most of our screen.

The user should be able to pinch and zoom, move around,

pan through the world as you would any map interface.

In the center, though, we're going to put a pin, and

that pin isn't going to be programmatic, that pin's going to be a graphic.

We're going to have that graphic as an image object that's going to

be floating on top of the map view.

And that will just be kind of a target that we're going to be using for

the user to orient where we're going to be doing the reverse geocoding.

Down at the bottom, we're going to have a label.

That label is where we're going to put the results of

the reverse geocoding information.

And in our first design we're going to have a button next to the table

that's going to cause the reverse geocode to fire off.

All right, so the way this would work is that the user is moving around,

that pin is going to look like a pin on the map, and there's going to be a dot.

And when the user moves the map around so

that the dot is located on a specific location, they'll hit the button.

And the reverse geocode event will go out to Apple's iOS services to do that.

The results will come back, and we'll put the information here in the label.

Now, this is going to be the first version that we're going to implement.

And what we're going to do in this first version is we're going to

just only have the services go when we hit the button.

The only thing tricky we're going to do with this user interface,

besides that PIN at the top, is that we're going to have the label change size.

Because you can have different amounts of placemark data come back, we're going to

allow that label to get larger with more data and smaller with less data.

And we're going to have the map view adjust so that as the data goes in,

the map view goes up and down to accommodate all that data.

So we see all the data that's getting put in.

That's just going to take a little bit of thought in the constraints that

we put on there.

Now, Sam's really good about thinking through some of these different

ways of doing UIs.

And one of the things that he really was interested in doing

was getting rid of this button entirely.

So in version two of the interface, we're going to get rid of the button,

we're going to extend the label the entire length of the bottom.

We're not going to be using the toolbar,

we're just going to have a label down there.

And as the user moves the map around, every time the map

settles into a location, we're going to fire off that geocode event.

So that the label is constantly getting updated without having to hit

the button in order to cause the event to go off.

Now, the reason why this is tricky is because we don't want to

hit that rate limit.

We don't want to send out events too often.

So in the second version what we're going to do is we're going to make sure at

any given time we only have one reverse geocode event going out to the service.

Because a geocode takes a little bit of time to send the information out for

the service to calculate the address and to send it back, that amount of time,

we're going to assume is a good amount of rate limiting.

So if we only have one request in flight at a given time that should be okay.

And then when the user stops moving the map, we'll stop sending the request out.

All right so that's kind of what we're going to hit in our case study.

I just wanted to give you kind of the overview of where we're going, so as we

dive into the code, it's not confusing how we're going to get there, okay?

All right, let's do that.

[MUSIC]

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2018 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play