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 2018

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

Idea Overview

General Information

These ideas are just some topics we came up with, where currently nobody is working on. However, Catrobat is a project with a wide range of possibilities and we’re aware of our blindspots: So let’s live the spirit of Open Source and come up with improvements (e.g., new features, extensions, …) that are related to the project and in which you’re interested in. We do have many senior contributors who would be happy to mentor such a project. Don’t be shy and check out the last point on the list: Your idea!

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

Include Paintroid into Pocket Code

Brief explanation and expected results:

Make Pocket Paint a subproject of Pocket Code: Currently Pocket Paint is an individual app on Google Play. However, since it is primarily used in connection with Pocket Code, it makes sense to merge these two apps into one. Instead of being an individual app, we want it to be included into Pocket Code - keeping the same functionality, but improving the User Experience for the user. Several challenges occur that will have to be considered for this project: How do modularize the code to make keep it maintable and keep a good performance? How to test it properly? How to resolve issues that result from the fact that these have been two different projects in the past? And also are there parts of the code that might be refactored during this process easily?

More Information:

  • Pocket Paint should get integrated into Pocket Code
  • The final outcome should be a subproject similar to Pocket Music
  • Remove any memory hogs (singletons, unecessary static variables)
  • Merge activites which offer functionality already present in Pocket Code (e.g. language selection)
  • Adapt namespaces
  • Refactor unit and integration tests
  • Move resources and assets (Reuse if possible)
  • Integrate strings from crowdin, avoid duplication if possible

Testing, Testing, Testing

Brief explanation and expected results:

increased code coverage, consolidated and more stable test setup, production code refactored with a focus on better testability

Desired Outcome:

Code coverage wise theres a lot of work to do. The recent frontend refactoring that switched big portions of the ui to now utilize android recycler view only comes with a rather basic set of tests, more tests have to be put in place here. Theres quite a lot of room for improvement when it comes to testable code, eg. encapsulating storage handling, problems that arise due to handing context deeper and deeper into classes that should not need it in the first place, etc. Those should be refactored and tests cleaned up accordingly. Also going hand in hand with the task above, refactoring the existing test utilities (especially with unit tests) to enforce a more object oriented approach towards testing. (Historically in this project tests were almost exclusively treated as if one could only use an imperative approach for writing tests) Unit and Espresso test sets are currently running on our Jenkins instances, but a few subsets of tests are currently not part of any automated run, eg. device tests, sensor test box tests, etc. Jenkins jobs for those subsets should be written, the existing test annotations can be used, and all jobs should be consolidated.

Refactoring Part 2: Bricks

Brief explanation and expected results:

UI and Interpreter are completely separate. UI adheres to Material Design Guidelines.

More Information:

In GSoC 17 the UI was refactored, however, the Bricks are still unchanged. The Bricks as a visual representation of the LibGdx actions should be completely separate. Standalone APKs would then finally be independent from the UI. he storage handling and the hierarchy suffered greatly when Scenes were introduced, this has to be changed. The internal structure of scripts is horrific → lists with dependencies and duplicate cross references. A solution would be to implement a tree structure instead (but could also be something else). Broadcasting is currently being refactored, but integration is still an open and hot topic.

iOS: Devices Sensors and Code Refactoring

Brief explanation and expected results:

Match iOS sensor ranges with Android specification. The student needs to come up with a design to enforce testability and the use of Mocking

More Information: Devices Sensors and Code Refactoring:

The Pocket Code app makes use of a variety of device sensors like inclination, compass, loudness, face detection and much more.

On both, the Android and the beta version of iOS, called “Catty”, these sensors are widely used in a large number of user-built programs.

Current Situation:

The Android version of Pocket Code and Catty are currently handling sensors in a different way resulting in a varying interpretation of sensor values (e.g. differing ranges of values). Additionally, many sensors get initialised with a differing default value.

Due to these deviations, many Catrobat programs behave differently depending on whether executed on the Android or Catty version.

Planned Improvements:

Catty should be refactored so that the handling of sensors, the conversion of ranges and the initialisation happens in a synchronized, highly performant and more-readable way.

Additionally, a suitable test framework for sensors needs to be introduced. The student needs to come up with a design to enforce testability and enforce the use of Mocking.

Robotic arm for testing device sensors

Brief explanation and expected results:

A Framework for automated testing of Device’s sensor with a Roboarm connected to Jenkins

More Information:

Include a Roboarm (e.g.such one available from Conrad) into the automatic Jenkins test pipeline to test following sensors:

  • accelleration
  • magnetic sensor
  • Proximity sensor
  • Inclination x/y/z

