Flutter’s flexibility, pre-built widget catalog, and robust animation capabilities allowed the L+R team to implement a design-led development process. When using Flutter, our developers have a blank canvas to bring custom designs to life. For L+R, this means our design teams can unleash their creativity to create user-centric apps that look and feel great.

Here are a few screenshots from the Global Citizen app:

The design process

When starting a new client project, the designers first create a design system in Figma. This consists of brand guidelines — like color palettes and typography — and small reusable components.

When starting on the Global Citizen app rewrite, the design team expanded upon the existing guidelines to provide a fresh look with higher-contrast elements. Not only does this help to direct the user’s attention but it also improves accessibility.

UI elements are created as components in Figma. Each component may have different variants depending on component type or state. For example, the following diagram shows several button variants:

When developing new components, the design team referenced the Material and iOS design kits in Figma for inspiration. This helps with translating the design to code as these Figma components closely correspond to widgets available in the Material and Cupertino libraries.

Throughout the design process, the team composed the small, reusable components to form larger feature-specific components that were then combined into entire pages. This empowered Global Citizen’s product team to expand the app with new functionality while remaining true and consistent with the original vision.

Project template

At L+R, our team has been working with Flutter since its first public release. To make building Flutter apps fast and easy for our team, we’ve created an open-source repository that serves as a project template and provides the cornerstone for all Flutter apps that we build.

This barebones project contains a set of widgets that can be customized and used in our client’s applications. For example, the buttons represented in the Figma design file (shown above) can be built using the _BaseButton class from the project template. This class accepts different colors, text styles, and padding to best match the design system set for that project.

,

To make it easy to style these components based on the brand guidelines, we use the ThemeData class. Developers take the color schemes and text styles from Figma and map them to the corresponding theme properties.

Our team leveraged the existing properties in ThemeData as much as possible, and then used the ThemeExtension functionality to complete the remaining configurations.

Flutter’s widget library

As mentioned above, the project template contains a set of reusable widgets. When developing these, we try to use pre-existing widgets from the Material and Cupertino libraries as much as possible. In the Global Citizen app, about half of the components descend from Material or Cupertino widgets.

For example, the TextField and TextFormField widgets from Material contained all the necessary customizations and functionality needed to match the designs. The TextButton from Material was also used to implement the _BaseButton widget. In this case, we took advantage of TextButton’s existing highlight functionality, but we wrapped it into a new widget with extended functionality to better suit our needs.

Having these out-of-the-box UI components that can easily be styled makes it easier to build and maintain our widgets. However, sometimes our designers create custom components that can’t be recreated using Flutter’s Material or Cupertino widgets. In these cases, the development team creates our own custom widgets from low-level Flutter widgets.

One example from the Global Citizen app was progress indicators. For this app, our designers created a custom progress indicator as shown in the following GIF. The existing Material and Cupertino progress indicators didn’t work for this design. However, it was easy for our developers to create an entirely new widget using only containers, rows, and columns with intrinsic animations.

Community libraries were also incredibly useful for more complex and flexible components. For example we used a community- built flushbar to display alert notifications inside the Global Citizen app.

Hot reload

When translating the Figma design to Flutter code, it’s important for designers and developers to collaborate. Designers often have feedback that results in small tweaks to styles, layouts, or animations. Hot reload made this collaboration much more efficient.

With hot reload, developers can tweak the code while screen-sharing with the design team (either during the UX phase, UI concept phase, front-end implementation stage, or even the design-QA stage). While screen sharing, the designer can instantly see the results of changes. This makes debugging and iteration much faster.

Smooth animations

One thing that helps an app feel polished is adding thoughtful animations. Flutter’s animation framework is flexible and powerful, however it can be difficult for designers to understand. One thing that helped our team was to reference beautiful animations in open source apps. Specifically, we looked at the codebase for the Wonderous app. We’ve since leveraged the open-source library, flutter_animate, that powers Wonderous to add simple yet enriching animations to key functionalities.

The video in the following link highlights part of the “Take Action” flow, where the user navigates through a series of informative screens to learn more about the issue.

Check out the action_learn_animations video.

Using flutter_animate, we were able to do the following:

• Animate the step indicator as the user moves forward
• Add a slight fade transition between pages
• Transform the Play Video button into a success checkmark after viewing the video

Overall, Flutter allows a flexible approach to design and development. Flutter’s pre-built widgets make it easier to create reusable UI components that can be styled to match a customer’s branding. The Flutter community plays an important role in how the technology matures, offering high quality libraries and expanding the available resources. Key Flutter features like hot reload supports better collaboration between designers and developers. All of these put together result in an app that is both beautiful and functional!

For more information about the app, check out The New Global Citizen App: Daily Activism & Measurable Impact in Your Pocket. You can also download the Global Citizen app to your mobile device.

L+R is an international strategy, design, and mobile technology studio. We offer many services like UX design, mobile development and strategy consulting.

How Flutter facilitates collaboration between designers and developers at L+R was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

Revolutionizing App Development with the Gemini API, Impeller Updates, and Windows Arm64 Support

Today we present you with a new Flutter release, Flutter 3.19. This release brings a new Dart SDK for Gemini, a widget enabling developers to add fine-grained control to widget animations, a rendering boost with updates to Impeller, tooling to help implement deep links, Windows Arm64 support and so much more!

The Flutter community continues to impress, merging 1429 pull requests by 168 community members, with 43 community members committing their first Flutter pull requests!

Keep reading to learn about all the new additions and improvements the Flutter community has contributed to this latest release!

AI integration

Gemini Google AI Dart SDK beta release

The Google AI Dart SDK has been released to beta. This enables you to build generative AI features into your Dart or Flutter app, powered by Gemini, Google’s latest family of AI models. There is now a google_generative_ai package on pub.dev. Learn more about how to build with the Google AI Dart SDK in this blog post or jump straight into the Dart quickstart.

Framework

Scrolling improvements

Flutter used to scroll twice as fast if you dragged two fingers. You can now configure the default ScrollBehavior with MultiTouchDragStrategy.latestPointer to get number-of-fingers-agnostic scrolling behavior. For more information on this change, see the migration guide.

We also completed bug fixes for SingleChildScrollView and ReorderableList, resolving a number of reported crashes and unexpected behavior.

In two dimensional scrolling, we resolved an issue so now, if you drag or tap while a scroll is underway in either direction, the scroll activity stops as expected.

The TableView widget in the two_dimensional_scrollables package has also been updated since the last release, providing more polish, adding support for merged cells, and adopting more of the new features of the 2D foundation after the last stable release of 3.16.

AnimationStyle

Thanks to a contribution by Flutter community member @TahaTesser, Flutter has a new AnimationStyle widget that allows users to override the default animation behavior in widgets, such as MaterialApp, ExpansionTile, and PopupMenuButton, providing developers with the ability to override animation curves and durations.

SegmentedButton.styleFrom

Flutter community member @AcarFurkan added a styleFrom static utility method, just like the ones provided by the other button types. This method enables quickly creating a SegmentedButton’s ButtonStyle that can be shared with other segmented buttons or used to configure the app’s SegmentedButtonTheme.

Adaptive Switch

This adaptive component looks and feels native on macOS and iOS and has the Material Design look and feel elsewhere. It does not depend on the Cupertino library so its API is exactly the same on all platforms.

See the adaptive switch pull request and the live example on the Switch.adaptive constructor API page.

SemanticsProperties accessibility identifier

A new accessibility identifier in SemanticsProperties provides an identifier for the semantic node in the native accessibility hierarchy. On Android, it appears in the accessibility hierarchy as resource-id. On iOS, this sets UIAccessibilityElement.accessibilityIdentifier. We want to thank community member @bartekpacia for this change, which spanned the engine and framework.

Increased access to text widget state

We added support for a MaterialStatesController in TextField and TextFormField so that you can listen to MaterialState changes.

UndoHistory stack

We fixed a problem where the undo/redo history could disappear on Japanese keyboards. You can now modify an entry before it’s pushed to the UndoHistory stack.

Engine

Impeller progress

Android OpenGL preview

In the 3.16 stable release, we invited users to try out Impeller on Vulkan-enabled Android devices, covering 77% of Android devices in the field. Over the past few months, we have brought Impeller’s OpenGL backend up to feature parity with the Vulkan backend, for example, by adding support for MSAA. This means that Flutter apps on nearly all Android devices are expected to render correctly, with the exception of a small number of remaining features that are coming soon, such as custom shaders and full support for external textures.

