I liked this article a lot - information-dense but approachable. It feels like you can understand the entire app using only the code snippets in the article, which speaks to the quality of the design. The only part that made me roll my eyes was the AI piece - I don't think there's any actual AI involved in the app, it seems like the author just used it to figure out what metrics to use, and then hardcoded them into the app? (That's probably how I'd do it, tbh - I just think the AI part distracts from the overall point and doesn't need to be in the post.)
For deprecations we're lucky in that the underlying systems don't change very much (the Input Message Accountability Data isn't going anywhere). But we'll run into collisions when we, for example, start issuing cards on Mastercard as well as Visa.
We have experimented with a couple of, um, abstractions, and may do so there. One rule we've stuck to, and likely would as well, is to keep the "substrate objects" un-abstracted but to introduce higher-level compositions for convenience. For example, there is no such thing as a "Card Payment" (https://increase.com/documentation/api#card-payments) - it's just a way to cluster related card authorization and settlement messages. But it's extremely useful for users and nontrivial to do the reconciliation, so we tried it. But we think it's essential that the underlying network messages (the "substrate objects") are also accessible in the API, along with all the underlying fields etc.
Unfortunately 100% of the public APIs I have worked on are in payments. I wish I had another lens!
I guess the phrase "no abstractions" is specifically valuable to us when designing our REST API resources - our whole stack is certainly an abstraction of sorts, but we don't want to add yet another abstraction in that specific layer.
Yes, exactly, the important thing to us is that our users don't need to build an additional mental model between us and the networks we sit atop. If you know the network, we want you to be able to intuit how our API works. There's a very real difference (arguably the fundamental value-add of our company) in the transport layer, though. The actual mechanics of integrating with, say, FedACH, are a bit long to get into here (we get into it a bit here if it's of interest: https://increase.com/documentation/fedach) but suffice to say it doesn't have a REST API.
I took a crack at recreating this in javascript once the necessary APIs made their way to mobile safari - https://highphone.app if interested! (iPhones only, sorry)
We took the approach of starting with an intentionally bad name (in our case, bnk.dev) and using it until a good domain became available to purchase for a reasonable price.
Neat idea overall! Some small feedback:
- You should check and see if the device has rotation lock enabled (or use a rotation API that isn't affected by it); I keep it on by default and the game wouldn't work for me until I thought to turn it off.
- It's pretty easy to accidentally tap an ad and thus destroy your game session.
Great question. For classes with sufficiently rich customization options (UISlider, UIStepper, UIBarButtonItem, etc) I don't think it's necessary to provide a full-on subclass, as ultimately I'm not really changing what the class does. I'm really just providing a mixin for a particular set of UI customizations (setting colors, etc), which categories are perfect for.
Some classes (UIAlertView and UISwitch, most particularly) aren't very flexible in terms of appearance customization, so I had to reimplement them to achieve desired effects. Using them is more difficult: to use an FUISwitch (my UISwitch clone) you have to replace any UISwitches in your app with FUISwitches (also, if you were using categories/subclasses of UISwitch to do some custom stuff, they would break).
Moving logic to a base class isn't really possible, as most of those classes already inherit from UIControl (and I'm not crazy/motivated enough to reimplement them all from scratch - UIKit is awesome, and I want to lean on it as much as possible).
The single header totally makes sense, I'll be sure to add that.
TL;DR: UIKit is great, I don't want to reinvent the wheel, categories are really easy to integrate into existing projects.
That's a really good observation re: accessibility, and something that had totally slipped my mind. I'll add accessibility support for FUISwitch and FUIAlertView in the next release (everything else, being a subclass/category of existing UIKit stuff, should have it already).
I'm using CoreGraphics for a lot of stuff here, just not actually in the controls' drawRect methods. Rather, I use CoreGraphics to produce UIImages of various sizes/shapes/colors and then use the appearance methods provided by each UIControl (e.g. setBackgroundImage) to style existing UIKit controls with said image. So there aren't any external images included in the project. I prefer this approach, as it minimally interferes with each control's existing/desired behavior (not to feed the trolls, but one of the weaknesses in the "Apple wouldn't approve of this" argument presented elsewhere in the comments is that I'm almost entirely just using existing classes/appearance customization APIs provided by UIKit).
Thanks! It feels good to get this out there - we want (and plan) to open-source more stuff but have been so busy that we haven't had the time. Deliberately writing this to be open-sourced also made me a lot more considerate when developing it and improved the code quality as a result.
Hey Mason, appreciate the feedback. Actually, all of those bugs are fixed in the 1.1 release which came out on Friday night. So just update and you'll be all set!