Need support for configuring Android's SystemNavigationBar color

App's deployed on Android should be able to request a light or dark navigation bar.

It would probably make sense to expose this via the SystemChrome API although there's no comparable iOS feature that I know of. Currently SystemChrome.setSystemUIOverlayStyle() doesn't do anything on Android (see PlatformPlugin.java in the engine). Not clear if it would make sense for that API to do double-duty, since it means something different on iOS.

Indirectly related 2 cents:

I know this is a side issue and maybe not worth mixing with this ticket, but would it be possible to deprecate the name SystemChrome and whenever a new method is added to do so in a class with a more appropriate name?

BTW I have previously read about setSystemUIOverlayStyle and couldn't figure out what it meant. Until now I had no idea it would have no effect on Android. Is there a way to add something that makes it obvious for the developer that this or that method is not expected to have side effects on a given platform? Something half way between annotation and exception? On one side we could have the setSystemUIOverlayStyle and this candidate function mention it in the docs. On the other hand sometimes someone can autocomplete from the IDE and not even notice it.

As a reference, I love when you're writing native android and have neat sugars such as @UiThread and when accessing some methods it reads your manifest and puts an error because there's a missing permission. That can make a big difference in the future for learning about what to expect of fuchsia for example.

@fmatosqg

@fmatosqg I think SystemChrome is more or less a perfect name, It's the system's chrome after all. That said, I will take a look at the existing documentation and make some improvements.

We don't really use annotations in Flutter as dart AOT cannot make any use of them. In theory it would be possible to add support for the annotations in the dart analyzer, but that is a significant amount of work.

I think there's still room for using annotations during compile but discarding in the AOT. Take as an example some methods introduced in some versions of android. Java discards some annotations after compile time, but it's still enough to FORCE the developer to write statements like this before making possibly forbidden calls:

if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.GINGERBREAD) {
     // call to method introduced in Gingerbread
}

Is that along the lines of what you imagine for the analyzer?

PS: can you elaborate what system's chrome means for you? I have never heard it meaning anything else than the browser, which makes me a bit confused when talking about native apps.

PS: I am absolutely no expert in either compilers or analyzers, but as a long time static language user I feel too much is delegated to the analyzer. I'm trying to understand a different point of view, but I'd rather have a very strict compiler that refuses to make AOT builds than dive into crashlytics. All things in their due time, but my struggle is understanding what's the general desired direction, which sometimes can be different than the actual taken direction.

Chrome is a design term for the non-content parts of the user interface which are controlled by the system, see this interesting quora answer.

Anyway, the analyzer is static analysis - It parses your program and resolves the types, it just doesn't generate any code. The Dart compiler already rejects invalid programs, including those with type errors since Dart 2. However, static analysis is not capable of detecting all kinds of errors, whether in Dart, Java, Rust, Go, et cetera.

If you have specific examples of code you would like to disallow, we can talk adding lints/analysis options. As an example of what is possible, we could prevent you from naming methods starting with a x (bad example).

class Foo {
  void xBar(); // error!
}

But we couldn't annotate something so that it statically rejected odd numbers.

@noOdd
void foo(int x) { ... }

foo(3); // ???

The former only needs to read the declaration names, the latter requires a running program (hence not static).

As an aside, the example you've chosen is certainly useful for Java, but ideally we would just never need something like that in Flutter!

This thread covers multiple things that could probably be split into multiple issues in possibly multiple repos (analyzer or compiler, flutter/flutter or flutter/intellij etc), but since for completeness and trying to stay on focus I'll try to stay on topic.

This is a subset of my wishlist, on how I think things should be to avoid runtime surprises at the expense of being forced to address problems before flutter build has the chance of succeeding:

Some analyzer errors should be encouraged over warnings (most things should be opt-out) such as missing_required_param, missing_return implicit-dynamic and implicit-casts, specially in packages who trickle down to new app writers who have no clue why their Dart 2.0 projects are failing
Analyzer errors should block flutter build from succeeding in a very easy way, opt-out
SystemChrome.setSystemUIOverlayStyle() should not be allowed to be called without being wrapped in some form of if ( TargetPlatform.isFuchsia ) and that needs to be done by the app developer who should be aware that there's no side effect on Android. The same would extend to the method created under this ticket in SystemChrome. Not doing it would cause AOT compiler to not succeeed. Special mention to the permission toggling methods when using iPhone who are so limited compared to Android, and there's many people who will make mistakes unless flutter tools nudge them.
JIT could use some assistance as well, the trending example is MethodChannel.invoke but there are community written things who are creating problems now that Dart 2.0 is rolling in by default. Upgrading a package for 2.0 compliance with the encouraged practice now involves either 100% unit test coverage or 100% example app coverage
And I think Android annotations are a big productivity enablers, so why not? Things like @StringRes or @DrawableRes are big helpers not only to break the compiler but as well as document things for the next developer. @Nullable, flutter's own @mustCallSuper and many more https://developer.android.com/studio/write/annotations#call-super.
An example of something very much like that trickles down from using a native BLE method not available before Android API 19, which would consequently be worthless in Dart code that runs in a Jelly Bean phone. So I think Dart still needs some form of if (Target is Android && Android > API 19) { } else { }.

I don't mean to pretend those things are easy or possible, or come without creating other problems, or even that I'm having the best ideas possible.

I think my point is that there's a steep learning curve for different people for different reasons, and I personally miss a lot of sugar.

I think a flag/setting to block builds when there are analyzer errors sounds reasonable, provided that it was opt-in for the sake of backwards compatibility. could you open a separate bug for this?

Dart 2.0 changes are definitely causing some churn, but I think it is something that will stabilize once 2.0 is officially launched. Again, please feel free to file issues if you disagree or have specific suggestions.

Adding annotations is a solution to something, what specific problems are you thinking of? It might end up that the solution is a lint/annotation or possibly a documentation change. @nullable, though, I agree that would be very useful. The Language having a concept of nullability is probably better though. This is asked for a lot so I'm pretty sure the Dart team is aware of it post 2.0.

In general, we're not going to expose platform-specific APIs in Flutter. Version issues should be handled in plugin code.

I'm marking this as fixed by #17171. Technically there are some new features introduced by P, but that hasn't released yet :3

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

Navigation Menu

Repository navigation

Need support for configuring Android's SystemNavigationBar color #16837

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Need support for configuring Android's SystemNavigationBar color #16837

Description

Activity

fmatosqg commented on Apr 21, 2018

jonahwilliams commented on Apr 27, 2018

fmatosqg commented on Apr 28, 2018

jonahwilliams commented on Apr 28, 2018

fmatosqg commented on Apr 30, 2018

jonahwilliams commented on Apr 30, 2018

jonahwilliams commented on Jul 14, 2018

github-actions commented on Sep 2, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions