my app user base is of an older age group and I'm having some issues when they have increased the screen size via accessibility options.
I'm going to guess Apple doesn't allow you to override this in your app? I'd rather them squint than think the app is useless because a 1/4 of the UI is off screen!
Failing that is there a way to detect it and at least pop a dialog to warn them?
Using Flutter.
You can override default system scaling if you absolutely have to via:
return MaterialApp(
builder: (context, child) => MediaQuery(
// or whatever `textScaleFactor` you want
data: MediaQuery.of(context).copyWith(textScaleFactor: 1.0)
child: child ?? SizedBox.shrink(),
),
// ... the rest of your MaterialApp setup
);
... but you shouldn't, ESPECIALLY given your target audience are visually impaired and you should instead be fixing your app and accommodating responsive UI to handle such use cases.
This is an "Accessibility" (a11y) topic.
Indeed, you can't override screen zoom settings in Apple devices. You can override some settings for Android though (through MediaQuery you should be able to set textScaleFactor).
But this makes sense: we can't just ignore the needs of visually impaired users. We should build apps and UIs that react to such settings without overflowing, even though the Layout worsen a bit.
When it comes to a11y, you don't necessarily need to re-think the whole layout as responsive (Layout Builders, etc.), but you should make your text containers flexible. For example, say you have:
Row(
children: [
Text("Hello a11y!"),
],
),
then, you should consider wrapping your Text in a Flexible container to avoid Overflow (so that your text can go down to a new line).
Related
I would like to add transparency to iOS widget, but it looks like it is not supported by default.
Most widgets are non transparent, but I have an example of transparent one.
That's why I ask you about any tips on how to implement such feature for widgets.
Thanks in advance!
Short answer is you can't (as of iOS 14.5).
Most "pseudo-transparent" non-Apple widgets involve asking the user for the wallpaper they're using, then cropping it accordingly and using the result as a widget's background, creating an illusion of transparency at that exact widget position. This can (and will) break parallax and other such effects.
That is if we're talking WidgetKit, of course; legacy Today widgets may give you a bit more freedom, although you likely won't achieve full transparency without hacks like above.
Vym is right. We just developed a widget app that can implement such a pseudo-transparent effect.
Hoping this might help others who want to achieve such effect.
Here is how:
Guide the user to take a screenshot(with current wallpaper) on a blank home screen, and save it.
Tell the user to provide the widget with the widget position. This can be done via the Siri Intents Extension.
public enum WidgetCropPosition: Int {
case smallTopLeft
case smallTopRight
case smallCenterLeft
case smallCenterRight
case smallBottomLeft
case smallBottomRight
case mediumTop
case mediumCenter
case mediumBottom
case largeTop
case largeBottom
}
Crop the saved wallpaper according to the widget position.
The pain point here is the widget of the same position does don't have the same frame location on different devices. You have to do a lookup the table to find the correct position.
This is a Swift Package that helps to crop the correct frame on different iOS devices.Translucent
I am using awesome window manager (new to it). The normal keybinding for changing size for the window in tiling mode is Super+h & Super+L but it only resizes the terminal window (I am using alacrity & it is resizing that), but if I try to resize another window instance firefox, it is not resizing that. Any solution will be appreciated
I'd recommend https://github.com/lcpz/awesome-copycats for newcomers. Also this is a related question: What is incwfact and setwfact of awesome.client
Basically what you need is hidden in this documentation page:
https://awesomewm.org/doc/api/classes/tag.html
incmwfact: Increase master width factor
And here: https://awesomewm.org/doc/api/classes/client.html
incwfact: Change window factor of a client.
Example from my config:
K.win is the Mod4 Key which is the windows key on my keyboard.
I'm "expanding" the current window (client) to the location indicated by the arrow key. Actually I'd need some extra code for up/down to work correctly in all cases but I rarely have vertically stacked windows.
awful.key(
{K.win},
"Right",
function()
awful.tag.incmwfact(0.05)
end,
),
awful.key(
{K.win},
"Left",
function()
awful.tag.incmwfact(-0.05)
end,
),
awful.key(
{K.win},
"Down",
function()
awful.client.incwfact(-0.05)
end,
),
awful.key(
{K.win},
"Up",
function()
awful.client.incwfact(0.05)
end,
),
First I want to talk about what I exactly did on Android, and I am now trying to do the same on IOS :
I developed a library on Android which contains an activity, in that activity we have several type of views (labels, buttons ... etc).
These views are used as an entry point/inputs for my library that provides some services to other apps.
To be able to match the general style of the user app, I created my own View Classes, the user(of my library) needs to provide a style id to the activity before launching it, so it can be used when constructing the View.
Doing so, we are able to maintain the style of the app without the need to re-implement the views for every app that uses my library or making the user(final user on physical device) feels as if he just moved out to another app.
I am really a newbie on iOS and I recently started to learn it so i am not sure how to do it, can you please provide me some guidelines please?
On iOS there are so many ways to create views (xibs, Storyboards , SwiftUI, and programatically). I am not really sure where to start.
He's a sample of my code on Android :
class MyView(val context: Context, val themeId: Int) : View(context) {
init {
val wrappedContext = ContextThemeWrapper(context, themeId)
val mInflater = wrappedContext.getSystemService(Context.LAYOUT_INFLATER_SERVICE) as LayoutInflater
mInflater.inflate(R.layout.my_view_layout, this, true)
}
}
This is a very broad question, but the short answer is "sure, it can be done."
I suppose a quick example might be:
I have a custom UIView with a UILabel centered in it, with 20-pts padding on all 4 sides.
I have 4 "themes" defined, defining the view's background color, the label's text color and the label's font style.
I write a custom init func to accept an Int "id" of 1 through 4
The library user could then instantiate it along the lines of let myView = MyView(with themeId: 2)
As this is a very broad question (topic), once you start developing your custom view you could come back if you run into specific coding questions.
Using capacitor to build an app in ios. In ios the webview covers the whole screen, for iphone-x that means the notch will be included and content will go behind it, like the picture on the right. But i want the picture on the left, black bars on 'no go areas'.
The expected solution (html/css) for this would be to set correct viewport and use the 'safe-area'insert-?', se: https://css-tricks.com/the-notch-and-css/
But for the webview in ios the 'safe-area'insert' will always be 0, that is how it works => this solution is useless.
How can i solve this? Can i change the webview to not cover the whole screen, without changing in the capacitor-framework?
You can use a compatible Cordova plugin cordova-plugin-safearea
npm i -D cordova-plugin-safearea
npx cap sync
With this installed, you can request the safe margin area over the cordova/capacitor bridge:
// Types for clarity
type SafeArea = {
top: string,
bottom: string,
}
window.plugins.safearea.get(
(result: SafeArea) => {
// elegantly set the result somewhere in app state
},
(error: any) => {
// maybe set some sensible fallbacks?
}
);
You could use these values to specify extra padding on the body, or on your header / bottom-menu components
The docs say it returns the values as Numbers, but it seems to me they are actually strings (consider parseFloat before doing math with them).
I have just implemented this in React (running the getter in React.useLayoutEffect); the project is wrapped in Capacitor and have tested on two iOS devices with different ingenious Apple notch screen formats (iPhone 8 and iPhone 11 Pro).
Refer to the documentation for more at https://github.com/rickgbw/cordova-plugin-safearea
There is a CSS variable preset by capacitor you can use to set the padding or a margin for example.
html {
--ion-safe-area-top: env(safe-area-inset-top);
--ion-safe-area-bottom: env(safe-area-inset-bottom);
--ion-safe-area-left: env(safe-area-inset-left);
--ion-safe-area-right: env(safe-area-inset-right);
}
Does anybody know how to draw immediate mode graphics into a xamarin.forms view?
I need to draw some app specific graphics into a form. I've been googling and looking at examples for a lot of the day. I know about Renderers. I can almost do it, but ViewRenderer can't be easily subclassed (unless I'm missing something), and I can't find an existing view subclass that is suitable.
Sometimes my own stupidity and thickness surprises even me.
The answer is to create a concrete, OS-dependent View for each platform. Then create a ViewRenderer implementation for each platform.
The platform-specific ViewRenderer<...> then instantiates the platform-specific view. And we're off to the races.
There are minor details, such as how to communicate or acquire view size and parentage, but at least those are known problems.
So, you have the following components:
A MyXamarinFormsView, which sub-classes Xamarin.Forms.View. MyView doesn't actually have to contain any significant logic. Think of it as a placeholder.
For each platform:
A MyXamarinFormsViewRenderer : ViewRenderer<MyXamarinFormsView, MyPlatformSpecificView>
Add the following attribute instance to each ViewRenderer, after any using statements and before the namespace declaration (if there is one):
[assembly:ExportRenderer( typeof( MyXamarinFormsView ), typeof( MyXamarinFormsViewRenderer ) ) ]
A MyPlatformSpecificView : platform-specific View (e.g. UIView for iOS)
Put the graphics-specific code in each platform-specific view subclass.
I'm not certain if this is the official/correct way of doing it, but it does appear to work for me.