hej_wickie_hej wrote:

Thanks for the detailed feedback!

mobluse wrote:

I've tested it now after I received a nightly build (Andr.0.9.2-660-debug) that worked on my Android 4.2 device. PocketCode seems to be at the level of Scratch 1.2 http://wiki.scratch.mit.edu/wiki/Scratch_1.2 in that one have only numbers and no strings or lists.

That's right. We are working on strings right now as we need them ourselves for many things that will come soon. But since it is possible to make fairly sophisticated programs (see, e.g., examples at the end of this reply) with the current version, we wanted to make it available already now.

mobluse wrote:

But it also seems like PocketCode cannot get properties of other objects as you can in Scratch 1.2+.

Workaround: Store them in global variables and use those in the other objects.

mobluse wrote:

It also lacks Pen-blocks (e.g. stamp), timer, collision detection, and mousepointer as you have in Scratch 1.0+. Instead of mousepointer one could have last tap position so that one could implement drag and drop and move to the last tap position.

• Pen-blocks (e.g. stamp): On our todo list but not yet started.
  

• Timer: Workaround through loop and global variable.
  

I think that would result in programs running at different speeds on different phones. Timer should be easy to add and has been in Scratch since 1.0.

hej_wickie_hej wrote:

• Collision detection: We started working on it. In the mean time, you can use coordinate comparison as, e.g., in the Air Fight 0.5 program (https://pocketcode.org/details/965 ) or the Galaxy War shooter (https://pocketcode.org/details/719 ).
  

• Mousepointer:We currently only have a When tapped block, which by the way works in a multi-touch way. Because of the multi-touch feature of most devices, we thought we need lists before we can implement a coordinate reporter. On our todo list. We are also thinking of a simpler reporter that returns the coordinates of only one of the finger positions, as that may be sufficient in many situations.
  

mobluse wrote:

In Scratch you can switch costumes using numeric variables but that seems impossible in PocketCode.

Workaround: Use a local variable that keeps track of this number, and emulate the switching through a When I receive broadcast event script.

I don't understand how that would be an improvement. I want to avoid using gigantic if-else-ladders. Can you broadcast a message that is the value of a variable? In Scratch you can do this.

hej_wickie_hej wrote:

mobluse wrote:

It doesn't have floor and ceiling as in Scratch 2.0 (Workarounds for ceiling and floor using round, http://scratch.mit.edu/projects/10857110/ ).

Yeah, I agree that we need those. There's however the simple workaround which you mention.

mobluse wrote:

I often start my programs by writing big formulas directly as arguments but then I use the formulas to set variables. In this version of PocketCode one cannot move or duplicate formulas or parts of formulas.

Within an object, blocks can be copied with their formulas, but of course we want more and are already working on copy/cut/paste across objects and also across programs (= projects).

Blocks can be copied with their formulas but a block (e.g. a move-block) cannot be changed into a variable setting block. This means I have to type in the formula again.

hej_wickie_hej wrote:

mobluse wrote:

Also the Backpack doesn't seem to work (or I don't understand it). I think that these editing functions are most important. You can live with limitations in a programming language but you don't want to use an editor that forces you to retype code and delete code instead of moving it.

Coming, we are working on it.

mobluse wrote:

There are sensors called inclination_x and inclination_y. What are they? There seems to be no documentation.

We are working on the documentation, a lot of it will be out soon. inclination_x returns the inclination in degrees w.r.t. the x axis. If you insert only this reporter into the formula and hit the Compute button, you will see its value change while you move your device. The same works with all formulas, e.g., the magnetic sensor (deviation from north in degrees), accelerometer (m/s^2), etc.

It's good that compute shows the calculation in real time. It's unclear to me what you mean by inclination. In the Android-documentation they mean the geomagnetic inclination but that is only one value, not two (x and y), see http://developer.android.com/reference/android/hardware/SensorManager.html#getInclination(float) and http://www.celestron.com/c3/support3/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=2493 .

hej_wickie_hej wrote:

mobluse wrote:

Is it possible to import and export from and to Scratch 2.0 projects?