The robotic arm is to be interfaced with a Raspberry Pi. An Android testdevice is to be mounted on the robotic arm in a way, that it can be easily unmounted, that it has working USB Connection to the Jenkins, to upload the testsuite and run the tests. A REST-ful service has to be implemented which runs on the Raspberry Pi which takes commands to move the robotic arm in a way which is needed for testing the sensors in the device. The server mus be accessible via the network and accept command from the tests running on the device. Tests for this device test suite for the aforementioned sensors are to be written, that the device can be moved with the robotic arm and the sensor data can be read out and compared to expected values. A jenkins test job has to be implemented to run the sensor-tests on the device.

Scratch compatibility - Color Collision

Brief explanation and expected results:

Bricks for Collisions: Object-with-Color: object with color in backgorund or other sprite; Color-with-Color: define a color of a sprte colliding with another color

More Information:

For collision detection it should be possible to define a color that an object collides with either in the backgorund or in any other sprite on the screen. Next step is to detect that a certain color of the sprites collides with a certain color in backgorund or in any other sprite. Here must be paid attention to the position of the layer the sprite is rendered to in terms of visibility of the color which is to be tested for collision with the sprite. E.G., if a color which is to be tested for collision is already coverd by a sprite NOT containing this color, the sprite which tests for collision is to be rendered above this aforementioned sprite - no collission is to be detected. Another case must be considered, if the the sprite checking for collision with color is covered by another sprite NOT contining the color, and another sprite contining the color is renderd above both of them - no collission is to be detected. In Detail there are more cases as such which musst be carefully determined and tested, that the color collision works the same like in Scratch.

  • UI feature to select colors (sprite or a background)
  • implementation to behave like Scratch color collision
  • run-time optimization/scalability: it must be possible to check for collision with colors with an arbitrary number of objects rendered to the screen

Scratch compatibility - Missing Bricks

Brief explanation and expected results:

Since Catrobat got inspired by Scratch and other visual programming languages, we also want to provide similar features, to make it young users as easy as possible to switch between those. Thus, certain features, beside the color collision, still need to be implemented in Pocket Code.

More Information:

  • Timer Sensor: Implement a Timer value as sensor, that starts when the program starts and also include a new brick to reset this timer to 0.
  • Set Volume for Sprites: Currently the “set volume brick” sets the volume for the whole app. However, it would have a huge benefit if you could also set the volume for certain sprites too.
  • Volume-Sensor Value: As mentioned above it should be possible to set the volume individually for each sprite. But, as an extension it afterwards should also be possible to access this volume as sensor-value from other sprites.
  • Show/Hide List: Currently there is just the Show/Hide Variable Brick. Similar to that it should be also possible for lists.
  • Extend “Distance to”: Currently “Distance to” in the formular editor just allows you to get the distance to the last touch-position on the screen. This feature should be extened by also adding the possibility to get the distance to another object (you may select in the formula editor)
  • Delete everything from list: Implement a special brick that deletes all elements from a list. Do not just use a loop therefore, try to find a fast and elegant solution to achieve this.

Google Blockly integration

More Information: Google Blockly is a library for building visual programming editors.

Google Blockly is increasingly being used as a platform for visual programming languages such as Scratch 3.0, AppInventor, and code.org. Especially the actively developed Scratch 3.0 instantiation is very congruent with Catrobat, since Catrobat was initially modeled after Scratch.

Current Situation:

Catrobat bricks used in scripts that are manipulated in the IDE part of Catroid (Android code base of Pocket Code and its flavors) and Catty (iOS code base of Pocket Code and its flavors), as well as the script preview on the sharing platform of Catrobat (Catroweb), all use our own visualizer. They display the scripts in a linear way, without the typical C and E nested bricks as known from Scratch and Blockly.

Planned Improvements:

We want to use the Scratch variant of Blockly to display Catrobat scripts and bricks in a webview. In a first step, the passive script preview on the sharing platform of Catrobat (Catroweb) should use Blockly instead of our current code base. One important issue that needs to be addressed is to use the correctly translated strings (localization, including for right to left languages such as Arabic). In a next step, this visualization of bricks shall also be used in a webview in Catroid and Catty, as an alternative way to display scripts and blocks, on an infinite virtual plane. For the two apps, it should be possible to switch back and forth between the read-only Blockly view and our current view of the scripts. Another important consideration needs to be that we want to be able to keep important the Blockly/Scratch 3.0 code repeatedly indefinitely in the future in order to be able to incorporate bug- and security fixes as well as feature enhancements.

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!