Re:Flutter – A mobile app SDK for iOS and Android
by skybrian on Saturday August 19, 2017 @12:02PM
(#15054077)
It might be more challenging without native widgets but it looks like it's still going to be implemented:
"Flutter has basic support for accessibility on iOS and Android, though this feature is a work in progress."
https://flutter.io/faq/#how-do-i-do-internationalization-i18...
Re:Flutter – A mobile app SDK for iOS and Android
by LeoNatan25 on Saturday August 19, 2017 @12:22PM
(#15054184)
I don't think this is possible on iOS. I don't think it is currently possible to achieve VoiceOver support, for example.
Re:Flutter – A mobile app SDK for iOS and Android
by eseidelGoogle on Saturday August 19, 2017 @11:07PM
(#15056813)
(Disclaimer: I work on Flutter.) As skybrian says, accessibility support is work-in-progress. But if you try an existing Flutter app (e.g. the official Hamilton App) you'll note that most aspects of the app are accessible to VoiceOver, just not quite everything yet. We're actively working on improving our iOS and Android accessibility integration.
Re:Flutter – A mobile app SDK for iOS and Android
by coldtea on Saturday August 19, 2017 @12:38PM
(#15054261)
If you wrap native widgets it is.
Re:Flutter – A mobile app SDK for iOS and Android
by LeoNatan25 on Saturday August 19, 2017 @01:01PM
(#15054377)
I don't think this is what they are doing, which is what I meant. How are Flutter widgets drawn on the screen?
Re:Flutter – A mobile app SDK for iOS and Android
by sethladd on Sunday August 20, 2017 @01:54PM
(#15059407)
(disclaimer: I work on Flutter.) Flutter uses its own renderer based on Skia. Flutter essentially asks the OS for an surface to draw onto, and then Flutter draws all the pixels through Skia.
Re:Flutter – A mobile app SDK for iOS and Android
by LeoNatan25 on Sunday August 20, 2017 @07:39PM
(#15060838)
In such case, this is what I feared; I don’t think it is possible to implement proper VoiceOver support with the current public API.
You should file bug reports with Apple to enable that.
Re:Flutter – A mobile app SDK for iOS and Android
by andrewljohnson on Saturday August 19, 2017 @12:11PM
(#15054128)
If you write a native app programatically, you replace all your localizable strings with NSLocalizedString(@"string to translate", @"message for translator") - or similar in Swift. There's also support for localizing strings that you supply in your plist config files, which are strings for things like telling a user why you want a certain permission.
If you use a lot of Interface Builder (IB), then your localization support stems from all the basic UIKit widgets having support for localization built into IB, and in that case you'll end up building custom components on top of your UIKit blocks, and localizing via IB.
One of the views in an app I work on (a Settings view) also uses some plists to generate the table, so we end up having a bit of code to generate the NSLocalizedStrings for the stuff that's not actually in the source code.
Isn't there a way to "publish", "expose" say text and other information to the system? I believe for example Windows has this, and Qt on the desktop can use it (although there were still complaints, that some really popular brand of braille reader was not working).
Simply curious, as long time ago I was heavy proponent of native only widgeting systems (like wxWidgets), but lately in favour of self-drawn one, but imitating the interface (like Qt).