Skip to content

Dart GSoC 2023 Project Ideas

Jump to bottom
Jonas Finnemann Jensen edited this page Feb 14, 2024 · 19 revisions

⚠️ Google Summer of Code 2022 is no longer accepting applications.

A list of Google Summer of Code project ideas for Dart.

For GSoC related discussions please use the dart-gsoc group.

Potential mentors

  • Jonas Jensen (jonasfj) jonasfj@google.com
  • Daco Harkes (dcharkes) dacoharkes@google.com
  • Sigurd Meldgaard (sigurdm)‎ sigurdm@google.com
  • Liam Appelbe‎ (liamappelbe) liama@google.com
  • Hossein Yousefi‎ (HosseinYousefi) yousefi@google.com
  • Majid Hajian (mhadaily) mhadaily@gmail.com
  • Brian Quinlan (bquinlan) bquinlan@google.com

Project Application Process

All projects assume familiarity with Dart (and sometimes Flutter). Aspiring applicants are encouraged to learn Dart and try to write some code.

Applicants are welcome to find and fix bugs in Dart or some of the packages written by the Dart team. However, getting reviews can take a long time as code owners may be busy working on new features. So instead of requiring applicants to fix a good first bug, we suggest that applicants write a working code sample relevant for the proposed project.

The code sample can be attached to the application as a secret gist (please use secret gists, and do not share these with other applicants). Suggested ideas below includes proposed "Good Sample Projects".

Do not spend too much energy on this piece of sample code, we just want to see that you can code something relevant -- and that this sample code can run and do something non-trivial. Be aware that we have a limited number of mentors available, and will only be able to accept a few applicants.

Applications can be submitted through the summerofcode.withgoogle.com website. Applicants are encouraged to submit draft proposals, linking to Google Docs with permission for mentors to comment. See also the contributor guide on writing a proposal.

IMPORTANT: Remember to submit final proposals before the April 4th deadline.

Idea: GOgen (or Rustgen, or ...)

Description: Package FFIgen makes interop with C and Objective-C seamless, and the (experimental) package JNIgen does the same for Java and Kotlin. However, what about Go?

In this project we would parse Go files and generate C wrappers and Dart bindings to those C wrappers so that developers can easily interop with Go from Dart.

  1. Design a way to interop with Go. We can explore cgo, is this at the right abstraction level for interop? Or would we want a more high level interaction? For example, since Go is garbage collected, can we have handles to Go data structures from Dart that prevent them from being Garbage collected?
  2. Design an approach to get the right information from a Go API. This will likely involve a Go parser and static analysis tool. That data structure then needs to be made accessible in Dart (either serialization such as in JNIgen or with direct FFI as in FFIgen).
  3. Generate the code that does 1 and 2.
  4. Profit!

(Alternatively, we could also do this project for another language. IDL, C++, Rust, …)

Good Sample Project: (1) Build a small sample project where you interop with a Go library. (2) Build a prototype for generating the bindings for that library, and (3) use a Go parser to generate those bindings.

Idea: Testing documentation comments

  • Possible Mentor(s): jonasfj@google.com, sigurdm@google.com
  • Difficulty: Hard
  • Project size: Large (350 hours)
  • Skills: Dart, static analysis

Description: When writing Dart code it is useful to write documentation comments, such comments will be included in automatically generated documentation created by dartdoc. Documentation comments for dartdoc are written in markdown, which allows authors to embed code samples. This project aims to create tools for testing code samples embedded in documentation comments.

This will likely involve:

  • Using package:analyzer to extract documentation comments.
  • Using package:markdown to extract code samples.
  • Testing these code samples by:
    • Running dart analyze on the code sample,
    • Passing the code sample through dart format, and/or,
    • Running the code sample in an isolate and compare stdout to comments from the sample.

For this project, we'll finish the dartdoc_test package, such that it can be used by package authors who wish to test code samples in their documentation comments.