From Scratch: working alpha version, still very limited. Key event blocks are translated into new objects that have the key as its look (= costume), are positioned at the border of the screen, and that, when tapped, will send a broadcast message such as Key A was pressed. Where the key event blocks were in Scratch, When I receive “Key A was pressed” broadcast events are automatically inserted into the created Catrobat program (Catrobat is the name of the programming language, while Pocket Code is the name of the IDE). The idea is that this translated program, while working, will need some remixing, e.g., replacing the key objects with controls better suited for phones and tablets such as the inclination sensors.

But can I try this alpha version?

hej_wickie_hej wrote:

Other direction: difficult because of multi-touch, sensors, much higher resolution and different aspect ration (e.g., on the 2013 edition of the Nexus 7 you can use the full 1824x1200 dots for your programs), and many new things that will come soon, e.g., the physics engine. See http://developer.catrobat.org/ for some of the things to come, including videos.

I still think automatic conversion would be useful because then you would not have to retype an entire program. The sensors could be replaced by variables and the coordinates could be wrong in the translated program. If you are developing a Catrobat-program with the purpose to convert it to Scratch you would avoid using sensors and hardcode it to a particular screen resolution. Since Catrobat-programs are shared they shouldn't be hardcoded to a particular screen resolution anyway. Is there a programmatic way to get to know the screen resolution? In Scratch the coordinate system is always the same no matter what the screen resolution is.

hej_wickie_hej wrote:

mobluse wrote:

I found a bug: even though I removed some local variables, I can still select them when setting variables.

I just tried it myself but could not reproduce the problem. Could you describe it in a bit more detail, and possibly upload a program where the problem occurs? Please then post the link here with a short explanation how to reproduce the bug (we can later delete the uploaded program).

I uploaded a program called “Football Barbra Streisand” that demonstrates this bug. I downloaded it under a new name and this bug is still there.

hej_wickie_hej wrote:

By the way, you could also use our issue tracker on github to report bugs more formally. Links are given on http://developer.catrobat.org/ below the download links (“⇢ Known issues (report new!)”) for both Pocket Code as well as Pocket Paint.

I have not learned how to use Github yet.

hej_wickie_hej wrote:

mobluse wrote:

Another bug: Sound doesn't always start when you start a program, but always starts if you restart it.

Same as above, I could not reproduce it. Please upload a program where it happens, and post the link here with a short explanation what you experienced. Or on our issue tracker on github mentioned above.

This bug disappeared after I had uploaded the program above. I.e. I cannot currently reproduce it, but this bug was in “Football Barbra Streisand”.

hej_wickie_hej wrote:

mobluse wrote:

I think PocketCode is very limited now, but apart from emulators for TI-89, ZX81 and ZX Spectrum it is the best on phone development environment I know of. (Edit: There is a Matlab clone for Android that is comfortable to edit with.)

Thanks!

