Skip to main content Link Menu Expand (external link) Document Search Copy Copied
YouTube Logo Google Group Logo Facebook Logo Twitter Logo

Ideas Page for Google Summer of Code 2017

We are thrilled to share our carefully curated project ideas for this year’s Google Summer of Code.

Idea Overview

General Knowledge Prerequisites for all Projects

  • Knowledge in the usage of Git and GitHub
  • Basic knowledge in the concepts of software testing (e.g., test doubles) and test-driven development
  • Basic knowledge in app development (for Android and iOS projects)
  • Java, JUnit, Mockito, Robotium and Espresso for Android development
  • Swift and Objective C for iOS development
  • Also please check that you have the proper hardware for the development (e.g., a Android/iOS smartphone for testing, Mac for iOS development)

Project Descriptions

HTML5 Physics Engine

Brief explanation and expected results:

PocketCode provides several code bricks for physics-enabled sprites:

  • SetPhysicsObjectTypeBrick
  • SetVelocityBrick
  • RotationSpeedLeftBrick
  • RotationSpeedRightBrick
  • SetGravityBrick
  • SetMassBrick
  • SetBounceFactorBrick
  • SetFrictionBrick
  • WhenCollisionBrick

A basic implementation of the bricks is already available (setter, getter) but these values are currently not supported (ignored). The physics engine will take care of these settings and render the physics states parallel to our current rendering engine supporting the same interfaces. The engine should work on desktop and mobile browsers. Some tasks you will have to accomplish:

  • Work on the specification together with your mentor
  • Calculate vertices from images
  • Replace the current look object with a physics object (physics sprite)
  • Calculate physics states of all physics objects per rendering frame
  • Rewrite existing code where conflicts occur between rendering engines (ifOnEdgeBounce, rotationType, whenCollision, ..)
  • Unit- & integration- testing (several devices, browsers, ..)
  • …

Desired Outcome: HTML5 Player supporting all physics bricks

Possible Mentors:

  • Matthias

iOS: Implementation of missing Bricks and Sensors

Brief explanation and expected results:

In order to be able to support Catrobat Language version 0.991 it is necessary to implement a set of missing Bricks and Sensors. New Bricks:

  • CameraBrick
  • ChooseCameraBrick
  • IfThenLogicBeginBrick
  • RepeatUntilBrick
  • WhenTouchDownBrick

New Sensors:

  • screen_touch_x
  • screen_touch_y
  • screen_touch_x(1)
  • screen_touch_y(1)
  • screen_is_touched(1)
  • last_screen_touch_index
  • color

Tasks your have to accomplish:

  • Create data models for new Bricks
  • Implement serialization and deserialization
  • Implement Brick visualization and related UI actions
  • Implement new logic in Player Engine
  • Write unit & integration tests

Desired Outcome: Support of all Bricks and Sensors for Catrobat Language version 0.991 (except physics bricks)

Possible Mentors:

  • Michael

Catroid-Core: Refactoring Code

Brief explanation and expected results:

Refactor code to improve:

  • readability
  • maintainability
  • testability
  • PMD, CPD, Findbugs and LINT checking

Architectural changes to

  • comply with Android guidelines
  • comply with software design patterns
  • enforce testability and introduce and enforce the use of MOCKing
  • give architectural overview as documentation for future developments with tangible examples

Desired Outcome: Slimmer, maintainable, clean code compliant, more stable, more robust, Pocket Code version using architectural Patterns rather than Antipatterns

Possible Mentors:

  • Christian

Catroid-Core: Refactoring Ui Tests

Brief explanation and expected results:

  • Transition from Robotium to Espresso framework for the GUI-tests and therefor getting rid of unnecessary waits
  • Get rid of Polidea testrunner
  • Get rid of redundant, flaky and broken tests
  • Create meaningful tests compliant with clean code rules
  • Get rid of reflections
  • Get rid of reflections in tests to introduce and enforce the use of MOCKing
  • Setting up proper gradle tasks and jenkins integration
  • Create guidelines as documentation in confluence how to test in this project with tangible examples

Desired Outcome: Refactored, slimmer test harness using Espresso instead of Robotium and introduce and enforce the use of Mocking framework

Possible Mentors:

  • Thomas

Catroid-Core: Refactoring Unit Tests

