[!warning] Google Summer of Code 2024 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
jonasfj@google.com
dacoharkes@google.com
yousefi@google.com
chinmoy12c@gmail.com
liama@google.com
mannprerak2@gmail.com
jacksongardner@google.com
camillesimon@google.com
bquinlan@google.com
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 2nd deadline.
Description:
Original idea: A web interface in which you paste a C header in a textbox on the left, and it outputs dart:ffi
bindings generated by package:ffigen
in a textbox on the right. (Inspiration is https://godbolt.org/ which does this for a C file on the left and assembly on the right.)
In order to avoid needing a server to do the backend, we'd like to compile the Dart code in package:ffigen
and libclang
to WASM. That way everything can run in the browser.
Good Sample Project:
For the purposes of this project, we decided that direct linking is going to make more sense for interfacing with libclang. It should be noted that direct linking will not actually work with a Flutter app, since wasm-compiled flutter apps already link against a separate wasm module for rendering and you cannot link more than one linear memory to the dart2wasm compiled module.
The recommended approach is going to be something like the following:
dart:ffi
and @Native
annotations to import the C function and call it.package:web
to interact with the DOM, in order to input and output information to the user.dart compile wasm
. The compiler outputs a main.dart.mjs
file that is produced alongside the main.dart.wasm
file. This is used to instantiate and invoke the webassembly-compiled dart program. Usage in JavaScript should look something like this:import 'main.dart.mjs' as dartProgram; const imports = ...; // Do something here to instantiate the external C module so its exports can be passed in as imports const module = await dartProgram.instantiate(WebAssembly.compileStreaming(fetch('main.dart.wasm')), imports); dartProgram.invoke(module);
Getting all this working and communicating would be a good first step. After that we'd probably want to look into doing some simple virtual filesystem access in the C module, as libclang
will need access to the source files.
Expected outcome: A web app (possibly hosted on github.io).
Description:
package:ffigen
allows Dart to interact with ObjC. Swift modules can be invoked from ObjC (and Dart through ffi), but only if the classes and methods have been annotated with @objc
. So if a user wants to interact with a Swift module they don't own from Dart, they need to write a wrapper module that mirrors the API, but has @objc
annotations.
It should be possible to write a tool that can automatically generate this ObjC compatibility wrapper. The official Swift parsing library is written in Swift, so the tool should probably also be written in Swift. In fact, the candidate doesn't even really need any Dart experience, just Swift and ObjC.
Good Sample Project: Use the Swift parsing library to load a module and print some of its metadata (e.g. print a list of the classes in the module).
A great project proposal will also talk about which Swift language features can be feasibly supported by this tool. For example, is it possible to write an @objc
wrapper method for an async
Swift method? What would that look like? Swift is a modern language, and ObjC is not, so there are probably a lot of features that will be problematic to wrap in a compatibility class.
Expected outcome: A dart package available on pub.dev.
yousefi@google.com
Description: With JNIgen, we bridge between Dart and Java by generating Dart bindings for Java classes. Sometimes however, the semantic differences between the languages means that we want to make some changes to these bindings. For example, accessing the i
th element of an List
in Java is done by list.get(i)
but in Dart we can do list[i]
. To facilitate these changes, we want to introduce a transformation mechanism.
Specifically we want to add the ability to rename, exclude, convert to operators, add members, and generally transform the classes and methods using visitor pattern. Something like this:
Config( visitors: [Foo2BarRenamer()], // User passes the visitor to config ); class Foo2BarRenamer extends JnigenVisitor { void visitClass(Class c) { if (c.name == 'foo') c.name = 'bar'; c.visitMethods(this); // ... } // ... }
Good Sample Project: Create a simple renamer/excluder visitor, so JNIgen users can pass that in, and rename/exclude classes, methods, and fields. You will have to create a user-facing AST that wraps the original AST. For the sample project, the wrapper AST could only expose name
or included
properties.
Feel free to email me and ask further questions about the project!
Expected outcome: A new set of features for package:jnigen
.
Possible Mentor(s): camillesimon@google.com
, bquinlan@google.com
Difficulty: Hard
Project size: Large (350 hours)
Skills: Dart, Java, Android
Description: Write a flutter plugin that wraps the OkHttp package using package:jnigen
and implements the package:http
Client
interface. Time permitting, the plugin will also implement the package:web_socket_channel
WebSocketChannel
interface. This will allow us to provide several features requested by our users such as:
KeyStore
PrivateKey
s (#50669)Successfully completely this project will likely involve:
package:jnigen
.package:http
Client
implementation using those bindings.Client
implementation passes the conformance tests.You'll like working on this project because:
A good project proposal will describe what Java APIs are necessary to implement the package:http
Client
interface e.g. OkHttpClient.newCall()
. An excellent proposal will use asynchronous APIs.
Good Sample Project: Try writing a small Flutter application that makes HTTP requests using OkHttp bindings created with package:jnigen
. You can use package:cronet_http
and package:java_http
as starting points.
[!TIP] Look at the
package:cronet_http
jnigen.yaml and build.gradle files.
Expected outcome: A dart package available on pub.dev.
package:webcrypto
jonasfj@google.com
, chinmoy12c@gmail.com
Description: package:webcrypto
(github.com/google/webcrypto.dart) is a cross-platform implementation of the Web Cryptography API. It is important that it behaves the same way whether it's running on Windows, Linux, Mac, Android, iOS, Chrome, Firefox, or Safari. Towards that end, it has a lot of test cases. We could and should probably make more test cases. But we should also test that it throws the types of exceptions when given incorrect parameters. This probably needs a small test framework to ensure good test coverage.
We expect a proposal for this project to include:
RsaPssPrivateKey.generateKey
. Ideally, the sample project includes parts of a generalized framework for testing exceptions.TestRunner
, or creating a new framework, to test exceptions thrown by all methods.Good Sample Project: Write a test cases that tests the different kinds of errors and exceptions that can be thrown by RsaPssPrivateKey.generateKey
, run the tests across desktop, Chrome and Firefox. Consider extending the tests to cover all members of RsaPssPrivateKey
. Try to generalize these test cases to avoid repetitive code, see the existing TestRunner for inspiration.
Expected outcome: PRs that land in package:webcrypto
and increases our confidence in correctness cross-platforms.
jonasfj@google.com
, chinmoy12c@gmail.com
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:
package:analyzer
to extract documentation comments.package:markdown
to extract code samples.dart analyze
on the code sample,dart format
, and/or,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:
main
function?main
to keep it simple?main
?// ignore: unreachable
comment)?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 stretch 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.
Useful hints: analyzer tutorial | analyzer API docs | analyzer file_system abstraction.
Copy this template.
Description: ...
Good Sample Project: ...
Expected outcome: ...