We request that Flutter developers upgrade to the latest stable version, and file issues about any shortcomings observed when Impeller is enabled. Feedback at this stage is invaluable to ensuring that Impeller is successful on Android and that we can confidently make it the default renderer in a release later this year. The Android hardware ecosystem is much more diverse than the iOS ecosystem. For that reason, the most helpful feedback about Impeller should include detailed information about the specific device and Android version where issues occurred.

Further, as a reminder, Impeller’s Vulkan backend enables additional debugging capabilities in debug builds beyond what is used with Skia, and these capabilities have additional runtime overhead. Therefore, it’s important to give feedback about Impeller’s performance from a profile or release build. The bug report should include timelines from DevTools and a comparison with the Skia backend on the same device. Finally, as always, we are very grateful for feedback that includes a small reproducible test case that demonstrates the issue.

Roadmap

After rendering fidelity, our main focus in Impeller’s Android preview period is performance. We continue to make incremental gains, however a couple of larger improvements are also in progress. We expect work to take advantage of Vulkan subpasses to greatly improve the performance of advanced blend modes. Further, we also expect that a change in rendering strategy away from always tessellating every path on the CPU towards a Stencil-then-cover approach will greatly reduce Impeller’s CPU utilization on both Android and iOS. Finally, we expect that a new implementation of Gaussian blurring will match the throughput of the Skia implementation, and improve idiomatic use of blurring on iOS.

API improvements

Glyph Information

This release includes two new methods on dart:ui’s Paragraph object: getClosestGlyphInfoForOffset, and getGlyphInfoAt, which each return an object of the new type GlyphInfo. Check out the documentation on the new GlyphInfo type.

GPU tracing

Under Impeller on Metal (iOS, macOS, Simulator) and on Vulkan-enabled Android devices, the Flutter engine now reports GPU times for each frame in the timeline in debug and profile builds. GPU frame timing can be inspected in DevTools under the “GPUTracer” heading.

Please note that since non-Vulkan Android devices might misreport their support for querying GPU timing, Impeller’s GPU tracing can only be enabled with a flag set in the AndroidManifest.xml file on these devices.

<meta-data
  android:name="io.flutter.embedding.android.EnableOpenGLGPUTracing"
  android:value="true" />

Performance optimizations

Specialization constants

The team added support for specialization constants to Impeller. Taking advantage of this feature in Impeller’s shaders reduced uncompressed binary size of the Flutter engine by nearly 350KB.

Backdrop filter speedups

There is much more work to do, however this release includes a couple of nice performance improvements for backdrop filters and blurs on Impeller. In particular, open source contributor @knopp noticed that Impeller was mistakenly requesting the capability to read from the onscreen texture. Removing this capability improved scenes that include multiple backdrop filters anywhere from 20–70% in our benchmarks, depending on complexity.

Further, Impeller no longer unconditionally stores the stencil buffer on every backdrop filter. Instead, any clip affecting operations are recorded, and replayed into a new stencil buffer when restoring the save layer for the backdrop filter.

With this change, our benchmark of animated advanced blend modes on a Pixel 7 Pro running Impeller with the Vulkan backend improved average GPU frame times from 55ms to 16ms, and improved 90%-ile raster thread CPU times from around 110ms down to 22ms.

Android

Deeplinking web validator

We have learned from developers that deep linking (taking users from a web URL to a specific page in a mobile app) has always been difficult to implement, and also error prone. So we first created a validation tool to help developers understand what links are incorrectly configured, and provide implementation guidance. We are very happy to share that an early version of the Flutter deeplink validator is now available!

In this early version, the Flutter deep link validator supports web check on Android, which means validating the setup of your assetlinks.json file. You can open DevTools, click into the Deep Links tab, and import a Flutter project that contains deeplinks. The deeplinking validator tells you if your web file is configured correctly. You can refer to the deep link validation tool testing instructions for more information.

We hope this tool is the first step to simplify your deep linking implementation journey. We will continue to work on providing future support for web check on iOS, and app check on both iOS and Android!

Support for Share.invoke

The default Share button on text fields and views was previously missing from Android, but we’ve added it in this release as part of our ongoing effort to ensure all the default context menu buttons are available on each platform. You can follow that ongoing work in PR #107578.

Native assets feature

If you’re interested in the interoperability of Flutter with functions from other languages in your Flutter code, you can now perform FFI calls through Native assets on Android as part of our ongoing work towards supporting Native assets.

Texture Layer Hybrid Composition (TLHC) mode

Flutter 3.19 includes work that now makes Google Maps and the text input magnifier work in TLHC mode, which means better performance for your apps. If you’re using Google Maps, we encourage you to test out the changes and let us know your feedback!

This work doesn’t include commits under the Framework or Engine, but you can see the work in PR 5408, along with the steps to test the THLC.

Custom system-wide text selection toolbar buttons

Android apps can add custom text selection menu items that appear in all text selection menus (the menu that appears when you long-press on text). Flutter’s TextField selection menu now incorporates those items.

iOS

Flutter iOS native fonts

Flutter text now looks a little more compact and a little more native on iOS. According to the Apple design guidelines, smaller fonts on iOS should be more spread out in order to be easier to read on mobile, while larger fonts should be more compact to not take up as much space. Before, we were incorrectly using the smaller, more spaced out font in all cases. Now, by default Flutter will use the compact font for larger text.

DevTools

DevTools updates

Some highlights for DevTools with this release are:

• Added a new feature and screen in DevTools to validate deeplinks setup on Android.
• Added an option in the Enhance Tracing menu for tracking platform channel activity. This is useful for apps with plugins.

• The Performance and CPU profiler screens are now made available when there is no connected app. Performance data or CPU profiles that were previously saved from DevTools can be reloaded for viewing from these screens.
• The Flutter Sidebar in VS Code now has the ability to enable new platforms if not enabled for the current project, and the DevTools menu in the sidebar now has an option to open DevTools in an external browser window.

To learn more, check out the release notes for DevTools, 2.29.0, 2.30.0, and 2.31.0.

Desktop

Windows Arm64 support

Flutter on Windows is now embracing initial support for the Arm64 architecture, thanks to the commendable efforts of community member @pbo-linaro. This initial support paves the way for more efficient and performant Flutter applications that run natively on Windows Arm64 devices. Although still in development, with progress trackable on GitHub issue #62597, this move signifies a promising enhancement for Flutter developers aiming to optimize their apps for a broader range of Windows devices.

Ecosystem

Required reason privacy manifest

Flutter now includes a privacy manifest on iOS to meet upcoming Apple requirements.

Progress of the Flutter and Dart package ecosystem

In case you missed it, check out the blogpost from January on the progress of the Flutter and Dart package ecosystem.

Deprecations and breaking changes

Dropping Windows 7 and 8 support

As Flutter evolves, we’re excited to focus on the latest technologies by ending support for Windows 7 and 8 with Dart 3.3 and Flutter 3.19 releases. This shift, in line with Microsoft’s strategy, allows us to enhance Flutter on modern operating systems. We appreciate the adjustments required from our developers and are committed to assisting you through this transition. This move paves the way for a more secure, efficient, and feature-rich development environment on supported versions of Windows. Thank you for your understanding and adaptability as we continue to innovate together in the Flutter ecosystem.

Impeller dithering flag

As noted in the release notes for the 3.16 stable release, the global flag Paint.enableDithering has been removed. See the breaking change announcement on the website for full details.

Deprecate iOS 11

Due to a runtime crash when certain networking APIs were called, Flutter no longer supports iOS 11. This means that apps built against Flutter 3.16.6 and later won’t run on those devices.

Deprecate auto render mode

Breaking changes in this release include deprecated APIs that expired after the release of v3.16. To see all affected APIs, along with additional context and migration guidance, see the deprecation guide for this release. Many of these deprecations are supported by Flutter fix, including quick fixes in the IDE. Bulk fixes can be evaluated and applied with the dart fix command line tool.

As always, many thanks to the community for contributing tests — these help us identify these breaking changes. To learn more, check out Flutter’s breaking change policy.

This is the first release to adopt the flutter_driver package into the deprecation policy in addition to already supported packages, flutter and flutter_test.

Conclusion

As we highlighted the remarkable number of contributors at the start of this announcement, we did so with purpose. The evolution of Flutter into the powerful and efficient toolkit it has become is a direct testament to the dedication and hard work of our incredible community. A heartfelt thank you to each and every one of you.

To dive into the specifics of what has been achieved with this release, we invite you to view the release notes and change log for a comprehensive list of additions in Flutter 3.19.

Flutter 3.19, alongside Dart 3.3, is now available on the stable channel. Embarking on this latest journey with Flutter is as straightforward as running flutter upgrade.

What’s new in Flutter 3.19 was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re excited to announce the first of this year’s quarterly SDK releases for Flutter and Dart — Flutter 3.19 and Dart 3.3, along with some exciting announcements involving AI.

