On Android, push notifications are handled by a service defined in your application's manifest. The system launches the service when a notification is received, and calls its onMessageReceived() function which you customize to display the notification's layout, add actions to tap events, etc.
It is counterintuitive, feels arbitrary, and logical thinking will cause you to misread the chart they provide. Whether that method is called is based on the payload of the notification as well as making sure you've properly registered the types of notifications. This is helpfully spread between Android docs and the Firebase docs. The exact differences between the notifications that will trigger this (while still being compatible with iOS) is left as an exercise to the reader.
It's not that bad if you completely ignore Firebase and override onHandleIntent. Now you can choose what to do with the message without caring about the difference between "data" and "notification" messages or whether your app is in the foreground.
Can you elaborate on this a bit? Is it possible to use a non-Firebase push notification service on Android, that properly works in the background? Our the app still needs to use FCM but you can override the client-side handler somehow?
Both are possible. The source code to the Firebase push messaging service is available on Maven and GitHub, so you can re-implement it. Otherwise, you subclass the same service but override `onHandleIntent` instead of `onMessageReceived`, and avoid the code path that immediately displays the notification for 'notification' messages when the app is in the background.
> • Enable additional protection. Some apps, such as Venmo, PayPal and Cash App, let you add a passcode. Just don’t use the same one as your iPhone.
> You can also set up a Screen Time passcode for yourself, then enable account restrictions to prevent an Apple ID password change, the way parents do with their kids’ devices. In Settings, go to Screen Time > Content & Privacy Restrictions, then toggle Content & Privacy Restrictions on. If you haven’t already set up Screen Time, you’ll need to choose a passcode. (Again, make it different from your iPhone’s.)
> Scroll down to the Allow Changes section, and where it says Account Changes, select Don’t Allow. Whenever you need to access your iCloud account settings, you’ll have to go to Screen Time and re-enable this.
Abstract: Structure editors designed for keyboard input often struggle to resolve the tension between maintaining hierarchical term structure and offering efficient linear editing affordances. Contemporary designs either compromise structure by deferring to text near the leaves or else maintain structure by permitting only edits that transform the selected term. However, visually adjacent sequences (e.g. of operators, operands, and individual delimiters) do not always cleave cleanly to term boundaries, so even experienced users report difficulties with selection and code restructuring tasks. We propose a novel approach to structure editing, tile-based editing, that maintains term structure while offering linear selection and modification affordances. The idea is to allow disassembly of terms into linearly sequenced tiles and shards around user selections, while guiding the user through restructuring actions and automatically inserting holes in a manner that ensures reassembly into a term. This paper introduces tylr, a tiny tile-based editor designed primarily to highlight this uniquely flexible set of affordances. We evaluated tylr with a lab study where participants performed simple code transcription and modification tasks using tylr as well as a text editor and a structure editor built on JetBrains MPS, a state-of-the-art keyboard-driven structure editor generator. Our results indicate that participants frequently made use of tylr’s selection expressivity, and that this flexibility helped them complete some modification tasks significantly more quickly than with the MPS editor. We further observed that a few participants completed some tasks more quickly using tylr than with text, but were in general slowed by a number of limitations in our current design and implementation. We discuss these limitations and suggest future research and design directions aiming toward more flexible structure editing interfaces.
I've run a single-user pleroma server since January 2019. I ran it on a digitalocean droplet with 2 GB RAM, and then an AWS instance (t3.small, also 2 GB) for the better part of two years; I recently switched to a t3.medium. Beam's current process size: 250MB resident, uses 5-7% CPU.
I discard remote posts after 120 days, and my database (using PostgreSQL 15, no RUM indexes) takes up just over 5.4 GB (as reported by `pg_database_size`). It's grown a lot faster in the past couple of weeks. I follow 245 accounts.
Very cool. While obviously not ideal, the results are probably accurate within a small factor. Unfortunately there's no assembly version for 65C02 but Z80 does surprisingly well in this test.
I muse what could be done with modern cross-compiler (SAT solving for optional code sequences?) A llvm backend for Z80 has recently kicked back into gear: https://github.com/jacobly0/llvm-project
I ran the C version of this benchmark using llvm-mos's Clang for the 6502. The results:
21.4 seconds
5793 bytes
Which is middle of thepack for the Z80 benchmarks, but well below the 6502 ones. We're also using a slightly tweaked embedded printf written in C, so this could probably be improved somewhat there, sans any compiler changes.