As part of this project, we'll likely have to define conventions for what is expected of a code sample in documentation comments:

  • What libraries (if any) are implicitly imported?
  • Can you make code samples that are excluded from testing?
  • Can comments inside the code sample be used to indicate expected output in stdout?
  • How should code be written?
    • Do all code samples need a main function?
    • Do we wrap top-level code in an implicit main to keep it simple?
    • Do we run the top-level function if it has a name other than main?
  • Do we allow dead-code in samples (without an // ignore: unreachable comment)?
  • What lints do we apply to sample code (same as the top-level project).

Some of these questions might be debated in the project proposal. A project proposal should also discuss how package authors would run the code sample tests. Finally, a project proposal is encouraged to outline implementation stages, including strech goals.

Good Sample Project: Create a function that given some Dart code will use package:analyzer to do static analysis of the code and count static errors. Additional step would be to try and use package:analyzer to extract documentation comments from source code and use package:markdown to extract code-snippets from source code comments, and then run analysis on the extracted source code snippets. Ideally, all of this could be done, in-memory without writing files to disk.

Idea: Build a Dart HTTP client using Java APIs

  • Possible Mentor(s): bquinlan@google.com, yousefi@google.com

  • Difficulty: Hard

  • Project size: Large (350 hours)

  • Skills: Dart, Java, Android

Description: Write a HTTP client that conforms to the package:http Client interface and uses native Java APIs through package:jnigen. This will allow us to provide several features requested by our users such as:

  • Support for KeyStore PrivateKeys (#50669)
  • Support for the system proxy (#50434)
  • Support for user-installed certificates (#50435)

Successfully completely this project will likely involve:

  • Determining exactly what APIs should be make available in Dart.
  • Creating a JNI bindings for those APIs using package:jnigen.
  • Creating a higher-level interface over the JNI bindings e.g. so the Dart developer can work with Dart URIs rather than java.net.URI.
  • Creating a package:http Client implementation using the interface above.
  • Verifying that the Client implementation passes the conformance tests.

You'll like working on this project because:

  • It will be easy to implement incrementally. After the basic functionality is present, more advanced APIs can be added as time permits.
  • There are existing conformance tests to validate the correctness of the work.
  • Dart users want it!

A good project proposal will describe what Java APIs are necessary to implement the package:http Client interface and an excellent project proposal will discuss what features package:jnigen needs to to use those APIs from Dart.

Good Sample Project: Try writing a small Flutter application that makes HTTP requests using Java API bindings created with package:jnigen.

Idea: Refactor Plus packages to utilize new Dart 3 language features

  • Possible Mentor(s): Majid Hajian mhadaily@gmail.com
  • Difficulty: Hard
  • Project size: / Medium (175 hours)
  • Skills: Dart

Description: Dart 3 introduces a few new language features. There are several features such as Records, pattern matching and new direct platform library interop which potentially helps to improve code readability and better API design for packages.

We would like to explore the possibilities of the new language features that could help to improve packages and create a new API (potentially) or refactor internal coding that make the package to take full advantage of Dart 3. We would like to also prepare a guideline after this refactoring for other maintainers to figure out what could be improved or changed.

We are using Federated plugins therefore this is likely to involve:

  • refactoring platform_interface class for each package,
  • refactoring app-faceing and platform-specific-implementation packages,
  • potentially removing native code and replacing it with direct dart API calls,
  • rewriting the entire package unit and e-2-e tests,
  • replacing CI/CD existing workflow making it compatible with upcoming language feature, and
  • potentially breaking the API and releasing a new major version.

Some of these questions might be debated in the project proposal. A project proposal is encouraged to outline implementation stages, including stretch goals.

Good Sample Project: Create new packages for both Device_Info or Connectivity_Plus and redesign part of the APIs including in platform interface and use Dart 3 language features, then create a Flutter project from Master branch and then use these packages with latest Flutter and Dart 3 version that uses all APIs.

FAQ about the Dart VM

Clone this wiki locally