Flutter and Dart’s value and future

I recently joined the Flutter and Dart team, and am excited to work with our developer community at a time when AI is moving quickly to enhance developer productivity and unlock new types of user experiences. I see endless potential in Flutter and Dart’s role in helping to shape this future. I’m equally inspired by the original vision for Flutter to improve the experience of building beautiful, performant, multi platform apps for any device.

Judging by the millions of talented and creative developers who support Flutter with contributions to the framework, or by building amazing experiences — it’s clear others see this vision and are motivated to help. And the core mission remains the same: to deliver a strong language and framework pairing, enabling creative developers to build beautiful, rich, and performant apps for any device. Let’s do this together!

Bringing Flutter and Dart into the Gemini era

Today we launched the Google AI Dart SDK, a new pub.dev package, google_generative_ai, and supporting resources; together these enable you to build your own generative AI-based features like smart chat bots, visual search engines, and image descriptions into Dart and Flutter apps using the Gemini API. Flutter and Dart’s cross-platform capabilities and this new SDK make it easier for you to build interactive experiences across platforms.

And this is only the beginning of the innovations that we’re bringing to Flutter and Dart development with AI. For instance, soon Flutter and Dart developers can copy Dart code directly from Google’s AI Studio after honing prompts for your use case.

Learn more about the Google AI Dart SDK in the deep dive blog post.

Many developers have already begun to bring Flutter and AI tools together in exciting ways:

• The team at LeanCode have used the Gemini model to build arb_translate, a package that allows developers to perform translation tasks automatically
• We Spot Turtles! have combined Flutter and AI in their mission to save sea turtles from extinction. They were recently featured in Google Play’s #WeArePlay campaign. Take a look below.
• AutoGPT, an experimental, open-source project that builds on top of large language models (LLMs), has a Flutter client that runs across iOS, Android, web, macOS, and Windows.

#WeArePlay | Caitlin and Nicolas | We Spot Turtles! | Australia

As you explore the Gemini model’s capabilities, be sure to share the new and innovate experiences you’re building with us using the #BuildWithGemini hashtag.

Two new SDK releases

Aside from the excitement that AI brings, we remain focused on continuing to build a strong UI framework, capable of delivering any experience you want to build on any screen you want to build for. You’ll see progress towards that vision in today’s SDK releases, Flutter 3.19 and Dart 3.3.

These releases are focused on refinements and performance improvements that build upon the trajectory that Flutter and Dart set out last year. In this Flutter release, you’ll find:

• Updates to our work to generate breakthrough graphics performance through our continued work on Impeller
• Additional steps towards providing seamless integration between platforms with Flutter iOS native fonts and an early version of a deep linking web validator
• Continued focus on the developer experience with updates to DevTools and a progress report on the Flutter package ecosystem
• And finally, we’re excited to share progress on our mission to help define the future of the web with Wasm

Dart 3.3 in turn, introduces extension types, a new model for interacting with JavaScript on the web, and updates to our work to support access to more and better web libraries. You can learn more about each release in the blog posts for Flutter 3.19 and Dart 3.3, respectively.

2024 Strategy and Roadmap

Each of these features is a small step in a larger journey we’re taking this year, and that you can see in our 2024 roadmap. As always, these roadmaps are born from a desire to be open about our plans as we know many of you consider Flutter and Dart to be essential components in your careers and businesses. That being said, progress can be difficult to predict, even with a plan in place.

And while we’ll do our best to continue to remain transparent as changes inevitably force us to shift focus and make tradeoffs, we want to highlight that there are more contributors to Flutter and Dart outside of Google than those of us employed here, meaning that the things mentioned in our roadmap are but a small portion of the thousands of changes that will come to Dart and Flutter this year.

Bringing it all together

I’ve worked on many fun and innovative projects during my 17+ years at Google and YouTube, but this is the most enthusiastic I’ve felt about leaning into a new opportunity. I started my career as a software engineer, and my first job at Google was as the PM for the Maps API and Geo developer tools, so it’s great to get back to my developer roots.

Part of what drives my enthusiasm is, well, your enthusiasm. Just in 2024 so far, I’ve seen such amazing things come out of this community, including:

• Over 2,700 of you have joined our Global Gamers Challenge, which we’re hosting in partnership with international advocacy firm Global Citizen to challenge you to use your skills to build Flutter games that inspire the world to live more sustainably.
• Superlist, who announced version 1.0 yesterday, is using Flutter to redefine task management, note taking, and everything in between.

In closing, my kids are starting to study Computer Science, and I’m motivated to help create the software development experience that will help the next generation change the world for the better.

This year promises to be an important one for creating that future, and I can’t wait to see the ways in which Flutter and Dart support it. As always, we’re incredibly grateful for your continued support and we can’t wait to see what we’ll build together. Until next time!

Starting 2024 strong with Flutter and Dart was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve been publishing our roadmaps since 2020, and today we’re sharing our 2024 roadmap. This is a natural continuation of previous years’ work, still working towards our long-term goal of creating the most popular, fastest growing, and highest-productivity multi-platform UI framework for building rich app experiences.

Note that what we’re listing here is primarily content gathered from those of us who work on Flutter as employees of Google. By now non-Google contributors outnumber those employed by Google, so this is not an exhaustive list of all the new and exciting things that we hope will come to Flutter this year!

We’re immensely thankful for the community and your continued support. We can’t wait to see what you’ll build!

Sharing Flutter’s 2024 roadmap was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re thrilled to announce the launch of the Google AI Dart SDK for the Gemini API. The new pub.dev package, google_generative_ai, and supporting resources enable you to build your own generative AI-based features into Dart and Flutter apps through an idiomatic Dart integration with the Gemini API. It opens the door to a vast range of possibilities for building intelligent, performant applications for Android, iOS, web, macOS, Windows, and Linux from a single code base.

With the Google AI Dart SDK, you can:

• Easily integrate generative AI features: Add advanced text generation, summarization, chat, and more to your Dart or Flutter apps with minimal setup.
• Tap into Google’s most capable and general model yet: The Gemini model draws on Google’s extensive research and development in machine learning, giving you access to generative AI capabilities that will continue to improve.
• Accelerate your AI-powered app development: Focus on your app logic and user experience, while the SDK handles the intricacies of interacting with AI models.
• Build cross-platform AI-powered apps: Easily create generative AI features across desktop, web, and mobile applications using Flutter.
• Use the Gemini API in more than 180+ countries and territories: Check the available regions for the most current list of countries and regions where the Gemini API and Google AI Studio (described further below) are available.

What can you build?

We believe generative AI holds immense potential to help you achieve your app and business goals. And since the Gemini model is multimodal (it’s capable of processing information from multiple modalities, including images and text), it empowers you to be extremely creative. However, the first question we often get from app developers — and even from within our own team — is “What can I actually do with the Gemini API?” Here are a few examples of features you might create for your Dart or Flutter app:

• Text summarization: Generate concise summaries of long articles, research papers, or website content from textual input.
• Smart chatbots: Build more engaging and human-like conversational interfaces, enhancing user experience in your applications.
• Visual search engine: Users can upload an image, and the app uses the Gemini API to return descriptions of what’s in the image, the style, and perhaps even how to make what’s in the image.
• Image descriptions for accessibility: Generate detailed text descriptions of uploaded images to aid users who are visually impaired.
• Diagram & chart interpretation: Users can upload images of diagrams, charts, or graphs, and the Gemini API delivers a text-based analysis and explanation of the data.

This list could go on because the possibilities are nearly endless!

Getting Started

Check out the Dart quickstart for a detailed step-by-step guide on how to get set up. At a high level, here’s what you’ll do:

1. Get a Gemini API key from Google AI Studio. Keep this key secure. We strongly recommend that you do not include the key directly in your code, or check files that contain the key into version control systems. While developing, we recommend using flutter run -d [DEVICE NAME] — dart-define=API_KEY=[YOUR API KEY] to run the app in an emulator/simulator, using your API key as an environment variable.
2. Add the Google AI Dart SDK to your Dart or Flutter app by running dart pub add google_generative_ai or flutter pub add google_generative_ai, respectively. This adds google_generative_ai as a dependency to your `pubspec.yaml` file.
3. Initialize the generative model in your code:

import 'package:google_generative_ai/google_generative_ai.dart';

// Access your API key as an environment variable (see first step above)
final apiKey = Platform.environment['API_KEY'];
if (apiKey == null) {
  print('No \$API_KEY environment variable');
  exit(1);
}

final model = GenerativeModel(model: 'MODEL_NAME', apiKey: apiKey);

