-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Google Summer of Code 2020
Please apply for GSoC 2020 through Google’s Site GSoC '20 Website. All applications have to go through Google.
We will be receiving applications within the timeframe allocated by GSoC. Please consult the GSoC '20 website for details. For bite-sized issues to work on as part of the community introduction phase, please see the help wanted issue list.
This is the list of projects we are proposing for the summer; you can choose one or more projects from the list, or come up with your own project. Also note that these projects could be worked on outside GSoC if you would like to volunteer during the summer.
Follow these instructions to apply. Also note that you will have to go through the normal application in the GSoC '20 website and register yourself as a student.
This is what you might expect from projects in the list below:
-
Brief explanation: An explanation of what the project is about. Please note that this might be just an idea, and as part of your work in the project you will be defining and scoping the project.
-
Expected results: What would be expected from this particular project at the end of the summer. Again, this might not be super specific at this stage, and the expected results might change and be redefined during the summer.
-
Knowledge Prerequisite: A brief list of the technologies needed in order to work on this project.
-
Difficulty and estimated time: An estimation of the effort needed for the particular project (legend:
Easy || Medium || Hard) and a rough estimation if the project would take the whole summer, or less than that. -
Mentor: The currently active team member you will probably be working with during the summer (this can also change depending on which projects are chosen).
Several projects involve the App Inventor Blocks editor. The main language used in these projects is JavaScript with the Google Closure and Blockly libraries.
Brief explanation: Nobody writes perfect code, so a key skill that developers need to learn is how to effectively use tools for debugging code. App Inventor lacks debugging tools that are typically found in other development environments, such as the ability to review a stack trace when an error occurs, or to pause and resume execution when conditions are met to inspect the state of the program. This project will begin by implementing a stack capture and viewer tool, and time permitting will explore the challenges of implementing a "stepper" debugger.
Difficulty and estimated time: Advanced. This project will take the whole summer, and is recommended for GSOC applicants who have some experience working with App Inventor already.
Knowledge Prerequisite: JavaScript, and some Java. Familiarity with Scheme is highly desirable.
Mentor: Evan Patton
Brief explanation: In many parts of App Inventor, numeric constants are used for properties that would be better served by using enumerations, which could be internationalized to be more approachable to our audience. This project would take a prototype of an enumerations block, make the behaviors around enumerated blocks standard across the code base, and make the code production ready.
Difficulty and estimated time: Moderate. We anticipate that this project will take the whole summer.
Knowledge Prerequisite: JavaScript and Java.
Mentor: Evan Patton
A number of improvements for the Designer view. This part of the system is built mainly with Java using the Google Web Toolkit.
Brief explanation: The current designer only allows uploading one asset at a time. If you need to upload 10 images, you need to do the process 10 times. It would be a much better experience to be able to upload a number of assets in one go.
Expected results: An improvement in the currently existing file chooser that allows multiple uploads for assets.
Difficulty and estimated time: Easy; no more than a couple of weeks including testing.
Knowledge Prerequisite: Java and familiarity with GWT.
Brief explanation: It would be very useful to be able to download the sources or the apk directly from the projects page.
Expected results: A new layout for the My Projects page from which a new set of options for downloading different packages are shown. There's some initial work done on this so it could be expanded during the summer.
Knowledge Prerequisite: Java and familiarity with GWT.
Difficulty and estimated time: Easy; 3 to 4 weeks including testing.
Brief explanation: App Inventor has implemented a JUnit framework for automated testing of our Java codebase. However, great strides still need to be made in testing coverage of existing code, including the design of meaningful automated tests.
Expected results: Accurate, meaningful test suites for at least one existing component in App Inventor that demonstrates comprehensive knowledge of the functionality of the component. Preferably, this will be complete for several components, but exact scope will be set as we discover together the effort and time involved.
Knowledge prerequisite: JUnit, Roboelectric Android framework
Difficulty and estimated time: Medium; meaningful work can be complete in 1-2 months. It can easily be extended into an all-summer project.
Brief explanation: Currently components as Sprites have to be manually added to a Canvas to be able to use them. In situations like games, it would be a lot more useful if Sprites could be instantiated and created when needed. In Scratch this functionality is called cloning and it would be a great starting point to see how cloning works to design a similar feature in App Inventor.
Expected results: An option for components to be instantiated from the blocks; note that this project would need a design proposal and some research and prototyping.
Knowledge Prerequisite: Java and familiarity with GWT and the Android SDK.
Difficulty and estimated time: Medium; this would be a whole summer project.
Synopsis: Use the App Engine Task Queue for long running operations such as uploading a project or downloading multiple (or all) projects.
Brief Explanation:MIT App Inventor runs on the Google App Engine infrastructure. A limitation of App Engine is that operations must complete in under 60 seconds. However we have some operations, such as downloading multiple projects, that can exceed this time limit. However App Engine does provide a background mechanism, the Task Queue, where longer running operations can happen. This project is to re-factor long running operations to make use of the Task Queue. Expected Results: MIT App Inventor users will be able to download multiple projects, and or upload large projects without triggering the 60 second time limit. Knowledge Prerequisite: Java and the Google Web Toolkit as well as familiarity with Google App Engine. Difficulty and estimated time: Medium: 1-2 Months
Add Microsoft OAuth Add Apple OAuth
This is a list of more research oriented projects. They might not be merged into the main repository straight away, but prototyping projects are very important in Open Source.
Brief explanation: To develop a more cohesive approach to data and device management, we would like to provide higher level abstractions in MIT App Inventor representing robots, IoT devices, and data sources, and develop corresponding components that can interact with these entities (see visualization entry above as an example).
Expected results: Design and implement interfaces for one of robotics, IoT microcontrollers, or data sources, and some corresponding blocks for manipulating those items.
Knowledge Prerequisite: Java, design patterns
Difficulty and estimated time: Hard; we anticipate the initial design to go through a few iterations before implementation of a proof of concept. If one project is successful and does not take the whole month, we will use the remainder of the summer to explore similar techniques for the other entity types provided above.
Brief explanation: Work has been done during the last few GSoC sessions in developing a Component Developer’s Kit to App Inventor. This facility provides for loading externally developed components into App Inventor. However this work is currently limited in scope. In particular only components that have no visible UI elements can be added. We would like to extend the CDK capabilities to include extensions with UI elements. Extensions are currently only available in English. We would like an enhancement to that extension writers can provide strings in other languages as well, as is the case with builtin components.
Expected results: The ability to build and add extensions with text in non-English languages as well as access to UI elements.
Knowledge Prerequisite: Java and familiarity with GWT and the Android SDK. Familiarity with systems integration, release management, and systems architecture is a plus.
Difficulty and estimated time: Hard; this would be a whole summer project.
Add the ability to add built-in blocks Extensions Library Brief Explanation: As described in the previous project, we now have the ability to add external extensions to App Inventor. We would like to host a library of potential extensions that people might want to add to their projects. This might include extensions that use Bluetooth Low Energy to interface with the Internet of Things. Remote sensors, Arduino’s or other external devices that someone might want to interact with from their phone or tablet.
Expected results: A working extension that performs a useful task that can be loaded into App Inventor.
Knowledge Prerequisite: Java and familiarity the Android SDK. Knowledge of any devices you might want to interface with.
Difficulty and estimated time: Moderate; The exact amount of work will depend on the complexity of the proposed extension.