alexhayes
Atomic is a second generation architecture that features hot-reloading native clients with a generic actions system that allows the entire UI to be defined on the server while maintaining a super dynamic, native UI.
You can build very simple things or you can also build very complex things like native, realtime messaging (which we've done and exists in production).
There's an accompanying video (down the bottom) which hopefully gives you a fairly good idea of the features :)
Some context - https://github.com/MobileNativeFoundation/discussions/discus...
(Edit to add context)
For example, asking for specific albums and it will play someone's playlist of the album - in terrible quality because someone uploaded it as a video to YouTube I think part of the problem is that the music catalogue is so poorly maintained/governed on YouTube Music. For example there are many songs that state they are by Little Richard that are actually other artists' songs
And now because of that it seems HN is also hurting.
I'm sorry internet.
It seems like a great way for Apple to hoover up a heap information they probably don't need.
I also wonder how they are going to combat bounces and send back a usable error message. While they can perhaps do useful things with say a mailbox full bounce they are probably going to have to hide or at least obfuscate some other kinds of bounces.
I don't think the author correctly represents this functionality in flutter.
I've found the debugging of flutter apps inside Android Studio to be excellent! You add a break point (by clicking on the lane to the left of your code or hitting some keyboard shortcut) and execution will be stopped and you can step through etc etc..
Using print statements to debug is slow and cumbersome, debugging in flutter is not.
Peeking Under the Flutter Covers
However I imagine it's probably a good way to get people to stay up to date with the latest OS: "Oh, I want that shiny new app, I must update"
Thank you for staying the course and believing! What an EPIC effort!!!
I kind of think of the relationship as a pointer into what should be a entirely separately managed project. Changes to that project should happen in that project and only then should the "pointer" be modified. I usually go as far as checking out the submodule separately (to my "projects" directory) when I need to work on it, which of course entirely unnecessary, but for me helps keep that separation.
Another approach I've found that helps to combat issues some people have with them is to not have them littered throughout a project but have a very clear delineation between what are submodule and "root" project git managed files - ie. an appropriately named, usually top level, directory.
In practice I find them an extremely useful way of getting stuff done effectively and efficiently!
There's also a wealth of resource in the docs!
Rather than say "well, I just failed to pay money I don't have" you can just say "oh no, it's cool, I'm just downloading it"
Honestly this is a complex problem area and I think the Celery developers have done an excellent job of making it pretty trivial to get up and running while providing lots of flexibility for more advanced users! Not an easy feat.
Are there bugs? Of course - but I've never come up against one that I can't work around. Is that annoying? Sometimes but that's software development.
I agree with the enabled on-demand comment however.