4. You can now start to explore using the Gemini API to implement different use cases. For example, when the prompt input includes both text and images, use the gemini-pro-vision model and the generateContent method to generate text output:

import 'dart:io';

import 'package:google_generative_ai/google_generative_ai.dart';

void main() async {
  // Access your API key as an environment variable (see first step above)
  final apiKey = Platform.environment['API_KEY'];
  if (apiKey == null) {
    print('No \$API_KEY environment variable');
    exit(1);
  }
  // For text-and-image input (multimodal), use the gemini-pro-vision model
  final model = GenerativeModel(model: 'gemini-pro-vision', apiKey: apiKey);
  final (firstImage, secondImage) = await (
    File('image0.jpg').readAsBytes(),
    File('image1.jpg').readAsBytes()
  ).wait;
  final prompt = TextPart("What's different between these pictures?");
  final imageParts = [
    DataPart('image/jpeg', firstImage),
    DataPart('image/jpeg', secondImage),
  ];
  final response = await model.generateContent([
    Content.multi([prompt, ...imageParts])
  ]);
  print(response.text);
}

Explore the Gemini API documentation and check out the Dart and Flutter sample apps in the GitHub repo for detailed guides and examples on how to use the SDK for various use cases, or in this sample app in DartPad, which is a free, open-source online editor for Dart and Flutter snippets, now built with Flutter. Please report any issues or tell us about feature requests in the generative-ai-dart GitHub repo.

Google AI Studio

Alongside the SDK, Google AI Studio is a browser-based IDE for prototyping with generative models. It enables you to quickly iterate to develop prompts for your use case, and then get an API key to use in your app development. You can sign into Google AI Studio with your Google account and take advantage of the free quota, which allows 60 requests per minute. To help us improve product quality, when you use the free quota, your Google AI Studio input and output might be accessible to trained reviewers. This data is de-identified from your Google account and API key.

We will add Dart to Google AI Studio soon, so keep a lookout for the announcement! This will enable you to simply click on “Get code”, select a new Dart tab (which will be alongside the existing supported languages), and then “Copy” the Dart code to transfer your work to your IDE of choice.

Share what you build!

We look forward to seeing what you’ll build with Gemini, like the team at LeanCode who have used the Gemini API to build arb_translate. It’s a package that helps developers to perform language translation automatically, streamlining localization in Flutter apps.

Use the hashtag #BuildWithGemini on Twitter/X to let us know what you’re building!

Harness the Gemini API in your Dart and Flutter Apps was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

When Google Earth set out to rewrite their mobile and web clients in Flutter, they knew they wanted to allow each and every one of their users to explore the planet however they liked, on whatever devices they owned. This had long been true to an extent; after all, Google Earth had existing web, desktop, Android, and iOS clients. But this rewrite, which would cover all of those targets other than desktop, would need to support the superset of existing use cases; plus a few new adaptability ideas the Earth team was excited to explore.

The search for Google Earth’s tech stack of the future was heavily informed by all-too-familiar sources of friction that had slowed development on their existing clients. Namely, Google Earth had long been forced to choose between developer velocity on new features and maintaining feature parity across their three unique codebases (web, Android, and iOS). Luckily, the center of the UI — the entirety of the pale blue dot in the middle of the screen — is powered by a C++ engine that already delivered a unified experience for some of Google Earth’s features. However, the rest of the UI chrome and menus were implemented separately across each codebase. This meant that any cross-platform choice would not only need to overhaul the UI development process, but also integrate with a large legacy engine in Android, iOS, and the web.

The deciding factors to use Flutter were twofold. First, integrating with the existing Google Earth engine proved to be a straightforward task using method channels. Second, Google Earth not only wanted to streamline their codebases, but also to reimagine their UI entirely. Any major UI overhaul is already something of a rewrite, and Google Earth opted to write one new Flutter app instead of performing surgery on three existing apps. This complicated the task, but the team committed to a clean break and obsessive focus on adaptability. In the end, the Google Earth team came to power their UI across three platforms with Flutter.

Defining adaptability

And so, the Google Earth team set out on an adventure to push the limits of UI adaptability. Prior art abounds on creating UIs tailored to different user journeys — dating back to the dawn of smartphones and the entire internet’s collective realization that most websites needed a rethink for small screens. Browser APIs and CSS patterns emerged to build websites with an awareness of their screen’s resolution; and those ideas have been prominent ever since. Even in Flutter’s earliest days, developers knew phone screens would vary and made their apps’ UIs depend on the screen’s resolution. And if that resolution changed — either because the user rotated their phone or resized their browser window, the app’s UI would respond. In Flutter, as in the web for years before it, responsive UIs improved user experiences.

What then, you might wonder, is the difference between a responsive UI and an adaptive UI? Put simply, a responsive UI adjusts to changes in the amount and aspect ratio of available pixels; while an adaptive UI adjusts to everything else. Responsive UIs can grow and shrink individual UI elements based on screen real estate details, but adaptive UIs answer more fundamental questions like where to render the app’s navigation, whether list views should route to separate detail views or show them side-by-side with the list itself, and how the user’s connected peripherals should influence things like tap targets and hover states (more on this concept later).

For more on this, watch episode 15 of Decoding Flutter on Adaptive vs Responsive UIs and see these guides from Flutter and Android’s documentation.

As anyone who’s written responsive CSS for a website will tell you, even simple UIs promise tricky edge cases. And to be clear, this is no fault of CSS; the problem space’s many states are so fine-grained as to almost feel analog. What then, should a UI developer expect when considering several additional variables, such as the device form factor and connected peripherals? Naturally, they should expect a fair increase in complexity.

This all came to a head when the behavior of an early prototype caught the Google Earth team off-guard. While playing with that early build, a Google Earth engineer shrunk their desktop web browser down to an extremely narrow width. Suddenly, typical desktop affordances like side navigation bars and tighter touch targets were replaced by mobile affordances, like a bottom navigation bar and larger, finger-friendly buttons. Their surprise was brief — after all, that was exactly what they’d told their app to do. The Google Earth team was now faced with a profound question — Is this what a user would want?

Such was the terra incognita the Google Earth team was about to chart.

Why adaptability?

To some, the following content raises a meta-question: Why bother with any of this in the first place? Is the ROI sufficient when surely a responsive UI will satisfy most users?

These are good questions, but they should not contribute toward hesitation with Flutter. Using a cross-platform UI framework like Flutter does not introduce adaptive UI concerns; it unlocks adaptive UI solutions. Beyond that, here are two considerations that suggest adaptive UIs really are that important:

• Screen resolutions don’t imply what they once did. Desktop browsers can have low DPI settings that a naive breakpoint check will confuse with mobile environments; high-DPI phones in landscape orientation can be mistaken with old tablet (or even desktop!) breakpoints; and foldable devices can alternate between showing your app full-screen and splitting screen real estate between multiple apps, leading to jarring differences if this careens a user back and forth across certain breakpoints.
• Apps with distinct creation vs consumption modes (think any text composition app with Read and Edit experiences) can suffer heavily on mobile — and especially on tablets. Shipping a mobile-first, and thus likely consumption-first experience to smartphones and tablets greatly limits your power users with a tablet, Bluetooth keyboard, and mouse.

Delivering on adaptability

The Google Earth team walked a long road of experimentation, user research, and iteration to arrive at the app they ultimately shipped. But in the end, their problem space boiled down to three high-level questions:

1. How should the app determine its initial UI strategy?
2. How and when should the app change its UI strategy?
3. How would the Google Earth team cleanly implement this logic?

Determining an initial UI strategy

One of the Earth team’s early assumptions was that “there is no difference between a Chromebook with a touchscreen and a tablet with a connected Bluetooth keyboard”, and that their UI should not distinguish between the two. Although this idea stood to initial reason, it did not survive testing; and over time the Earth team increasingly realized the gaps in this approach. A user launching the app with a high-resolution tablet in landscape mode could find themselves within a desktop UI range of pixel resolution (following older, responsive UI rules). If that same user then rotated their tablet into portrait mode and in doing so shifted into a pixel resolution range assigned to tablets, Google Earth would be faced with a hard choice. The dynamic option would be to dramatically restructure everything by shifting from the desktop UI to the mobile UI; whereas the static option would be to do nothing except squish and compress the desktop UI until it fit in within its new constraints. Neither of these options were satisfying, and it all meant that there was a difference between a Chromebook with a touchscreen and a tablet with a keyboard.

In the end, the Earth team settled on a simple rule: serve the mobile experience to smartphones and tablets, and the desktop experience to desktops. If this seems anti-climactic, well, it sort of is; but only because it punts some of the juicy parts to the next question — When should the UI’s initial strategy change?

