-
Notifications
You must be signed in to change notification settings - Fork 19
Build fixes #73
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
base: master
Are you sure you want to change the base?
Build fixes #73
Conversation
- Fixed bad reference to MS Band dll's - Added missing reference to System.IO - Updated exception message as BluetoothDeviceInfo.Id is no longer available - switched to using Name
…re inaccurate Filter invalid map points before exporting to GPX. - Updated BikeEvent & RunEvent to return IEnumerable<> instead of naked List<>. - IEnumerable backed by new BandMapPointCollection which serves as central place to execute any filtering/processing etc on map points as they get exported. Just runs a simple filter on bad mappoints currently. - Added Unit
Updated to compile and work with v1.3.10423.3 of the MS Band dll's
Events now loaded on a task. UI updated with the list of results on the UI thread once complete.
Blocking was occurring while event full load was occurring.
Commented out most of the bluetooth device implementation as its pretty broken and unused currently
The MapPoints I changed to have a backing field over a naked List<> to basically add clarity to the interface. List<> implies as a client you are free to add and remove to the MapPoints, I don't think that's the case, I thought the Event classes owned the map points, hence IEnumerable was a better return type. |
Happy to remove the commented out code. |
Regarding removing bad points versus early removal. I figured its better to keep as much info for as long as possible. i.e. maybe the raw data gets persisted to a store in the future. Later we may find a better way to handle the bad data than just filtering it out, if they get removed early and never persisted, we wouldn't be able to recover them. All very theoretical, but my general thought was to keep as much data as possible. |
For commit https://github.com/robsonj/unBand/commit/cbdd3b0c3e9c366231069b5658a241309b999036 it did not compile on a fresh checkout - for me at least. hence the fixing of the references |
Regarding - https://github.com/robsonj/unBand/commit/2c6de4fee9a87e43aafd6ed87b5c3e61945f3e47#commitcomment-11234866 Yep sounds good it can be split out |
available - switched to using Name