As I said, fairly sophisticated programs can be made already now, e.g., a tic tac toe program (https://pocketcode.org/details/817 ) that plays optimally (try to win against it, especially when you let it play as the first player), or the aforementioned Air Fight 0.5 shooter (https://pocketcode.org/details/965 ). Certain programs such as the Bubble Level program (https://pocketcode.org/details/718 ) can only be made on a device with the corresponding sensors. The bell (https://pocketcode.org/details/701 ) also makes sense only with accelerometer sensors, etc.

A problem can be that the users learn inefficient programming techniques (e.g. huge if-else-ladders) due to lack of lists and other flexible constructs such as switching costume using a numeric variable.

mobluse wrote:

hej_wickie_hej wrote:

• Timer: Workaround through loop and global variable.
  

I think that would result in programs running at different speeds on
different phones. Timer should be easy to add and has been in Scratch
since 1.0.

Loops have a built-in iteration delay, both in Scratch as well as in
Pocket Code (unless you turn on Turbo Mode in Scratch). This makes
sure that loops take the same amount of time on all devices.

And if you need a timer with a granularity of, e.g., 0.1 seconds, then
just insert “wait 0.1 seconds” and “change variable ‘timer’ by 1”
blocks in the loop.

mobluse wrote:

Can you broadcast a message that is the value of a
variable? In Scratch you can do this.

Sorry, not yet. One of the reasons is that we also have no character
strings in the public version yet – An alpha version of Pocket
Code with character strings and string manipulation operators exists
but it not yet ready for the public.

mobluse wrote:

hej_wickie_hej wrote:

mobluse wrote:

There are sensors called inclination_x and
inclination_y. What are they? There seems to be no
documentation.

We are working on the documentation, a lot of it will be out soon.
inclination_x returns the inclination in degrees w.r.t. the x
axis. If you insert only this reporter into the formula and hit the
Compute button, you will see its value change while you move your
device. The same works with all formulas, e.g., the magnetic sensor
(deviation from north in degrees), accelerometer (m/s^2), etc.

It's good that compute shows the calculation in real time. It's
unclear to me what you mean by inclination. In the
Android-documentation they mean the geomagnetic inclination but that
is only one value, not two (x and y), see
http://developer.android.com/reference/android/hardware/SensorManager.html#getInclination(float)
and http://www.celestron.com/c3/support3/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=2493
.

inclination x is the deviation of the positive x axis from the
flat position in degrees compared to the center of the device, where
positive values correspond to lifting your device on its right border.
Similar for y. If your device has inclination sensors, the easiest way
to understand it is to try it out with the compute button.

mobluse wrote:

hej_wickie_hej wrote:

mobluse wrote:

Is it possible to import and export from and to Scratch
2.0 projects?

From Scratch: working alpha version, still very limited. Key event
blocks are translated into new objects that have the key as its look
(= costume), are positioned at the border of the screen, and that,
when tapped, will send a broadcast message such as Key A was
pressed. Where the key event blocks were in Scratch, When I
receive “Key A was pressed” broadcast events are automatically
inserted into the created Catrobat program (Catrobat is the
name of the programming language, while Pocket Code is the name
of the IDE). The idea is that this translated program, while working,
will need some remixing, e.g., replacing the key objects with controls
better suited for phones and tablets such as the inclination sensors.

But can I try this alpha version?

Sorry, not at the moment, it is still too far from being ready for
outside inspection.

mobluse wrote:

hej_wickie_hej wrote:

Other direction: difficult because of multi-touch, sensors, much
higher resolution and different aspect ration (e.g., on the 2013
edition of the Nexus 7 you can use the full 1824x1200 dots for your
programs), and many new things that will come soon, e.g., the physics
engine. See http://developer.catrobat.org/ for some of the things to
come, including videos.

I still think automatic conversion would be useful because then you
would not have to retype an entire program. The sensors could be
replaced by variables and the coordinates could be wrong in the
translated program. If you are developing a Catrobat-program with the
purpose to convert it to Scratch you would avoid using sensors and
hardcode it to a particular screen resolution.

Sure, but why would you want to do that at all? Why not then program
it directly in Scratch?

mobluse wrote:

Since Catrobat-programs are shared they shouldn't be hardcoded to a
particular screen resolution anyway.

In Catrobat the screen resolution is handled in a different way than in Scratch. Catrobat to Scratch translation would in many cases result in thick black bars on the left and right parts of the stage in Scratch because of the totally different portrait-style aspect ratio of typical phones.

The reason is that we wanted to be able to take advantage of the full screen resolution of the phones, and also because of these strongly varying aspect ratios (e.g., phone in portrait mode versus tablet in landscape mode for the most extreme examples). After much thinking, deliberations, and tests with users, we decided to use the screen resolution of the initially shared program, and continue to use it from there on for all remixes of that program. The latter is necessary because of the use of formulas in scripts. Users can always decide how the program should be displayed during execution, i.e., stretched to the full screen (without preservation of the aspect ratio), or maximized to the screen under preservation of the aspect ratio, with black bars either on the sides or on the top and bottom of the screen. In the newest version, a default can be set by the initial author, but it can be overridden by the user. In the future it will become possible to reset the resolution of a program to new values.

mobluse wrote:

Is there a programmatic way to
get to know the screen resolution?

At the moment there's only a workaround, but yes, it is possible. One way would be to move some object to, e.g., the right border in a loop including a bounce from border brick, and check whether the x value does not increase starting from a certain value. This can be made very quickly in a repeat-until style loop at the beginning. There is a way to create repeat-until loops and speed up these loops to avoid the built-in slowdown described above. See https://pocketcode.org/details/964 for details.

Kind Regards,
Wolfgang

I installed the beta on my phone straight from the Market or Play store or however it's called right now, and it worked!
Looks interesting in general.
The default whack-a-mole did not adapt well to my screen size though, and there's no landscape mode when you turn the phone.
Very very promising, I can't wait to get a tablet to try it on!

So I made a google+ account and a pocketcode.org account but I still don't see how I could work on a project on any computer other than a phone, which is a little cramped?

michael42 wrote:

So I made a google+ account and a pocketcode.org account

The Google+ account is not needed anymore. Just download Pocket Code and Pocket Paint from the Google Play market.

michael42 wrote:

but I still don't see how I could work on a project on any computer other than a phone, which is a little cramped?

Pocket Code is just for phones and small tablets with a screen size up to 7 inches — it does not run on computers. For computers, please continue to use Scratch, it is fantastic. Also note that at the moment it works only on Android devices.

Kind Regards,
Wolfgang

Hi,

Pocket Code Beta is now available in the normal Google Play market!

We haven't announced it yet broadly as we are still eliminating the last bugs, but you are welcome to install and use it.

There was one small change in the behavior of programs, namely that the first look of each object is now immediately shown at the center of the screen when executing a Catrobat program, without the need for an extra “Switch to look …” brick. Some Catrobat programs will thus need less “Switch to look …” bricks, but maybe additional “Hide” bricks in order not to show looks of objects that should appear only later during program execution.

The original restricted beta version (the one for which you needed a Google+ account for the Pocket Code Beta Google+ community) will be deleted soon.

Please also download a new version of Pocket Paint from the market as the old one has been depreciated (updating is not enough, you have to deinstall the old Pocket Paint version first).

The links are:

• Pocket Code: https://play.google.com/store/apps/details?id=org.catrobat.catroid and

• Pocket Paint: https://play.google.com/store/apps/details?id=org.catrobat.paintroid

Enjoy!

PS: I edited my original post to reflect this change in the availability of Pocket Code.

Hi,

We just uploaded a new version of Pocket Code to Google Play that now includes a step by step guide, several short tutorials, and a number of starter programs, all accessible via the Help button on the main screen. Also the workflow and usability have been improved in many ways. E.g., when creating a new sprite, one first is asked to select or draw a picture, without intermediate step, like in Scratch.

We also have a first Catrobat program that was entirely made on a small phone and which then was automatically transformed into a real Android app that now is available as a game Android app on Google Play!

And the biggest news is that Google is promoting Pocket Code heavily during the launch of Google Play for Education, including:

★ Apps screenshot featured in the launch developer blog post http://goo.gl/Xob6pu, Android Edu developer site http://goo.gl/YeuSXE, and Google in Education site http://goo.gl/ciCFck
★ Google in Education G+ page app spotlight http://goo.gl/hQAXgy
★ Great Apps for your Class slides for educators http://goo.gl/pG9DVT
★ Top Tools for Schools 2 pager for educators http://goo.gl/BF2Dmh

Here's the link to Pocket Code on Google Play: https://play.google.com/store/apps/details?id=org.catrobat.catroid

Kind Regards,
Wolfgang

Can we make OS

kitasuka wrote:

Can we make OS

Hi, what do you mean? Kind Regards - Wolfgang

Cool, but it would be better if you could implement a go-to ‘where tapped’ and if touching ‘….’ That would be really useful! Thanks.

Hmm, good idea but confuses me????

Is their a PocketCode2APK

Cool i will try it

The Android version is now beta, with versions for iPhones, Windows Phones, mobile HTML5 browsers, and tablet devices of all supported platforms in various alpha stages.

There is a version for Windows Phone? I didn't see it on the app store.

hej_wickie_hej wrote:

kitasuka wrote:

Can we make OS

Hi, what do you mean? Kind Regards - Wolfgang

I mean how to make an OS?

QuillzToxic wrote:

Is their a PocketCode2APK

I found this response to a review who said that Pocket Code would be better if you could publish your projects to the Play Store.

Catrobat wrote:

Thanks!!! The apk builder is one of our Google Summer of Code 2014 projects. If everything works out, it will be ready in September 2014. Sorry that this is still far away, we are all volunteers… and Catrobat is a long term project, still in its infancy.

I love Pocket Code !

I can teach function and graph freely with Pocket Code,

and more, Students can operate there Graphs in Andriod smart phone.


https://pocketcode.org/details/1698


http://cafe.naver.com/pocketcode


Thanks…

Can you get it on HTC

Works on android!

is there a release date for the beta version on IOS devices
if there is, plz tell me