Team effort, but thank you!! I've just taken the next month and a half off to work on things full time. I'm excited!
The next update won't be huge, (Google required us to make all screens 'edge to edge'[0], which took up most of my time last month). I'm hoping for some solid improvements now that's out the way, once the release pipeline has returned to normal.
Feel free to get in touch if you fancy contributing.
If you can get your agent of choice to run up the app in an emulator and navigate the whole thing taking screenshots then tasks like edge-to-edge can be pretty hands off.
The way I did it was to firstly get accessibility identifiers on everything. Then have it record everything I do on an emulator to navigate the entire app. Then left it for a while to work out how to actually use the app via the emulator. Once you have this sort of baseline. A lot of changes are really quite pleasant. I often ask for an HTML gallery of screenshots covering a few device sizes as the step before I bother running it on a device myself.
We use Roborazzi[0], which is an excellent screenshot library, but:
* We target minSdk 24
* We're still using XML views
* We target a large variety of form factors
* We have a lot of screens, and these have a lot of configuration options.
I really wish it was "point an agent at it, and walk away", but many screens ended up being hours of iteration with Fable driving my phone/an emulator to produce an acceptable outcome.
Given that my Pixel 9 Pro has system screens which are still broken under edge to edge, it's not an easy change, and takes up time which could have been going towards feature development.
A tangent, but a big thank you (to you, and all other developers) for supporting older API levels from someone with devices ranging from Android 8.1 (BlackBerry Key2LE, at minSdk 27) to Android 16 (BlackBerry "Q25", at minSdk 36.1) <3
E-waste is awful, as is cutting off old devices. We still backport security fixes to minSdk 21.
To Google's credit, post-21 is a much more pleasant experience and requires very little developer time. API desugaring[0] has worked perfectly, their compatibility classes[1] handle most of the common cases, and there's often very little to actually code[2].
Their emails are confusing, but they came after the alleged violation in private communication, not what you were going from at the time of the alleged violation. If you ignore them momentarily (surely you understand they probably aren't as well-scrutinized by lawyers, which would explain why they appear to mistakenly refer to the tax status of the recipient rather than that of the donation), is anything else actually confusing or inconsistent? Their policies, the relevant laws, and what common sense would have you expect - they seem pretty cut and dried. Are they inconsistent with anything other than their emails, which came after the fact?
From another angle: why/how do you feel the tax-exempt-mess of the recipient itself could sensibly be the determining factor here, rather than the taxability of the transaction itself? Is there any law or precedent or anything outside their emails that would suggests a payment processor should look at the tax status of the recipient rather than that of a transaction?
I don't know every jurisdiction, but that's not the only relevant factor. If they are tax-deductible, they still introduce the need for paperwork etc. for the payment processor to let the payer deduct it from their own income. A 0% tax on some action doesn't imply you don't have to worry about tax law when performing said action.
Though I think you can just read the policy and take it at face value and not even have to know any of this beforehand.
But the complaint isn't that Google won't process the payment. It's that they won't allow them to link to an OpenCollective donation page, and presumably OpenCollective would handle anything like that.
That’s not true. If a donation is tax deductible that’s just between the IRS, the recipient and the donor. The payment processor, banks, etc don’t do anything special.
So I'm only a layperson and don't know what is strictly legally required, but my understanding (based on reading/third-hand information) is that payment processors do in practice end up with more work to do for this, whatever the reason. Quoting from [1]:
> Nonprofits have strict tax regulations when accepting donations. The more a payment processing system can assist with these regulations, the better for you and your donors. For instance, donors need to receive specific documentation for tax-deductible contributions, such as donation receipts. Additionally, different types of donations may involve different tax considerations for the donor and the organization. Nonprofits also have to consider any state and federal regulations regarding their charitable solicitation and fundraising activities, which may vary depending on location and activities.
And there's of course also exemption from sales tax which they have to handle too.
Sure, but that’s still a problem of their own making. These people don’t want to use them to process the payment. They just want to link to their own web page.
The Call of Duty series is one of the worst offenders, effectively every game outside of the last 2 years has so many bad CVEs' and remote code exploits that even opening them on your PC is unsafe. Playing the official matchmaking on even something as recent as Black Ops 3 will have your computer compromised in minutes.
Yet they are still on the store front, they never go on sale. Black Ops 2 has been out for well over a decade and still wants full price for it on Steam & its unsafe.
Playing Call of Duty games on PC is probably the most unsafe thing you can do with your computer, outside of downloading malware itself.
Valve should delist these games from the store if they are effectively unplayable. They should ban Activision from selling new games on the store if they cannot make older titles even remotely safe. It's pure neglect, most of this stuff is fixed by the community with a few lines of code.
There's an arena/research report by Ozzie Kirkby and Andy Matuschak at https://memory-machines.com/ which you might find interesting.
I predict that things will be 'good' within the next 5 years, but your intuition is correct (and the SOTA models are often producing worse prompts than older models).
I tried to play it about two months ago and it pops up a notice and quits. I found on Reddit that the notice is “we are Rory, but servers for this title have been shut down. Thank you very much for playing” which is roughly like what I remember.
According to Wikipedia: “in December 2023, all servers for mirrors edge catalyst were shut down by EA” but that only says online content was disabled.
It’s possible that the game is only unplayable on PlayStation, but still playable (without online features) on PC. But it does seem to still be listed in stores (steam and PlayStation) so I’m not sure exactly what’s going on. I’d have to redownload it to test it again.
We define our API into the Rust via protobufs[0] and some codegen.
The wrapper around these is very lean, FFI-based[1], it's abstracted to a library so Android devs never need to know there's rust/codegen involved.
We then define a light Kotlin-based wrapper around the protobuf-generated API[2]. This is a candidate to move to Kotlin multiplatform in the near future (mostly for test speed improvements).
Love this. Gonna add it to a few of mine that are quasi abandoned because I'm too burned-out to wade back into them in any detail, per one of the categories described in the article.
This seems utterly delusional regarding the state of software engineering. In fact, you could almost build a mapping of billion dollar companies who's entire business model actively works against each one of them.
reply