Watch Support not clear

[helmutnn]

Its not clear how the Apple Watch Support should work. The App is not offered for installation on the watch and stopping at a charger listed in the favorites does not show up a dialogue to check in the charge at GE.

[remuslazar]

There is no dedicated Apple Watch Support right now. Because the Apple Watch does handle all notifications from the iPhone and also the notification actions, it is possible to create a (successful) CheckIn with the Apple Watch "stand alone".

I already documented the CheckIn Feature in the Wiki here:

https://github.com/remuslazar/EVPlugFinderPublic/wiki/Check-In-Feature

So this should just work as expected, see the Apple Watch Screenshots..

[helmutnn]

Did not work as expected, no notification arrrived. Neither on the iPhone nor on the Watch. Charging station was registered as a favorite, notifications were allowed for "Ladestationen".

[remuslazar]

Could you try to adjust the "Proximity Radius (100m - 300m)" in Settings? The Default value is 150m, you could try to increase the radius gradually.

Join the new project Slack!

[helmutnn]

According to the App i am 5 m away from the charger. Increased Radius to max now, lets see what happens next time.

[helmutnn]

Second day of testing, no Notification on Apple Watch or iPhone when i arrive at a charger that is present in the favourites.

[remuslazar]

how many favorites?

[helmutnn]

Eight.

[helmutnn]

As this issue is still valid (iPhone 7 Plus and Apple Watch 1st gen): How about offering checkin latest in the moment the user opens the app and being close to a charger in the favorite list and not having done the checkin via the Watch in the last few minutes?

[remuslazar]

.. but then I have to turn on GPS every time the user wakes up the app from background (=battery)

A GPS fix will also need some time, sometimes several seconds or even longer, so I have to wait for the GPS fix and then "automagically" open the detail view of the charging station near-by, which will be very irritating and will lead to a quite bad UX IMO.

[helmutnn]

Then please just make it an option. On my iPhone the position is quickly accurate and battery usage is really no concern, because you practically start the app at most a few times a day.

[helmutnn]

Wirh the new version the alert appears on the watch. However, the range setting seems not to work. When i come 300 to 200 m close to a station on the favourite list the notification appears, so per day i have around 4 notifiations wirhout even being close to the charger. Range setting is set to minimum in the app. Shall we close this issue and open a new one?

[remuslazar]

I don't think we need another issue. The minimum range of 150m is the minimum distance supported by iOS. It depends on the hardware and network coverage, the geofencing being done without GPS! My iPhone 7 is quite accurate most times, the iPhone5 from my wife has a much larger tolerance, using the exact same settings in the App, though.

200-300m is quite good for average situations and I will say, this is the expected behavior.. just ignore the notifications - will be my pragmatic suggestion - if you get false positives.

[helmutnn]

150 m is not practible. I dont like some limitations Apple applies to us, like 30 seconds for background fetch and task completion :(.

[remuslazar]

this kind of limitations are for good reasons and are surely not meant to bother the devs....

[remuslazar]

and 30s are not true for background fetch when using URLSession background tasks....

[helmutnn]

I am aware of these reasons. But sometimes things take a bit longer, wirhout consuming cpu cycles or energy. My application e.g. queries t-mobile servers which are quite slow, and for accounts with many contracts the sequence takes longer than 30'seconds. There is also no way to be woken up at certain points in time in the background. I also kmow the reasons for this, but it is hard to understand for the customers why refresh cycles do not match their expectations. And to make things worse iOS throttles the frequency of background fetches if the user does not actually open the App. But that's exactly what the notifications are fore, you dont need to open the App because you are aleeady up to date with the information provided by the notifications. Sigh.

[helmutnn]

You can not extend the 30 seconds by issuing a sequence of URL Session background tasks, if ypu start new tasks at the end of a finished task. The requests in my App can not be parallelized, unfortunately, because the current contract is kept in the session.

[remuslazar]

@helmutnn my advice will be to use NSOperation's, which then encapsulate URLSession background tasks e.g. NSOperation can have dependencies, when, let's say the second operation needs some data from the first one. Else, they will run in parallel, the system will take care of it. I'm using NSOperations all over the place and I'm very happy with this setup. See also https://developer.apple.com/videos/play/wwdc2015/226/

[helmutnn]

Are you sure you can avoid the 30 second deadline with this? Would be not Apple like if they would allow it this easy...

[remuslazar]

Pretty sure, yes. I'm using NSOperations all over the place in my app Leafter, the whole logic is built on Operations. While fetching an update in background the app has to poll the Nissan server every 10 seconds and the whole process will take about 2 minutes to complete. All that being done with NSOperations with dependencies and from a background fetch session as well. I have Operations for the login procedure, refreshing an existing token etc, having dependencies between each other. The code is very robust, clean and testable because each Operation encapsulates a single piece of logic, heavily async.. and not having a single service doing "everything and the kitchen sink" instead.. the mentioned WWDC Session will show you some use cases.