Dart News & Updates

Hot reload on save By request, we now support doing a hot reload on file save. On an explicit save (cmd-s / ctrl-s or File > Save All), if there’s an app currently running we will try to reload changes into that app. This integrates well with how IntelliJ’s save action works — the default behavior of the action maps to a save-all command. If there are analysis errors on save, instead of reloading we will highlight errors in the analysis view. This behavior is off by default and can be turned on in Settings > Languages & Frameworks > Flutter. Feedback on this feature is much appreciated and will help us make additional improvements to the workflow. In particular, should we enable this feature by default? Improved project wizard We’ve updated the new project wizard! You can now choose which type of Flutter project to create: an app, a plugin project – to expose native services, or a package – to create a reusable Dart library. In add...

One of the most important features for Dart 2.0, strong mode , has been available for several releases. Migrate to strong mode now to take advantage of the new sound type system that finds errors at compile time (rather than letting your users discover them). You may even find bugs that have been lurking in your code.  If you are using Flutter, it already uses strong mode, so you have met this requirement.  Strong mode is the primary breaking change for 2.0, but there are likely to be other updates. For more information, see Dart 2.0 Updates.

New testing support We’ve added the ability to run individual Flutter tests via actions in the editor’s gutter: And now support running Flutter’s widget tests; see https://flutter.io/testing/# widget-testing . Project structure We re-worked how we define Flutter project and module types in IntelliJ. This addresses a few outstanding issues and will let us more easily go into more IntelliJ based products in the future. The next time you open an existing project with the new version of the plugin, you’ll see a one-time ‘module type updated’ message: Launching improvements This release sports several improvements to app launching: Launch your app in profile and release modes (available via the ‘Run’ menu) Start Android emulators from the device dropdown; this requires the Android AVDs to have been already created in something like Android Studio Tweaks to when the run and reload buttons are enabled For more detailed info on the version 16.0 release, s...

We’re aflutter to announce the official Dart conference in Los Angeles on January 23-24, 2018. The event will be even bigger and better than last year, with exciting talks about Dart 2.0, Flutter, Dart Dev Compiler, AngularDart, and much more. UPDATE : Please learn more and register here . We’re moving the annual conference from October to January for two reasons: We want our speakers to be available for the other conferences that are happening in the Fall. Each year, September to November is full of events where the team can reach developers unaware of the awesomeness of all things Dart. Likewise, we don’t want you to have to choose between DartConf and other great events. Lots of new things are coming to Dart in the new year. Place: Google Los Angeles Time: January 23-24, 2018 Pre-registration: [CLICK HERE] The event will be live-streamed and sessions will be recorded. Ask questions at dartconf-questions@googlegroups.com.

Flutter test support! We now support running and debugging ‘flutter test’ tests! Right click on your Flutter tests in the test/ directory, and choose the ‘Run’ or ‘Debug’ option: The results are displayed in the standard IntelliJ test runner. The support for this just recently landed in Flutter’s alpha channel, so you don’t see support for it in IntelliJ, you may want to run ‘flutter upgrade’. Happy testing! Improved project creation When creating a new Flutter project, you now have the option of installing the Flutter SDK from the new project wizard. This will help new users get started – they can create their first Flutter project without having to make a detour to the command line. In addition, we’ve improved the error reporting on project creation failures. Reload feedback improvements Based on user feedback, we’ve made some improvements to the UI for hot reload. When clicking the hot reload button (or using the reload key binding), we disable the hot reload ...

We are constantly asking ourselves: How do we make developers even more productive when writing Dart apps? We believe that a critical part of the answer to this question is to make strong mode – a sound static type system for Dart – the standard for all Dart developers. Teams that use Dart to build apps like Soundtrap , AdWords , AdSense , and Greentea say they really enjoy using strong mode features, such as early error detection. In fact, teams that have switched completely to strong mode cite not only early error detection but also better code readability and maintainability as major benefits. We hear this both from small teams and – even more so – from large teams with hundreds of developers writing and maintaining millions of lines of Dart code. As Björn Sperber from Soundtrap says, Strong mode and the smooth integration with IntelliJ is a joy to use and a huge improvement. If you’ve tried out Flutter , you’ve already used strong mode checks from the Dart analyzer. G...

Long long ago in the dawning days of Dart, when Future s were new and Stream s unknown, Bob saw the need for a package manager to bring the people together. Together he and I spun formless bits into code and wove that code into pub , which even today carries code into the eager hands of Dartisans. In those olden days, we had no modern marvels such as the twins async and await , and our tests grew heavy and graceless under the weight of their chain() s 1 . So it was that I came up with an idea for a new way of writing tests. Instead of gluing the steps together with the cumbersome Future API, each step would register an asynchronous callback in a queue. Once all the steps were queued up, the library would run them in order. All the API boilerplate would be hidden away from the user, and the tests would look nice and clean . After honing this technique on pub’s tests, I brought it out into its own package, which I called scheduled_test . If this whole idea of queuing up tasks and ...