Add convenience initializers for simpler code

[edorphy]

There are many classes that require a line for initialization, another line or two to set a few public properties, then finally appending it to the tree. It would be nice to have some convenience initializers for many of the classes.

Directly from the project markdown you have to do this:

let trackpoint = GPXTrackPoint(latitude: yourLatitudeHere, longitude: yourLongitudeHere)
trackpoint.elevation = yourElevationValue
trackpoint.time = Date() // set time to current date
trackpoints.append(trackpoint)

It would nice to be able to do this instead:

trackpoints.append(GPXTrackPoint(latitude: yourLatitudeHere, longitude: yourLongitudeHere, elevation: elevation, time: Date()))

Or better yet, if willing to make CoreLocation a dependency (maybe nice that it isn't). I know I can just write an extension for all of these, but they feel like a natural fit to have part of the API surface.

let location: CLLocation = ...
tracepoints.append(GPXTrackPoint(from: location))

[vincentneo]

Apologies for the delay. I thought I have already wrote a reply, when I didn't... Sorry!

I like both ideas, particularly more for the CLLocation one. Since CoreLocation is available in all 4 apple OSs, it should be fine, without breaking support for any OS or anything.

As with the other issue, will attempt when time permits.

[edorphy]

I might send a PR your way if I get to it. The precaution for adding CoreLocation is to make sure that it doesn't force the user to add location permission to the app.

[vincentneo]

I didn't know that adding CoreLocation would force a location permission requirement, in cases like this. That surely wouldn't be nice though.

Is there anyway to add CoreLocation without needing that?

[edorphy]

@vincentneo it depends on which API are called. I believe it is only when CLLocationManager is used for location detection, not just linking CoreLocation to use the CLLocation objects.

One could confirm this by submitting to Apple/TestFlight without the plist key present and see if it fails validation.

If I make a PR, I’ll certainly double check. Another option would be to make a second library that adds it and depends on this lib—power of Swift Packages that I have found.

I’ve asked other open source or SDKs to break their stuff into modules as to not need to inherit permission requirements that might not make sense. So it’s on my mind before adding this.

However, if someone has data to export as GPX, they’re likely already using location permissions for their app.

[vincentneo]

@edorphy

submitting to Apple/TestFlight without the plist key present and see if it fails validation.

Sadly, I did not enrol for the Apple Developer Program, can't test :(
(may do so in future though.)

Another option would be to make a second library that adds it and depends on this lib—power of Swift Packages that I have found.

Would CocoaPods/Carthage work as well? (Since both are supported in project.)

[edorphy]

@vincentneo Would you mind creating a branch for this? Maybe named enhancements/location-extensions?

I have a small handful of local changes that I can share that do some of the above mentioned.

[vincentneo]

Are you aiming for a separate branch for this functionality? If so I will create a branch called location-extensions, as I feel the enhancement prefix makes it a little too long.

If its to be pushed to the master branch one day, just create a pull request.

Thank you!

[vincentneo]

I have added a file that should work for your use case via a drag and drop. This should be safer than in any other way, and can still be maintained.