-
Notifications
You must be signed in to change notification settings - Fork 741
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Directions (Routes) and AR Polylines #159
Conversation
fix code style
…piles and the pod lib lints.
…oject to not directly reference the source from the pod in the project, but rather use it via cocoapods.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good. I noticed a few stylistic things. I'll put time into functional testing on a device later today.
@available(iOS 11.0, *) | ||
public extension SceneLocationViewEstimateDelegate { | ||
func didAddSceneLocationEstimate(sceneLocationView: SceneLocationView, position: SCNVector3, location: CLLocation) { | ||
// |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to exist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is that they are default implementations of the functions (essentially making them optional when conforming to the protocol). They don't have to exist, but by existing, they allow you to choose which functions you want to implement and not have no-op implementations for the ones you don't want to implement.
@available(iOS 11.0, *) | ||
public extension SceneLocationViewDelegate { | ||
func didAddSceneLocationEstimate(sceneLocationView: SceneLocationView, position: SCNVector3, location: CLLocation) { | ||
// |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this need to exist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is that they are default implementations of the functions (essentially making them optional when conforming to the protocol). They don't have to exist, but by existing, they allow you to choose which functions you want to implement and not have no-op implementations for the ones you don't want to implement.
…print statements, though; not CocoaLumberjack).
…ng them in AR, however I haven't wired it up to the map yet.
@aaronbrethorst - thanks for the feedback. I've responded and/or updated based on your feedback. I have started working on updating the UI and have hacked together the ability to specify a location, search for it, get directions and see those directions as a polyline in AR, however the settings UI is janky and I need to clean it up and polish it more. |
… as a gate for the PR.
…f the library lints correctly).
…search. 2. Search results are sorted by distance to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks 👍 awesome work!
Attempt at fixing merge conflicts with #26.
The original update info is:
.travis.yml
to lint the podTODO
LocationNode
andAnnotationNode
out ofLocationAnnotationNode.swift
and back intoLocationNode.swift
Updates
forEach
function blocks instead of for loops for example)ARCL.podspec
file to contain theswift_version
.swift_version
file (Podspec is now responsible for it)Checklist
open
, andpublic
scoped methods and properties.Tests have have been added to all new features. (not a requirement, but helpful)Screenshots
First Demo: the polyline route demo:
Second Demo: the (original) annotations