forked from Catrobat/catrobat.github.com
-
Notifications
You must be signed in to change notification settings - Fork 0
/
gsoc_2018_ideas_page.html
241 lines (218 loc) · 17.9 KB
/
gsoc_2018_ideas_page.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="chrome=1">
<title>Ideas Page</title>
<link rel="stylesheet" href="stylesheets/styles.css">
<link rel="stylesheet" href="stylesheets/pygment_trac.css">
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">
<!--[if lt IE 9]>
<script src="//html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
</head>
<body>
<div class="wrapper">
<header>
<h1>Catrobat</h1>
<p>
A visual programming language
<br/>
and set of creativity tools
<br/>
for smartphones, tablets,
<br/>
and mobile browsers
</p>
<p class="view">
<a href="http://www.catrobat.org/">Home</a>
</p>
<p class="view">
<a href="http://developer.catrobat.org/">Developers' Home</a>
</p>
<p class="view">
<a href="http://developer.catrobat.org/first_steps">First steps into Catrobat</a>
</p>
<p class="view">
<a href="http://catrob.at/pc">Find Pocket Code on Google Play</a>
</p>
<p class="view">
<a href="http://catrob.at/plus"><img src="googleplus.png" height="20px"/></a> <a href="http://catrob.at/fb"><img src="facebook.png" height="20px"/></a> <a href="http://catrob.at/pctwitter"><img src="twitter.png" height="20px"/></a> <a href="http://catrob.at/youtube"><img src="youtube.png" height="20px"/></a> <a href="http://catrob.at/mailinglist"><img src="google-group.png" height="20px"/></a> <a href="http://catrob.at/github"><img src="github.png" height="20px"/></a> <a href="mailto:contact@catrobat.org"><img src="mail.jpg" height="20px"/></a>
</p>
</header>
<section>
<h2>Ideas Page for Google Summer of Code 2018</h2>
<br />
<strong>Welcome,
<br />
we officially present our project ideas for this year's Google Summer of Code.</strong>
<br />
29 Jan 2018</p>
<p>
<strong><u>General knowledge prerequisites for all projects</u>
<br />
<i>JUnit, Robotium and Espresso for test-driven development on Android devices (Pocket Code and Pocket Paint), basic knowledge in app development (Android or iOS, depending on the project) and of course Git (revision control) for all projects. Also please check that you have sufficient hardware (e.g. a Android/iOSsmartphone for testing) for the development, since we can't provide you any for the coding period. </i></strong>
</p>
<p>
<strong><u>General information about the ideas</u>
<br />
<i>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 feautes, extensions,...) that are related to the project and 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!</i></strong>
</p>
<p>
<h3>Overview:</h3>
<ul>
<li>
<a href="#idea_1">Include Paintroid into Pocket Code</a>
</li>
<li>
<a href="#idea_2">Testing, Testing, Testing</a>
</li>
<li>
<a href="#idea_3">Refactoring Part 2: Bricks</a>
</li>
<li>
<a href="#idea_4">iOS: Devices Sensors and Code Refactoring</a>
</li>
<li>
<a href="#idea_5">Robotic arm for testing device sensors</a>
</li>
<li>
<a href="#idea_6">Scratch compatibility - Color Collision</a>
</li>
<li>
<a href="#idea_7">Scratch compatibility - Missing Bricks</a>
</li>
<li>
<a href="#idea_8">Google Blockly Integration</a>
</li>
<li>
<a href="#youridea">Your idea</a>
</li>
</ul>
</p>
<p>
<h3> Projects </h3>
<a id="idea_1"><strong>Title:</strong> Include Paintroid into Pocket Code</a>
<br />
<strong>Brief explanation and expected results:</strong>
<p>Make Pocket Paint a subproject of Pocket Code: Currently <a href="http://catrob.at/pp">Pocket Paint</a> 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?
</p>
<strong>More Information:</strong><i></i><br/>
<ul><li>Pocket Paint should get integrated into Pocket Code<em><br></em></li><li>The final outcome should be a subproject similar to Pocket Music</li><li>Remove any memory hogs (singletons, unecessary static variables)</li><li>Merge activites which offer functionality already present in Pocket Code (e.g. language selection)</li><li>Adapt namespaces</li><li>Refactor unit and integration tests</li><li>Move resources and assets (Reuse if possible)</li><li>Integrate strings from crowdin, avoid duplication if possible</li></ul>
<p />
<hr>
<a id="idea_2"><strong>Title:</strong> Testing, Testing, Testing</a>
<br />
<strong>Brief explanation and expected results:</strong>
<p> increased code coverage, consolidated and more stable test setup, production code refactored with a focus on better testability
</p>
<strong>Desired Outcome:</strong><i></i><br/>
<strong>More Information:</strong><br/>
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.<br/>
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.<br/>
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)<br/>
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.
<p />
<hr>
<a id="idea_3"><strong>Title:</strong> Refactoring Part 2: Bricks</a>
<br />
<strong>Brief explanation and expected results:</strong>
<p>UI and Interpreter are completely separate. UI adheres to Material Design Guidelines.
</p>
<strong>More Information:</strong><i></i><br/>
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.<br>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<br>a tree structure instead (but could also be something else). Broadcasting is currently being refactored, but integration is still an open and hot topic.
<p />
<hr>
<a id="idea_4"><strong>Title:</strong> iOS: Devices Sensors and Code Refactoring</a>
<br />
<strong>Brief explanation and expected results:</strong>
<p>Match iOS sensor ranges with Android specification. The student needs to come up with a design to enforce testability and the use of Mocking
</p>
<strong>More Information:</strong><i></i><br/>
<strong>Devices Sensors and Code Refactoring</strong></p><p>The Pocket Code app makes use of a variety of device sensors like inclination, compass, loudness, face detection and much more.</p><p>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.</p><p><strong>Current Situation:</strong></p><p>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.</p><p>Due to these deviations, many Catrobat programs behave differently depending on whether executed on the Android or Catty version.</p><p><strong>Planned Improvements:</strong></p><p>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.</p><p>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.</p><br>
<p />
<hr>
<a id="idea_5"><strong>Title:</strong> Robotic arm for testing device sensors</a>
<br />
<strong>Brief explanation and expected results:</strong>
<p>A Framework for automated testing of Device's sensor with a Roboarm connected to Jenkins</p>
<strong>More Information:</strong><i></i><br/>
<p>Include a Roboarm (e.g.such one available from <a href="https://www.conrad.com/ce/en/product/191516/Arexx-RA1-PRO-Metallic-Robot-Arm">Conrad</a>) into the automatic Jenkins test pipeline to test following sensors:
<ul>
<li>accelleration</li>
<li>magnetic sensor</li>
<li>Proximity sensor</li>
<li>Inclination x/y/z</li>
</ul>
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.
<p />
<hr>
<a id="idea_6"><strong>Title:</strong> Scratch compatibility - Color Collision</a>
<br />
<strong>Brief explanation and expected results:</strong>
<p>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
</p>
<strong>More Information:</strong><i></i><br/>
<p>
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.
<ul>
<li>UI feature to select colors (sprite or a background)</li>
<li>implementation to behave like Scratch color collision</li>
<li>run-time optimization/scalability: it must be possible to check for collision with colors with an arbitrary number of objects rendered to the screen</li>
</ul>
<p />
<hr>
<a id="idea_7"><strong>Title:</strong> Scratch compatibility - Missing Bricks</a>
<br />
<strong>Brief explanation and expected results:</strong>
<p>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.
</p>
<strong>More Information:</strong><i></i><br/>
<p>
<ul>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>Show/Hide List: Currently there is just the Show/Hide Variable Brick. Similar to that it should be also possible for lists.</li>
<li>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)</li>
<li>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.</li>
</ul> <p />
<hr>
<a id="idea_8"><strong>Title:</strong> Google Blockly integration</a>
<br />
<strong>More Information:</strong><i></i><br/>
<p>
<strong>Google Blockly is a library for building visual programming editors.</strong><br/>
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.<br/>
<strong>Current Situation:</strong><br/>
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.<br/>
<strong>Planned Improvements:</strong><br/>
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. <p />
<hr>
<p>
<a id="youridea"><strong>Your own project ideas ... </strong></a>
<br />
<p> In the last year we made the experience that you have many great ideas and knowledge! Catrobat is currently still focusing on refactoring and we're aware that there are many ways how to improve performance, reduce memory usage, make our services more stable and of course the code easier to maintain. We're sure you do have ideas how to achieve this, although we maybe never heard of this approach before -> that's the great thing about Open Source! And well, that's also the experience we made at last year's GSoC - and we liked it!</p> But also new features or extensions for iOS and Android are welcome to be introduced to us. Help us to spread coding and Open Source!<br/>
Please do not hesitate to bring forward your own ideas and discuss them with our community on our mailing-list: <a href="http://catrob.at/mailinglist"><img src="google-group.png" height="20px"/> catrobat@googlegroups.com</a>!
</p>
</p>
</section>
</div>
<script src="javascripts/scale.fix.js"></script>
<script>
(function(i, s, o, g, r, a, m) {
i['GoogleAnalyticsObject'] = r;
i[r] = i[r] ||
function() {
(i[r].q = i[r].q || []).push(arguments)
}, i[r].l = 1 * new Date();
a = s.createElement(o), m = s.getElementsByTagName(o)[0];
a.async = 1;
a.src = g;
m.parentNode.insertBefore(a, m)
})(window, document, 'script', '//www.google-analytics.com/analytics.js', 'ga');
ga('create', 'UA-42270417-2', 'catrobat.org');
ga('send', 'pageview');
</script>
</body>
</html>