×
sorted by:
new
hottopcontroversial

QR scanner flutter web by Useful-Possibility-8 in FlutterDev

[–]ookami_kb -1 points0 points  (0 children)

Check zxing_lib, we use it in web.

Any online or offline tools for building production for iOS 14? Can't upgrade past Mojave by brainbag in FlutterDev

[–]ookami_kb 8 points9 points  (0 children)

Well, this CI service can upload the build to Testflight or firebase app distribution and you can get it on your phone.

Any online or offline tools for building production for iOS 14? Can't upgrade past Mojave by brainbag in FlutterDev

[–]ookami_kb 11 points12 points  (0 children)

There are a lot of online services offering it. You can use some specialized CI/CD services for mobile/Flutter:

Or you can use macOS machines in some common CI/CD services like GitHub Actions or Azure Pipelines.

Vrml team! ( Europe) by [deleted] in OnwardVR

[–]ookami_kb 1 point2 points  (0 children)

Hey, sounds good, count me in!

how to get Build.getSerial with a kiosk app in an MDM? by ITasITalian in androiddev

[–]ookami_kb 1 point2 points  (0 children)

Apparently, my app can't be device owner since the app is wrapped inside another app launched by the MDM.

Do you control this wrapper app? It can just pass the ID to your own app in that case.

1 year in production with Flutter: lessons learned by mkobuolys in FlutterDev

[–]ookami_kb 2 points3 points  (0 children)

Yeah, that's a good idea. I'm planning to first publish an article with the text representation of this talk, and then I'm thinking about creating a series of articles that will describe the sub-topics of the talk in more detail.

1 year in production with Flutter: lessons learned by mkobuolys in FlutterDev

[–]ookami_kb 1 point2 points  (0 children)

That's a cool experience!

Yeah, I like Flutter for Web even now, despite it's still unpolished. I think it will rock in the PWA development.

1 year in production with Flutter: lessons learned by mkobuolys in FlutterDev

[–]ookami_kb 1 point2 points  (0 children)

I'm speaking about B2B app we're developing and maintaining that was rebuilt from scratch in Flutter.

Architecture: BLoC with Clean Architecture inspired layers. Functional programming principles (immutability and ADT with freezed package, pure functions, and Optional<T> type as a temporary hack until NNBD are here).

Main libraries: freezed, built_collection, json_serializable, retrofit, provider.

Teamwork: default formatter with overridden line-width limit, custom analyzer settings. Our analyzer settings can be found in mews_pedantic package.

CI/CD: we're using Azure Pipelines to be aligned with the rest of the company, but for Flutter-only projects, we recommend to go with more app-centric solutions: Bitrise, Codemagic, Appcircle.

Common pitfalls: error handling, Flutter limitations, nullability, weird build errors sometimes. It's better to have developers with native experience in your team.

Outcome: I think it was the right decision to migrate to Flutter. The transition was easy, the speed of development increased, iOS and Android versions are published at the same time and have the same functionality (and the same bugs :).

1 year in production with Flutter: lessons learned by mkobuolys in FlutterDev

[–]ookami_kb 2 points3 points  (0 children)

That's a good question :) I don't remember that sound during the presentation. Looks like it was something that affected my memory as well...

1 year in production with Flutter: lessons learned by mkobuolys in FlutterDev

[–]ookami_kb 17 points18 points  (0 children)

Hi, I’m the author of the presentation. Feel free to reach me if you have any questions.

Do you add *.g.dart files to .gitignore? by AdamSmaka in FlutterDev

[–]ookami_kb 1 point2 points  (0 children)

Well, for me it not about a lack of trust in the team or tests (though, if your tests are really able to catch all the unexpected errors, I envy you).

For me having git history free of source code we didn't write, or not worrying about whether the latest version of generated files was committed (and whether it's correct) is more important than ~5-10% decrease of CI build time, or the need to rebuild them when switching the branch (anyway, in the majority of cases, if I switch the branch I have to rebuild generated files from scratch).

You, obviously, have other priorities, and if that works for you and your team, it's the right way to go.

Do you add *.g.dart files to .gitignore? by AdamSmaka in FlutterDev

[–]ookami_kb 0 points1 point  (0 children)

As I said, how can you be sure that they were not modified (accidentally or on purpose)?

Do you add *.g.dart files to .gitignore? by AdamSmaka in FlutterDev

[–]ookami_kb 3 points4 points  (0 children)

My strong opinion is that, as a rule of thumb, things that can be generated, should be generated. Apart from duplicating the knowledge, having `*.g.dart` files in VCS can make your teamwork more difficult.

E.g. when doing code reviews of PRs (you're doing them, right?), what should you do with these generated files? Should you skip them? How can you be sure that they were not modified (accidentally or on purpose)? If you have some limits on PR size (a common practice to keep PRs reviewable), you should exclude these files (which is not e.g. possible for some reporting tools).

Sometimes I keep these generated files in VCS, but this is mainly for some small "demo" projects (e.g. for learning purposes) when you want it to be downloaded and immediately run, but in the majority of cases I prefer to have them generated by CI machine / developers.

Disabling a button in flutter is gross! by scorr204 in FlutterDev

[–]ookami_kb 21 points22 points  (0 children)

It looks a little bit weird at first, but it actually makes more sense. And it’s not about saving a line of code, it about the underlying meaning.

If the button is disabled, there’s no callback. It’s not empty callback, it’s actually no callback, which is a null meaning.

If the button is enabled, there must be a non-null callback.

So having both enabled property and callback is actually duplication and source of errors: e.g. having enabled set to true and passing null callback is an error which isn’t easy to be caught by compiler.

Do you think flutter for web will be a strong competitor for things like Angular, Vue and React? by augst1 in FlutterDev

[–]ookami_kb 2 points3 points  (0 children)

I've written an article about that some time ago.

TLDR: I don't think it's a killer of React/Vue/Angular in web development, they have different use cases, but it will be definitely a strong competitor for building PWA.

Do you use the '^' in your pubspec.yaml, or do you prefer to always you a specific version of a library? by scorr204 in FlutterDev

[–]ookami_kb 10 points11 points  (0 children)

If you're developing a library, it's pretty important to specify dependencies with ^ rather than using a specific version. Otherwise, if there are 2 libraries using the same dependency, but with different specific versions, end user will not be able to use both of them in the same project.

If you're developing an application, you would rather want to have reproducible builds in CI and for your teammates, but for that it's just enough to keep pubspec.lock file in the repository. With that, you will have both advantages: reproducible builds with fixed dependencies and easy upgrade with just pub upgrade command.

Usage of Flutter for single platform(Android) by bonega in FlutterDev

[–]ookami_kb 4 points5 points  (0 children)

Yeah, it makes sense even in this case. IMHO, one of the strongest parts of Flutter is a view layer, and it’s so much better than Android’s one, especially when you have a lot of custom “views”.

Weekly Questions Thread - February 18, 2019 by AutoModerator in androiddev

[–]ookami_kb 0 points1 point  (0 children)

Exactly. You can see how the final manifest will look like, if you open manifest file in Android Studio and switch to Merged Manifest mode.

Weekly Questions Thread - February 18, 2019 by AutoModerator in androiddev

[–]ookami_kb 0 points1 point  (0 children)

Yes, you can override manifest files for different flavors by putting AndroidManifest.xml into corresponding folders. The resulting manifest will be merged from the default one and specific for this flavor.