Updating the UI strategy within a user session

The Earth team’s first strategy for UI changes was little more than established responsive UI rules: show your mobile UI on any resolutions below a minimum threshold, your tablet UI (if you have one) the next few hundred possible widths, and lastly, your desktop UI on anything else. And, critically, when a UI crosses one of those thresholds for any reason, you re-render the app accordingly. Of course, this ruleset’s awkwardness launched Google Earth onto its odyssey of extreme adaptability; so it should be no surprise that the team abandoned this approach.

A second possibility came from Stadia, a fellow Google team with a successful Flutter mobile app. (Obviously, Stadia did not survive as a product; but that was not for lack of functionality in its mobile app!) Stadia’s approach was to make adaptive UI decisions based on which inputs were last touched. Drag your computer’s cursor or press a key, and Stadia would snap into its desktop UI mode. Conversely, if you tilted a joystick on a connected console controller, Stadia would snap into its console UI mode. However, while that made sense for Stadia, it proved less appropriate for Google Earth. A simple case ruled out this last-inputs-touched strategy: a tablet user pinching to zoom their map, then returning to a Bluetooth keyboard to finish typing content. No user would want two dramatic UI transitions during that simple interaction, so the user’s most recent inputs could not wholesale change Google Earth’s UI from mobile to desktop or back.

In the end, the Google Earth team settled on a second very simple rule: remain consistent within a session and never leave the initial UI flavor without the user’s explicit permission. As explored earlier, Google Earth would show its mobile-first UI on smartphones and tablets and its desktop-first UI on desktops; and it would never outsmart itself and change that unless the user requested a change in the settings panel.

Mixed-UI states

UI consistency within sessions served Google Earth well, but it is not the whole story. UI affordances in desktop experiences like cursor hover effects lack any equivalent on mobile and must be reimagined. A user treating their touchscreen laptop like a tablet could be blocked entirely by an app’s failure to replace critical hover effects with alternatives suitable for mobile. This realization suggested a two-tier problem and solution. Google Earth’s UI would not only need to smoothly switch back and forth between its mobile and desktop experiences when a user requested, but individual controls would need to have both a touch-friendly form and a mouse-friendly form, regardless of the overarching strategy.

Finally, Google Earth knew what they were building. All of their research and iteration left only implementation questions, which amounted to:

1. How to manage transitions between two fundamentally different UIs, and
2. How to build individual controls to support atypical peripherals

Managing multiple UIs

At its simplest, building any Flutter app to seamlessly switch between two different experiences is as simple as putting the following line somewhere in a widget’s build method:

child: mode == Mode.desktop ? DesktopUI() : MobileUI()

However, this strategy (which is what Google Earth uses) implies some extra work elsewhere to fully realize. The issue — initially obscure — surfaces when any application state is stored within a Stateful widget, as toggling that `mode` variable completely replaces the widget tree, destroying all State objects and any information they hold. There are two layers to this problem.

To imagine the first layer, consider a screen that has multiple panels on desktop, but reorganizes each of those panels into a tab bar experience on mobile. A mobile user will have an active tab, but that concept has no equivalent on desktop. Storing the active tab index within a StatefulWidget (an idiomatic decision in Flutter!) would always reset a mobile user’s position to the default tab after toggling back and forth through the desktop UI. The solution to this involves moving any primitive application state — strings, integers, and the like — out of StatefulWidgets and into your state management classes. This way, no shenanigans in your widget tree can reset critical values.

The problem’s second layer comes from application state less easily pulled out of the widget tree, like TextEditingControllers or ScrollControllers. The situation looks like this: you have a ListTile with a TextField, but any time the user touches their mouse or touchscreen, you rebuild that ListTile to accommodate the user’s latest peripherals. Without intervention, this would cause Flutter to destroy the entire part of the Widget and Element trees containing the old TextField, taking with them any controllers holding the user’s work. You might be tempted to treat these as primitives (TextEditingControllers as strings and ScrollControllers as doubles) and repeat the above solution; but controllers are too rich to easily serialize in this way (cursor position and text selection, anyone?).

To solve this problem, Google Earth uses GlobalKeys to have the framework “reparent” highly-scoped widgets after a fresh layout. The following AdaptableTextInput widget is tightly scoped to its TextField and TextEditingController. Supplying the same GlobalKey to that AdaptableTextInput widget across UI-changing rebuilds will keep the TextEditingController alive, saving your users’ work.

class AdaptableTextInput extends StatefulWidget {

  // Supply a consistent GlobalKey here!
  const AdaptableTextInput({super.key, required this.mode});

  final Mode mode;

  @override
  State<AdaptableTextInput> createState() => _AdaptableTextInputState();
}

class _AdaptableTextInputState extends State<AdaptableTextInput> {

  final _controller = TextEditingController();
  final String helpText = 'I clarify this text input!';

  @override
  Widget build(BuildContext context) {
    if (widget.mode == Mode.desktop) {
      return Tooltip(
        showOnHover: helpText,
        child: TextField(controller: _controller),
      );
    } else if (widget.mode == Mode.mobile) {
      return Column(
        children: <Widget>[
          TextField(controller: _controller),
          Text(helpText);
        ],
      );
    } 
  }
}

Navigation

Navigation stacks and the app’s Back button also require special attention. Continuing with the above example of a desktop UI that shows multiple panels at once, now imagine a complementary mobile UI that presents those panels in a stack-like UI with forward and backward navigation. The implications of allowing desktops to use the mobile UI, and phones to use the desktop UI, was one of the big adaptability ideas Google Earth wanted to pursue.

If a desktop-UI user is on the red panel when they switch to the mobile UI, the Back button won’t automatically be wired up, because the navigation stack will be reset. This means your desktop UI needs to account for extra information technically only needed by the mobile UI, because at any moment the mobile UI could be asked to take over.

Luckily, GoRouter’s declarative routing API can help. Create two separate routing declarations and switch to the appropriate route when your user toggles UI modes. In this situation, if the desktop UI has tracked the user’s last activity to the red panel when a request to activate the mobile UI comes in, calling `mobileRouter.go(‘home/blue/red’)` will create a navigation stack with a synthetic history, allowing the user to press the Back button to escape the red screen.

final desktopRouter = GoRouter(
  routes: [
    GoRoute(
      path: '/home',
      builder: (context, state) => FourPanels(),
    ),
  ],
);

final mobileRouter = GoRouter(
  routes: [
    // One route for each panel, configured to wire up
    // the Back button if a user arrives on one of the nested panels
    GoRoute(
      path: '/home/blue',
      builder: (context, state) => BluePanel(),
      routes: [
        GoRoute(
          path: 'red',
          builder: (context, state) => RedPanel(),
          routes: [
            GoRoute(
              path: 'green',
              builder: (context, state) => GreenPanel(),
              routes: [
                GoRoute(
                  path: 'yellow',
                  builder: (context, state) => YellowPanel(),
                ),
              ],
            ),
          ],
        ),
      ],
    ),
  ],
);

Highly adaptive UIs like Google Earth’s require an implementation that treats all possible scenarios as always in play, even though only one given UI is ever being rendered. This means that the app must always be able to completely reconstruct its state from resources you completely control — whether that is because you have GlobalKeys to retain State objects holding important information, or because you’ve stored all relevant details in your state management classes.

Adapting to user inputs

All of this left only one more tricky adaptability problem: ensuring controls across their UI were amenable to the user’s last-used peripherals and not just the reigning UI strategy. After all, if a tablet user started clicking a Bluetooth mouse; Google Earth wasn’t going to wholesale switch to their desktop UI, but they did want to slightly tweak elements to leverage a keyboard and mouse’s strengths.

Merely using Flutter meant Google Earth was off to a good start here. Imagine the alternative: an app that is split across three codebases (JavaScript for desktop via web, and Swift and Kotlin for mobile), when the Swift and Kotlin teams realize that it would be awfully nice if, in some scenarios, they could borrow elements from the JavaScript app’s UI. Maybe what they need can be re-implemented simply enough; or maybe not. Either way; in a Flutter app, the existing tool you want to borrow is always in the same codebase.

But code sharing is not code organization, and the question of how to implement this coherently remained. Here, the Google Earth team turned to an old Flutter staple: the builder pattern.

/// High level categories of user inputs.
enum InputType { gamepad, keyboardAndMouse, touch }

/// Builds a widget tree that depends on the user's current [InputType].
class InputTypeBuilder extends StatelessWidget {
  /// Called when the [InputType] data updates.
  final Function(BuildContext, InputTypeModel, Widget?) builder;