Brief explanation and expected results:

  • Review of existing JUnit tests and splitting them in two groups, actual Unit tests and Integration tests
  • Re-implement subset of UiTests that do not require a Ui as integration/unit tests
  • Get rid of Polidea testrunner
  • Get rid of redundant, flaky and broken tests
  • Create meaningful tests compliant with clean code rules
  • Get rid of reflections
  • Get rid of reflections in tests to introduce and enforce the use of MOCKing
  • Setting up proper gradle tasks and jenkins integration
  • Create guidelines as documentation in confluence how to test in this project with tangible examples

Desired Outcome: Refactored, slimmer and more robust JUnit tests, introduction of a new test group of integration tests (technically based on JUnit), and enforce the use of Mocking framework

Possible Mentors:

  • Wolfgang

Catroid-Core: Refactor/Introduce Flavoring (Flavoring NEW)

Brief explanation and expected results:

  • Meaningful, stable, robust, way to activate additional unique features in Pocket Code which are not the core functionality like, e.g., education features needed for school courses (Dashboard, Analytics)
  • Feature de/activation must have an impact on the size of the APK - in terms of footprint of the resulting APK, the less flavor features are activated the smaller the footprint

Desired Outcome: Working flavoring as a base for integration of Pocket Paint and other functionality beside the core Pocket Code functionality

Possible Mentors:

  • Bernadette

Pocket Code - Pocket Paint: Integrate Pocket Paint AS a Flavor into Pocket Code

Brief explanation and expected results:

  • Pocket Paint should be a flavor of Pocket Code. This makes sense to integrate Pocket Paint into Pocket Code (no need to install both anymore). But it also allows to publish Pocket Paint still as a standalone app in the Google Playstore, as until now.
  • Pocket Paint should be integrated into Pocket Code in a way that it can be set to be build as a standalone APK and also published as such in the Google Playstore.
  • The footprint must be according the used features - smaller than with activated Pocket Code.

Desired Outcome: Make Pocket Paint a flavor of Pocket Code

Possible Mentors:

  • Annemarie

UX Redesign of Pocket Code

Brief explanation and expected results:

  • Redesign GUI for Pocket Code - look and feel as it was done in Pocket Paint the last year
  • Detailed Guideline for the Redesign, in respect of material design, will be provided

Desired Outcome: Redesign of all GUI Elements according the current Android and the worked out UX guidelines

Possible Mentors:

  • Sebastian

iOS: Create your own Bricks - User Bricks

Brief explanation and expected results:

User Bricks provide the functionality to create custom scripts which allow one to reuse user-defined functionality across objects without duplicating Bricks. This is the Catrobat-equivalent to “Custom Blocks” in Scratch. Tasks you have to accomplish:

  • Create data model
  • Implement serialization and deserialization
  • Provide a user interface to create and edit User Bricks
    • Each User Bricks consists of a header and a number of normal Bricks
    • The header of a User Brick can contain text and variables which can be used within the User Brick
  • Integrate in Player Engine
  • Write unit & integration tests

Desired Outcome: User should have the possibility to create custom scripts which can be reused without duplicating Bricks

Possible Mentors:

  • TBA

HTML5: UserBricks (Scripts + CallUserScript)

Brief explanation and expected results:

Parser: Parsing the user scripts (early version) is already available in our backend (PHP). There may be the need of customization the parser and adding unit tests for the backend. Client:

  • load the userScripts into our gameEngine
  • brick logic for calling the scripts
  • adjusting parser/formula objects to execute code in a new scope (e.g., using script parameters instead of local/global variables)
  • extend the sprite cloning brick to clone the user scripts as well if necessary
  • make sure the stopScriptBrick is handled correctly when placed inside a userScript
  • unit + integration testing (several platforms, browsers, ..)

Desired Outcome: HTML5 Player supporting user defined scripts and the brick calling theses scripts

Possible Mentors:

  • TBA

Pocket Code: Inclusion of Firebase

Brief explanation and expected results:

  • Integrate Firebase Funnels feature to track success rate of login, etc.
  • Integrate Firebase FCM (Firebase Cloud Messaging) feature so we can notify our user of cool coding events.
  • Improve manual bug reporting to also report defects which doesn’t cause the app to crash.
  • Fix Firebase crash reports.

Desired Outcome: Firebase implemented in Catroid and producing useful output

Possible Mentors:

  • Robert

Your own Project Ideas

Please do not hesitate to bring forward your own ideas and discuss them with the Catrobat team members at #catrobat on Freenode or by contacting us via https://catrob.at/mailinglist!