I wonder if the author considered moving payment processing to Adyen from Stripe? They're also EU-based and a bit more... well known? I liked integrating with them in the past.
IMO one of the cool things about Wallet is the notification that appears on the homescreen when you're in proximity of the venue or time of the event and automatically displays the pass when tapped. I wonder if "create your own" will be able to do that (I'm not sure how it would)?
For one, the article doesn't suggest that this will indeed be allowed as a part of that process. OTOH: it's easy for a flight ticket pass (which has time and airport location) but not for a gym membership pass (time can be anything and the gym can have several locations.)
Location-based functionality like this is already widespread in iOS; I'd be surprised if it wasn't supported. Reminders and calendar events (and PassKit!) already have it, for example.
I said this elsewhere in the comments, but I think there's sort of a fundamental tension that shows up sometimes between DRY and "a function/class should only do one thing." E.g., there might be two places in your code that do almost identical things, so there's a temptation to say "I know! I'll make a common function, I'll just need to add a flag/extra argument..." and if you keep doing that you end up with messy "DRY" functions with tons of conditional logic that tries to do too much.
Yeah there are ways to avoid this and you need to strike balances, but sometimes you have to be careful and resist the temptation to DRY everything up 'cuz you might just make it brittler (pun intended).
I think there is often tension between DRY and "thing should do only one thing." E.g., I've found myself guilty of DRYing up a function, but the use is slightly different in a couple places, so... I know, I'll just add a flag/additional function argument. And you keep doing that and soon you have a messed up function with lots of conditional logic.
The key is to avoid the temptation to DRY when things are only slightly different and find a balance between reuse and "one function/class should only do one thing."
For sure. I feel I need all of my experience to discern the difference between “slightly different, and should be combined” and “slightly different, and you’ll regret it if you combine them.”
One of my favorite things as a software engineer is when you see the third example of a thing, it shows you the problem from a different angle, and you can finally see the perfect abstraction that was hiding there the whole time.
reply