  /// Constructs a wrapping widget that will invoke the [builder] whenever
  /// [InputType] changes.
  ///
  /// See [InputTypeModel] for details on how to change [InputType].
  const InputTypeBuilder({
    Key? key,
    required this.builder,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Consumer<InputTypeModel>(
      builder: (context, inputTypeModel, _) {
        return builder(
          context,
          inputTypeModel.inputType,
        );
      },
    );
  }
}

A widget like InputTypeBuilder listens to a top-level mechanism, the InputTypeModel, which itself subscribes to the Flutter Engine for updates on the last-used input. InputTypeModel.inputType is a property of the InputType enum. And with that, child widgets can make localized decisions about how to render themselves in light of how the user is currently interacting with the app. For example, if you had been using a mouse, but then tapped your finger on the touch screen, affordances that were once only revealed by the cursor’s hover effect would now appear all over the app. And similarly, if you switched back to using the mouse, this InputTypeBuilder would allow them to reverse the change.

@override
Widget build(BuildContext context) {
  return InputTypeBuilder(
    builder: (context, inputTypeModel, child) {
      final bool isHoveredOrTouchInput = isHovered || inputTypeModel.inputType == InputType.touch;
      return Row(
        children: <Widget>[
          isHoveredOrTouchInput ? DragIndicator() : Container(),
          RestOfRow(),
        ],
      );
    },
  );
}

The following gif shows Google Earth’s desktop UI (running in Chrome), nimbly adjusting to the user alternating between touchscreen and mouse actions.

Conclusion

The biggest unexpected wins rebuilding Google Earth with Flutter came to users of the tweener environments — tablets and the web. Caught awkwardly between phones and laptops; tablets can physically support both types of experiences but rarely enjoy the software flexibility to match. Similarly, web experiences can be loaded on any device; and on desktop, browsers can be arbitrarily resized. Depending on the app, all of this can imply radically different UIs. For most development teams with separate codebases for each build target, fully supporting users caught in these limbo states is a non-starter. (Imagine convincing your boss to spend the time rebuilding your entire desktop UI on mobile, just in case a tablet user wants it!)

But, as the Google Earth team found, while building a fully adaptive UI in one codebase did imply extra complexity, it was dwarfed by the user experience improvements gained by meeting each and every user exactly where they were.

You can try Google Earth’s new Flutter implementation today by downloading the app on Android or iOS, or visiting https://earth.google.com.

Extreme UI Adaptability in Flutter — How Google Earth supports every use case on earth was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Flutter and Dart package ecosystem remains a key enabler for developers to build beautiful, performant apps for any screen from a single codebase. The ecosystem grew 26% in 2023 from 38,000 packages in January to 48,000 at the end of December.

Pub.dev now has more than 700,000 monthly active users as of January 2024. The Flutter team remains keen and committed to supporting this growth into the future, and enabling developers to build with and contribute to Flutter and Dart. In this update, we’ll take a look at the newest Flutter Favorites, results of the Package Ecosystem Virtual Summit and share some notable updates and things to know.

New Flutter Favorites

The Flutter Favorites program recognizes and helps developers discover the highest quality packages to consider using in their apps. We’re pleased to announce seven new Flutter Favorite packages that have demonstrated exceptional quality, popularity, and community engagement, making them invaluable tools for Flutter developers. Let’s dive into each:

1. flame: A high-performance 2D game engine for Flutter. Its intuitive API and rich feature set make it an ideal choice for creating visually stunning and engaging games. Check out this codelab to try your hand at building a game with flame.
2. flutter_animate: Bring your UI to life with this a powerful animation library that simplifies complex animations and makes them accessible to all Flutter developers. Its declarative syntax and extensive documentation make it a breeze to create smooth and expressive animations.
3. riverpod: An elegant package that offers a powerful and intuitive approach to managing application state. Its streamlined API, performance, scalability, and testability make it a compelling choice for modern Flutter apps.
4. video_player: Essential for anyone looking to integrate video playback in their Flutter applications. It provides a widget to display video content. It supports a wide range of formats and sources, including network asset and file-based videos. This makes it a versatile tool for building multimedia-rich Flutter apps.
5. macos_ui: For developers targeting macOS, this package enables creation of applications with a design that feels right at home on that platform. It provides an extensive collection of widgets and components that are styled according to the macOS design language, ensuring that your Flutter app not only runs well on macOS, but also looks and feels native.
6. fpdart: This package enables functional programming in Dart. It’s great for implementing business logic, for instance, where functional programming paradigms like immutability, pure functions, and higher-order functions, as well as fpdart’s use of Dart’s type system, helps in building more maintainable and predictable code.
7. flutter_rust_bridge: For developers seeking to leverage the best of Rust and Flutter in their application, flutter_rust_bridge provides a seamless bridge between the two worlds. It enables native Rust code to interact with Flutter seamlessly, unlocking the potential of Rust’s performance and memory safety in Flutter apps.

Sunsetting the Happy Paths program

We decided to sunset the Happy Paths program to enable a more dedicated focus on Flutter Favorites. The vision of Happy Paths recommendations was to help you to make informed decisions on finding and using packages to add functionality to your app. We are fortunate to have community initiatives such as Flutter Gems that are comprehensive resources for navigating well categorized package options. As we focus on the Flutter Favorites program, we will continue to evolve it with input and feedback from the Flutter and Dart community.

Package Ecosystem Virtual Summit

At the end of August 2023, we held a first-time virtual summit for the Flutter and Dart package ecosystem, attended by more than 50 non-Googler and Googler contributors to pub.dev. We started with a relatively small invitee list to fit the unconference-style format, and to learn from this first-time event before figuring out what it might look like in the future. The goal was to bring contributors together in unconference-style discussions to plan, educate, learn, and share amongst the community. We had three discussion sessions, each on topics that were voted on by registered attendees in the weeks leading up to the summit. The three discussion topics were 1) Building high quality packages — best practices, and challenges, 2) Maintaining packages long term — sustainable models, and 3) Flutter and Dart DevTools Extensions. Respondents to the post-event survey gave us insightful feedback that we’ll incorporate in future event planning. Thank you! Overall, we consider this first summit a success. Going forward, we’re keen to partner with the community on similar standalone events, or sessions focused on the Flutter and Dart ecosystem, set within more general events.

Updates to the Pigeon package

The Pigeon package is a code generation tool that streamlines setting up the communication between your Flutter app and platform-specific code. This makes Pigeon useful both 1) when writing custom integrations directly between a Flutter app and platform-native APIs, such as in an add-to-app scenario, and 2) when writing a Flutter plugin to provide a Dart API surface for platform-native APIs. It’s maintained by the Flutter Team who has made the following notable improvements to the package over this year:

• Added support for Swift, Kotlin and C++ (C++ unlocked Windows support).
• Null safety is now enforced.
• Expanded support for primitive data types support. For example, enums were added as a supported type.
• Added nullable parameters.
• Added error handling on host and Flutter APIs.
• Improved the ergonomics of the tools to make them easier and more intuitive to use. For example, we added support for default parameters and named parameters.

There are a lot more developments between v5.0.0 in January and v15.0.2 in December than we can list here, so check out all the changes in the change log!

Packages in DartPad

DartPad supports a fixed set of packages that you can view by clicking the info icon in the bottom, right-hand corner of the screen. The Flutter and Dart team at Google reviews and prioritizes package requests on an ongoing basis. If you’d like a package to be added to DartPad, add your thumbs up to an existing package suggestion, if there is one, or open a new issue with your suggestion.

Proposal for canonical topics on pub.dev

In 2023 we launched the ability for package authors to tag their package with 1–5 free text topics in the pubspec file. The goal was to improve discovery of packages by potential users by adding a form of package categorization. We’ve seen a healthy uptake of the feature with many packages tagged. We’re exploring a proposal to improve the feature by merging topics that are effectively the same (For example, widget and widgets). We invite the community to share feedback or contribute PRs to this canonicalize topics issue.

That’s it for now! To engage with the amazing community of package authors, check out the #package-authors Discord channel (you first need to join the Flutter Discord server).

Progress of the Flutter Package Ecosystem was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

We know Flutter devs love a good challenge, so just in time for the new year, we’re excited to announce the next Flutter challenge!

The Global Gamers Challenge is an 8 week contest to design, build, and publish sustainable games, sponsored by Flutter and Global Citizen. The contest’s winners will receive a trip to NYC in September 2024 to meet some of the Flutter team for a day of workshops and mentorship, and then celebrate their achievements with up to 60,000 other Global Citizens at Global Citizen Festival 2024.

What are sustainable games?

