I was curios what does the code do and asked ChatGPT.
Summary of Functionality:
• This code seems to perform a sequence of loading data from memory into registers, performing bit tests, comparisons, and conditional branching based on the results of these tests.
• It appears to be part of a loop or some repeated operation, as there are multiple backward branches that seem to control a flow of tests and memory manipulations.
Do yourself a favour -- develop an intuition for this sort of code rather than reaching for GPT. It basically gave you what you should be able to read in a first pass, and a you can probably reduce the algorithm to some C-like code with a few manual passes in notepad or textedit.
I'm on mobile but my guess would be an init function waiting for hardware to be ready based on the looping and bit testing, and the context of the page itself.
Not sure if many others made the same assumption, but that landing page feels to me like it should have a more obvious way to feed into the text-based content.
I'm always concerned that accessibility is being left behind. Android and iOS both put great efforts into making their UI accessible, why do the work again? Chances are that the accessibility of those third-party components will be worse or maybe doesn't even work at all.
The problem is that the accessibility work already needs to be done on every platform (for now we have two really popular ones but nobody can be sure what the future brings).
Also, if you could just recompile your app for a new platform and release (more or less), it would remove the biggest barrier to entry for possible new platforms: Adoption.
That's not what I meant. Android and iOS already have their own widgets with accessibility features in place. iOS even better than Android. It took years for them to develop to where they are now.
Now Flutter is making its own widgets that look and handle like the corresponding native widgets. So they need to implement accessibility all over again in the same way that is already present on the platforms. Google is thus redoing all the work they already did in Android.
A lesson from modern software development is that software is developed incrementally and because accessibility is never high on those priority lists, it will lack in quality at first and take multiple iterations to get up to the same level as the native accessibility of the OS, if it even gets there in the first place.
I love Flutter, and how it looks, but while I was at the Google I/O Extended I was given an Android Things Kit. That specific version of the kit did not had GPU, and later (at home) when I tried Flutter - it was running very slow, while other android apps were manageable.
Then again, this is more of an outlier (today) with the GPU present almost on any mobile device, but still something to know about (e.g. flutter won't be of good use there).
A GPU is possibly more energy efficient given a much more complex scene, animation, effects, etc. than what you would draw with CPU, and much faster. But in case there is no GPU, one must definitely go without any complexities, heavy draw calls, etc. Kind of obvious, but may get forgotten. I certainly don't know what's best in this case, unless I have some time on my own to experiment and see. One reason custom, but fixed hardware tends to get better software over the time, is that developers learn how to use it best (for example: game consoles/systems/arcades, classic computers... whether they have GPU, or not (in the distant past)).
> In other words, in today’s market, a branded, custom UI is king.
Does a custom UI per app not make it more difficult for people to learn each new app? Didn't the platform developers write their human interface guidelines for a reason? Or was that level of consistency only necessary in the early days of Mac and Windows, when the temptation was to port a DOS app straight over rather than redesigning it as a GUI?
Platforms also like their branded, custom UIs. When you build an app that uses the platforms widgets, you reinforce the platform's brand. When you use the same look everywhere, on the web and for apps on each platform, you reinforce your own brand.
If platform developers cared so much about consistency, they wouldn't change their UI design just to freshen up their image or because design trends have changed. Maybe looking and behaving like everyone else really has a major influence on user adoption, but it usually seems to be ignored in favor of branding.
For mobile platforms, is there such a thing as timeless, classic UI design that won't look dated next year, but doesn't require every app developer to create their own brand?
Not using OEM widgets has huge advantages too though - easier portability, you can preview any OS style on any device (e.g. develop an iPhone app even if you don't have an iPhone), you don't rely on the underlying platform as much (e.g. if maybe that platform doesn't get updated very reliably!).
Really the only downside is that it is a ton of work to make it match the look of the native widgets. They've done a good job though. I really doubt 99% of people could tell at all.
Dart is ok. Better than Java or Javascript at any rate!
It’s true it’s very difficult to completely replicate the look and feel of a native toolkit with something like this.
However, my experience has been that most people want a heavily customized and styled UI that looks similar on both iOS and Android because a generic stock UI doesn’t have enough visual bling to attract users or establish a strong brand. And it looks like doing that kind of customization should be a lot easier with Flutter than it is with either native platform’s native APIs.
