Yeah that’s what I meant by segments of the same type not merging, I feel like it’s the same bug that was in the non beta version
I don’t have a good example I ended up deleting the beta because it’s a little too not fleshed out for me yet, but when confirming locations often there are 0 stationary activities, but that might just be my model
It was a bit annoying to go through every location manually to make the points within a visit stationary
Hey! For the onboarding screen, I was swiping through the screens instead of hitting the “Continue” button but I guess that button launches the permissions acceptance screens. Instead of Continue, maybe “Authorize Location”, “Connect Location Data”, “Allow Location Data” or something else. That way it gives more context to the user? Thanks!
Aah I wonder if I didn’t port Foursquare category to icon mappings over. I’ll dig about in the code.
Yeah, that and the address lines really help, I’m finding! When you’ve got a list of sometimes similar sounding places, those extra little bits do a lot of work to disambiguate.
Strong agree. Don’t know why I haven’t put that in yet. I think I’ve put them in for at least one other destructive action. I’ll make sure that’s on the todos for the next TestFlight build.
I’m also not 100% happy with the button being down on the bottom left. Or were any of the bottom buttons are at the moment. But I’m still in the phase where I’m not sure if it’s just a muscle memory problem or a genuine UX problem. Still waiting for the muscle memory to settle before I make my personal judgement on button placements…
Processing and recording engine hasn’t changed at all since last build (I think no new commits at all in LocoKit2 codebase), so it’ll be just a chance thing.
Basically it’ll… well it’s not quite simple enough to boil down to a “basically”, but what the processing engine does is go through several steps in those cases:
So that’s “basically” what’s happened. It’s done the edge stealing, but then assessed those “stationary” Trip items as still passing the “keeper” threshold checks, so it’s left them. Annoying, but in terms of the recorded location data, technically still correct. (The worst kind of Technically Correct - the annoyingly wrong kind!)
There is however a quick workaround in these cases. You can long press on those stationary items and select “Confirm stationary” or whatever the menu item is called. That’ll convert it form being a Trip to being a Visit, at which point it’ll be a Visit-to-Visit merge consideration, with different rules, and it’ll almost certainly merge immediately, without fuss.
So basically just long press on each one, “Confirm stationary”, and it’ll disappear and all will be well.
On the question of “why did this happen this time?” the answer will be something along the lines of the location data in this particular case being a bit too drifty. If those stationary samples all clustered very close to the Visit edge boundaries, then processing would’ve automatically merged it all in / edge stolen it all in. So for those drifty items to survive the processing the location data must’ve drifted too far away from the Visit edges, creating data that technically looks more like genuine movement away from the Visits. So… basically just bad luck in terms of location data.
@Hutima, was this after an import from old LocoKit database? It sounds like your activity type models hadn’t built yet, so the activity type classifiers weren’t doing their job well yet.
After the old LocoKit import finishes … actually I can’t remember the exact flow. But basically the activity type classifier models have to do an initial build, for each neighbourhood your data covers. That can be quite a lot of model updates. Many of them will be tiny, and take only milliseconds each to get done. But some will be chunkier jobs, like around your home or work locations, common travel routes, etc, and can take some seconds or even up to around a minute to complete.
So the first model builds can … it’s a bit random and unpredictable. You might end up with the right models falling into place almost immediately, or possibly it might be some minutes or longer before the classifiers start doing their jobs well. I think it might also prioritise the models for the location you’re in right at that moment, to try to make sure the most important models are updated first. But yeah, there’s still a bit of luck / randomness to it.
Yeah that very much sounds like the models weren’t built yet. If anything, Arc Editor’s models/classifiers should be producing significantly better results than old Arc Timeline’s. It has better data to work with (well, its own recorded data, not the old imported data), and also has generally smarter models and auxiliary tooling than the old system had. But yeah, if the models haven’t finished building yet, there will be that period of “this is doing dumb things” until it catches up.
No worries! Which parts weren’t feeling fleshed out enough though? I’m very much trying to prioritise adding back in features based on beta tester feedback. I can focus on the things I personally want the most, but it’ll be much more helpful to base the priorities on everyone else’s needs! One person’s wants versus everyone else’s wants/needs 
So yeah, definitely left me know which bits stuck out as “oh it doesn’t have that yet”, so I can nudge those tasks up the todo priorities.
Hi @zerbzman!
I 100% agree, but Apple doesn’t. That explicit phrasing is how I and every other third party Apple developer wanted to label those buttons, for years. Then Apple decided for some insane reason “no, you’re not allowed to tell users to give authorisations!” So we had to change all the buttons to be … well, to not actually describe the impending authorisation task. If we didn’t do that, our app updates got rejected from the App Store. Utter madness.
Maybe Apple have backed down on that nonsense now - that was a few years ago. I wonder if it’s worth a try, submitting a build with more sensibly named buttons. Though there’d be the risk that it’d get through the less stringent TestFlight approval process only to eventually get rejected during the final App Store approval process. Hmm.
Oh, trivia: This is also why you used to see apps show you an actual mini screenshot of what the authorisation dialogue would look like, and tell you which button you needed to tap, but then all those explicit “this is visually what you’re meant to do” explanations disappeared from every app.
Apple deemed those screenshots and instructions to be Bad, and Anti User. I guess their reasoning was that all privacy relevant authorisations should be (or in their terms, must be) optional, so the app isn’t allowed to lead you into a privacy effecting choice, and can merely describe what added benefits that choice might provide.
Absurdly, even if your app absolutely requires that data (let’s say it’s a location timeline recording app, called, oh I don’t know, Arc Timeline? That literally can’t do anything without location data) you still couldn’t explicitly push the user towards giving approval. It was a strange time in App Store submissions process wrangling. And by “strange” I mean “infuriating”. Heh
I think at one point I was even told that Arc Timeline had to still function even if the user denied location data access. Like… what’s it meant to do? Just sit there? I think at that point I just rejected the build submission process and resubmitted a new build, hoping to get a different reviewer who was less strictly adherent to the letter of the law 
Today I experienced an issue where I made some changes to the timeline (correcting Visits, changing some segments etc) and the Arc Editor UI did not update. The iPhone became very hot and I can see that the Active Operations were stuck. There are six items in the Active Operations that have been running for a very long time (3 minutes)!
@trackerminerfs Yeah this is a super annoying mystery problem I’ve been trying to figure out for a while!
Something jams up the system. I initially assumed it was either the Photos framework or the HealthKit framework. Which… might still be correct. So I put in some timeouts on those lookups on timeline view, so that if either Photos or HealthKit lookups are stalling (sometimes those iOS subsystems decide to take way too much time to reply), it wouldn’t jam up the whole system.
But it’s still happening sometimes. So either it’s something else, or I should be using a shorter timeout for Photos and HealthKit.
Anyway yeah, definitely aware of it! And hopefully soon I’ll figure out who it is that’s jamming things up. Maybe instead it’s something inside LocoKit2, that’s being sneaky and not showing up when I go looking. We’ll see…
Oh when that happens, what I’ve found clears it the fastest is putting Arc into the background and coming back in a few minutes. It seems that whatever the jam up is, it frees up fastest if there’s no UI updates going on.
Oh yes! This bug appeared again today and I tried your suggestion of putting it to the background, waiting, and then reopening it. Works indeed!