Sustainable games use the power of play to inspire positive environmental action. Imagine Candy Crush, but instead of crushing candies, you’re crushing plastic pollution! Or, picture a game like Super Dash, but instead of collecting acorns, you’re in Dash’s home figuring out how to cool the house by optimizing a path for airflow using windows instead of the AC. Here are some more ideas inspired by Global Citizen campaigns running right now:

1. Encourage a reduction in home energy use
   Data shows that American homes average three times more electricity use than typical homes across the rest of the globe. Can you build a game that helps to reduce reliance on inefficient energy sources?
2. Encourage a reduction in use of single-use plastics
   Southeast Asia has some of the highest levels of plastic pollution in the world. Consider building a game that encourages someone to make a swap, like opting for a reusable water bottle over a single-use one.
3. Encourage use of public transportation for short distances and overland options for longer distances
   Europe is home to many of the world’s greatest public transportation systems. Effective games can encourage people to use local public transit for shorter distances, and overland transport, like trains rather than planes) for longer distances.

We’re confident that games can encourage players to take small, real life, actions that add up to a large impact for the environment. In fact, if you’d like to take direct action on these items, check out the campaigns Global Citizen is running now.

Why join the Global Gamers Challenge?

Defend the planet

This contest was inspired by the Playing for the Planet Alliance, a United Nations-facilitated alliance of 50 game studios and companies, including Google, with a mission to reduce the industry’s environmental impact and leverage the power of gaming to bring awareness to and coordinate action for important environmental issues like climate change, biodiversity loss, and pollution.

Games produced by members of the Playing for the Planet Alliance have a combined reach of over 1 billion people. Through the Alliance’s flagship initiative, the Green Game Jam, participating games have created real-world impact by raising funds to plant 2.75 million trees and raised roughly $1,500,000 USD to protect wildlife and support environmental causes.

We’ve partnered with the Playing for the Planet Alliance to source best practices for environmental games and added them to the resources kit provided as part of this challenge. This is your chance to build something that helps protect our planet!

Learn something new

Whether you’re a Flutter developer who’s new to games, a game developer who is new to Flutter, or someone new to both game development and Flutter, you’re bound to learn a few tricks while creating a positive impact on the world.

Details

Timeline

All projects must be submitted by March 5, 2024, 2:59pm PT (GMT -8). A Top 20 will be announced in late March 2024, and final winners will be announced in May 2024.

Submission guidelines

Registration and entry submission instructions can be found at DevPost.

Awards

Winners will be judged based on criteria like:

• Originality and creativity
• Sustainable action and story
• Use of animation
• Effective Multi-platform deployment

We won’t just award great coding ability, though. We also have prizes for great ideas, demo videos, educational content for your game, and more!

Resources

We’ve compiled a bunch of resources to help you build a game, including a guide to navigating this challenge, kind of like a game map. It shows you the resources you need, helps you become a Global Citizen through a new learning journey in the Global Citizen application, and contains instructions on how to register and submit your game.

Teams

We recommend completing this challenge as part of a team. When you register for the challenge on Devpost, you’ll be able to share your skillset, your team status, and your ideas.

So, whether you have a great idea but need teammates with technical skills to bring it to life, or if you have the technical skills, but want a great idea, make sure to fill out your profile accordingly and then peruse the participants tab and look for folks whose profile details match what you’re looking for!

We’re particularly excited for the ideas that will come from technologists and activists working together towards a common goal. If you need extra support in finding a teammate, read over this help article.

Finally, note that teams can be any size, but only 3 people from a team will be able to travel to New York City should the project be selected as a finalist.

Get started and stay connected

Check out the official contest site at flutter.dev/global-gamers for everything you need to know. You can also visit DevPost to register and submit your game.

Submissions close on March 5th, so don’t wait! We can’t wait to see what you build!

Announcing the #GlobalGamers Challenge was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

As part of the Google Cloud Applied AI Summit, the Flutter and Vertex AI teams collaborated with Very Good Ventures to create an AI-powered Flutter demo app, Ask Dash, using Vertex AI Search and Conversation by Google Cloud. Vertex AI Search and Conversation empowers you to build and deploy search and conversational applications quickly with little to no experience in AI. Flutter was a great way to build a beautiful, customized search experience to show how both products can be used to build powerful applications in only a few short weeks!

Vertex AI Search and Conversation allows you to create applications that interact with your data with personalized responses demonstrating the power of generative AI. Most importantly, it gives you full control over what data your application accesses and indexes so you can control what information is surfaced to which user. All application data and user interactions are stored in your own cloud instance and are never used to train Google’s underlying machine learning models.

Since we used Flutter to build the demo app, we decided to use Flutter documentation as training data. We worked with the Google Cloud team to train the model specifically on the Flutter and Dart developer documentation to provide generative AI responses to questions like: What is Flutter? What platforms does it support? And what is hot reload? While much of this data is readily available in public AI models, this demo showcases how you can train a model on just your own data to create powerful AI experiences.

This article takes you through how our partner, Very Good Ventures, built a Flutter web application and how we connected the app in the Cloud console.

How we built the Flutter web app

The idea of creating a search application trained on the Flutter docs was straightforward. In fact, the official Flutter documentation already provides a simple search experience that delivers relevant page results for questions on Flutter. However, when conceptualizing what to build, we wanted to demonstrate how Flutter can be used to create visually appealing interactive experiences that are fun and engaging.

Creating interactive animations in Flutter

Flutter empowered the team to implement a wide array of animations seamlessly. Its rich set of animations, coupled with the flexibility of widgets, allowed us to create transitions, engaging motion effects, and fluid user interactions. From creating animated loading states while generating the results, to a Dash sprite that waves when the answers appear, Flutter provided flexibility to turn what could be a basic text response into something fun for users to interact with.

Visualizing natural language search results

Unlike a traditional search experience, Vertex AI Search provides a natural language response to the question asked. The answer is generated with AI sourced from various pages within the Flutter documentation and presented as a summarized response alongside cards that display the relevant pages used by the AI. Each card provides the title to the page and a description so that the user can flip through the cards to get more context on the AI response.

Additionally, within the natural language response, Vertex AI Search provides a link to the source of each sentence in the response — giving the user a more granular understanding of where each part of the response originated. In the demo, clicking on the number next to each sentence flips the cards to the relevant source page.

More engaging in less time

Going into the project, we had a tight deadline to launch the demo at the Google Cloud Applied AI Summit. Flutter’s efficient development and ease-of-use, significantly expedited the development process for the team of two working on the application. It provided the necessary tools and framework to build complex animations efficiently, enabling our team to build and launch this demo in just under the two weeks leading up to the event.

Connecting the Flutter app to the Vertex API

Integrating our front end web application with the Vertex AI Search API was achieved with a simple request using the `http` package. Without requiring any previous experience in building AI, Vertex AI Search provided answers to user-generated questions as JSON responses that were parsed and displayed within animated widgets. This allowed the team to focus on Flutter development to create an engaging experience out of the generated data.

Setting up generative AI search in your application

Setting up Vertex AI and hosting the API for our Flutter app was also straightforward.. In our case, we used https://docs.flutter.dev/ as our data source and set it up directly in the Google Cloud console. As a Google Cloud customer, getting started with Vertex AI requires just three steps:

1. Create a data store

This is your website’s digital library, holding all the information you need to generate the AI model based on just the root URL. Google Cloud crawls your website for relevant data and creates a data source for you to query. To set this up in the Google Cloud Console,select Search and Conversation. Choose Data Stores and then New Data Store. Opt for Website URL as the source and provide your website’s URL.

2. Access your data

Next, create an app in Cloud Console to navigate the data indexed by the model and link it to the data store you created earlier. Under Search and Conversation, choose Apps and then New App. Select Search as the type and give your app a name that reflects its purpose, like Ask Dash.

3. Craft a Cloud Function

Finally, create a Cloud Function. This is the API wrapper that exposes your Vertex AI data to other applications. In the Console, go to Cloud Functions and select Create Function.

That’s it!

From there, use the API in your front-end application as you would any API to send requests and receive formatted responses that your application can display. To test it out, head to the Function page and select Testing. Enter a JSON object with a “search_term” key for your question (such as “hot reload”), and see a detailed response containing a natural language summary, relevant citations, and concise summaries of the referenced pages.

Learn more about how to get started with Vertex AI Search in Google Cloud’s documentation.

Generative AI applications built in Flutter

To see Ask Dash in action and learn more about how we built it, check out the video session from the Google Cloud Applied AI Summit, where Alan Blount, a Product Manager for Google Cloud, breaks down the build process to show the potential of Vertex AI Search in a Flutter application. Check out the open source Flutter code for the demo and get started with your own AI search experience in Google Cloud Console.

Ask Dash is just the start for how Flutter can power interactive Generative AI experiences in applications. We can’t wait to see what you build!

How we built it: Ask Dash — A generative AI Flutter application was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

Have you ever wanted to build developer tooling for Dart and Flutter but didn’t know where to start? Or maybe you didn’t want to go through all the work of establishing a connection to a running Dart or Flutter application to access debugging data? Then, even if you did create a development tool, how would you deploy it or give users easy access to it? Well, we have some good news for you: now you can create developer tooling without all these hurdles.

With the new Dart & Flutter DevTools extensions framework, you can easily build developer tooling that is tightly integrated with the existing DevTools tooling suite. Extensions are built using Flutter web and leverage existing frameworks and utilities from DevTools to simplify the developer tool authoring experience.

How do DevTools extensions work?

Extensions are shipped as part of a pub package. For example, imagine we have some package:foo, and this package provides a DevTools extension. When a user depends on package:foo in their app, they automatically get access to the DevTools extension provided by this package. When this user is debugging their app with DevTools, they will see a new tab “Foo” that contains the developer tools provided by package:foo.

You can add a DevTools extension to an existing pub package, for example package:provider, package:patrol, or package:drift, which have all already published DevTools extensions, or you can create a new package that provides a DevTools extension only. In both these scenarios, the user must list a dependency on the package providing the DevTools extension in order to see the developer tool in DevTools.

Writing a DevTools extension: a step-by-step guide

Before you get started

What you will need:

• Flutter SDK >= 3.17.0–0.0.pre & Dart SDK >= 3.2.
• A Pub package (existing or new) to add a DevTools extension to.

It is recommended to develop your extension from the Flutter master channel in order to use the latest devtools_extensions and devtools_app_shared packages

Step 1: Set up your package hierarchy

To add an extension to your Dart package, add a top-level extension directory to your package.

foo/
  extension/
  lib/
  ...

Under the extension directory, create the following structure (exactly as shown):

extension/
  devtools/
    build/
    config.yaml

The config.yaml file should contain metadata that DevTools needs to load the extension:

name: foo
version: 0.0.1
issue_tracker: <link_to_your_issue_tracker.com>
material_icon_code_point: '0xe0b1'

Copy the config.yaml file content above and paste it into the config.yaml file you just created in your package. For each key, fill in the appropriate value for your package.

• name: the package name that this DevTools extension belongs to. The value of this field is used in the extension page title bar. [required]
• version: the version of your DevTools extension. This version number should evolve over time as you ship new features for your extension. The value of this field is used in the extension page title bar. [required]
• issue_tracker: the url for your issue tracker. When a user clicks the “Report an issue” link in the DevTools UI, they are directed to this url. [required]

• material_icon_code_point: corresponds to the codepoint value of an icon from material/icons.dart. This icon is used for the extension’s tab in the top-level DevTools tab bar. [required]

For the most up-to-date documentation on the config.yaml spec, see extension_config_spec.md.

Where to put your extension source code

Only the pre-compiled output of your Flutter extension web app needs to be shipped with your pub package for DevTools to load it in an embedded iFrame. To keep the size of your pub package small, we recommend that you develop your DevTools extension outside of your pub package. We recommend the following package structure:

foo/  
  packages/
    foo/  # your pub package
      extension/
        devtools/
          build/
            ...  # pre-compiled output of foo_devtools_extension
          config.yaml
      ...
    foo_devtools_extension/  # source code for your extension

Now it’s time to develop your extension.

Step 2: Create a DevTools extension

From the directory where you want your extension source code to live (foo/packages in the example above), run the following command, replacing foo_devtools_extension with <your_package_name>_devtools_extension:

flutter create --template app --platforms web foo_devtools_extension

In foo_devtools_extension/pubspec.yaml, add a dependency on devtools_extensions:

devtools_extensions: ^0.0.10

In foo_devtools_extension/ib/main.dart, place a DevToolsExtension widget at the root of your app:

import 'package:devtools_extensions/devtools_extensions.dart';
import 'package:flutter/material.dart';

void main() {
  runApp(const FooDevToolsExtension());
}

class FooDevToolsExtension extends StatelessWidget {
  const FooDevToolsExtension({super.key});

  @override
  Widget build(BuildContext context) {
    return const DevToolsExtension(
      child: Placeholder(), // Build your extension here
    );
  }
}

The DevToolsExtension widget automatically performs all extension initialization required to interact with DevTools. From anywhere in your extension web app, you can access the global variables extensionManager and serviceManager to send messages back and forth with DevTools or interact with the connected app.

Utilize helper packages

Use package:devtools_app_shared for access to service managers, common widgets, DevTools theming, utilities, and more. See devtools_app_shared/example for sample usages.

Step 3: Debug a DevTools extension

When developing and maintaining your DevTools extension, you’ll want to run, debug, and test your extension Flutter web app. You have a couple of different options for this, outlined below.

Option A: Use the Simulated DevTools Environment (recommended for development)

For debugging purposes, you will likely want to use the “simulated DevTools environment”. This is a simulated environment that allows you to build your extension without having to develop it as an embedded iFrame in DevTools. Running your extension this way will wrap your extension with an environment that simulates the DevTools-to-DevTools extension connection. It also gives you access to hot restart and a faster development cycle.

1. Your DevTools extension.
2. The VM service URI for a test app that your DevTools extension will interact with. This app should depend on your extension’s parent package (package:foo in this example).
3. Buttons to perform actions that a user may trigger from DevTools.
4. Logs showing the messages that will be sent between your extension and DevTools.

The simulated environment is enabled by the environment parameter use_simulated_environment. To run your extension web app with this flag enabled, add a configuration to your launch.json file in VS code:

{
    ...
    "configurations": [
        ...
        {
            "name": "foo_devtools_extension + simulated environment",
            "cwd": "packages/foo_devtools_extension",
            "request": "launch",
            "type": "dart",
            "args": [
                "--dart-define=use_simulated_environment=true"
            ],
        },
    ]
}

or launch your app from the command line with the added flag:

flutter run -d chrome - dart-define=use_simulated_environment=true

Option B: Use a real DevTools environment

Once you develop your extension to a point where you are ready to test your changes in a real DevTools environment, you need to perform a series of setup steps:

1. Build your Flutter web app and copy the built assets from the your_extension_web_app/build/web directory to the parent package’s extension directory (your_pub_package/extension/devtools/build). To do this, use the build_and_copy command from package:devtools_extensions:

cd your_extension_web_app;
flutter pub get;
dart run devtools_extensions build_and_copy --source=. --dest=path/to/your_pub_package/extension/devtools

Note: if you are using the recommended package structure from above, the value for — dest should be ../your_pub_package/extension/devtools.

2. Prepare and run a test application that depends on your pub package. In the test application’s pubspec.yaml file, you’ll need to change the dependency on your package to be a path dependency that points to your local package source code. Once you have done this, run flutter pub get on the test app, and run the application.

3. Start DevTools. Open the DevTools instance that was just started by running your test application. You can open DevTools from either the url printed to the command line or from the IDE where you ran your test app. Optionally, you can also run dart devtools from the command line.

Note: If you need local or unreleased changes from DevTools, you’ll need to build and run DevTools from source (server + front end). See the DevTools CONTRIBUTING guide.

4. Connect DevTools to your test app if it is not connected already, and you should see a tab in the DevTools app bar for your extension. The enabled or disabled state of your extension is managed by DevTools. The extension-enabled states are exposed from an “Extensions” menu in DevTools, available from the action buttons in the upper right corner of the screen.

Step 4: Publish your package with a DevTools extension

In order for a package to provide a DevTools extension to its users, it must be published with the expected content in the your_pub_package/extension/devtools/ directory (see the setup instructions above).

1. Ensure that the your_pub_package/extension/devtools/config.yaml file exists and is configured per the specifications above.
2. Use the build_and_copy command provided by package:devtools_extensions to build your extension and copy the output to the extension/devtools directory:

cd your_extension_web_app;
flutter pub get;
dart run devtools_extensions build_and_copy --source=. --dest=path/to/your_pub_package/extension/devtools

Then publish your package on pub.dev: flutter pub publish. For additional guidance around publishing your package, see the package:devtools_extensions publishing guide.

Conclusion

That’s it! Now, when a user depends on the latest version of your package, they will automatically get access to the tools you provide in your DevTools extension. This feature is hot off the press, so we are eager to hear your feedback.

For issues and feature requests, please file an issue on the DevTools issue tracker.

For general support and access to the community of DevTools extension authors, check out the #devtools-extension-authors Discord channel (you will first need to join the Flutter Discord server).

Dart & Flutter DevTools Extensions was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.