google / blockly-android Goto Github PK

To match web Blockly behavior, when clicking anywhere in a BlockView in a hideable toolbox, a duplicate block should appear in the Workspace.

• In the case of clicking on a FieldView, the field should be focused.
• In the case of a field view that with a pop up window, the window should be opened and focused.

All touches currently begin drags. Should all drags be scrolls? Should all taps be automatically moving from trash to workspace?

We're somehow finding a connection candidate without a view associated with its block. This shouldn't be possible but it seems our view and model hierarchy can get out of sync.

02-29 17:14:54.574 5518-5518/com.google.blockly.demo D/AndroidRuntime: Shutting down VM
02-29 17:14:54.584 5518-5518/com.google.blockly.demo E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.google.blockly.demo, PID: 5518
java.lang.NullPointerException: Attempt to invoke virtual method 'void com.google.blockly.ui.BlockView.setHighlightedConnection(com.google.blockly.model.Connection)' on a null object reference
at com.google.blockly.control.Dragger.continueDragging(Dragger.java:246)
at com.google.blockly.control.Dragger$1.onDrag(Dragger.java:102)
at android.view.View.dispatchDragEvent(View.java:18321)
at android.view.ViewGroup.dispatchDragEvent(ViewGroup.java:1492)
at android.view.ViewGroup.dispatchDragEvent(ViewGroup.java:1441)
at android.view.ViewGroup.dispatchDragEvent(ViewGroup.java:1441)
at android.view.ViewGroup.dispatchDragEvent(ViewGroup.java:1441)
at android.view.ViewGroup.dispatchDragEvent(ViewGroup.java:1441)
at android.view.ViewGroup.dispatchDragEvent(ViewGroup.java:1441)
at android.view.ViewGroup.dispatchDragEvent(ViewGroup.java:1441)
at android.view.ViewGroup.dispatchDragEvent(ViewGroup.java:1441)
at android.view.ViewGroup.dispatchDragEvent(ViewGroup.java:1441)
at android.view.ViewGroup.dispatchDragEvent(ViewGroup.java:1441)
at android.view.ViewGroup.dispatchDragEvent(ViewGroup.java:1441)
at android.view.ViewGroup.dispatchDragEvent(ViewGroup.java:1441)
at android.view.ViewGroup.dispatchDragEvent(ViewGroup.java:1441)
at android.view.ViewRootImpl.handleDragEvent(ViewRootImpl.java:5073)
at android.view.ViewRootImpl.access$700(ViewRootImpl.java:99)
at android.view.ViewRootImpl$ViewRootHandler.handleMessage(ViewRootImpl.java:3271)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5221)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)

We should include a demo showing how to wrap Blockly with a material design activity (including ActionBar and NavigationDrawer), but they probably don't belong in the core library. Lets remove them from AbstractBlocklyActivity.

FieldInputView (EditText) currently takes more vertical space than FieldLabelView (TextView) and FieldDropdownView (Spinner).

Colour picker, Angle picker, etc. don't currently scale with the workspace when zooming. We should review the UX for these and decide if they zoom and how much.

We aren't actually using FieldWorkspaceParams for everything and they were a premature optimization. We should remove them and all other WorkspaceParams.

Can we lazily load it?

1. Zoom out.
2. Drag a block to the trash. The block drops behind the trash.
3. Drag block to center of screen (while still zoomed in). Sometimes the block disappears into trash.

"We should have a dragEventListener on the trashView instead of doing screen location comparisons in the dragger code." - @rachel-fenichel

Full spec fleshed out here google/blockly#446

• Support custom VARIABLES toolbox category.
• Support creating variables.
• Support deleting variables.
• Support renaming variables.
• Support dynamic creation of variable blocks when they're added/removed.

Currently implemented with 9-patch files that scale with zoom. When the user zooms out, the border width scales down, making it harder to see potential connections when dragging.

The Generator code should be refactored into BlocklyGenerator and BlocklyGeneratorService.

BlocklyGenerator is the client side class and should be responsible for connecting to the service and wrapping calls to the service (and contains the callback classes). This code is currently part of BlocklySectionsActivity but should be pulled out into its own class.

BlocklyGeneratorService is currently named CodeGeneratorService and shouldn't need many changes.

There should be a default bitmap if FieldImageView cannot load a bitmap from the given URI. Currently, the field stays unset/empty.

If the trash fragment is always visible, it should be drop location. This alleviates the need for a trash can on the workspace. This, in turn, affects the placement of the zoom buttons.

Probably depends on a drag shadow for dragging outside the workspace, first.

User should be able to retrieve old blocks, regardless of how they are deleted.

Shadow blocks are supported.

• Need UI assets
• Need to add shadows to the turtle demo

Resilience to unexpected shutdown (out of battery, etc).

Upon each compile? More often?

We will never support API Levels 1, 2, or 3, so there is no reason to use the backward compatibility class.

Here:

This bug is for configurable backgrounds for each flyout in a toolbox/trash.

If models are observable, then views wouldn't rely on the controller for changes. Apps could manipulate the model objects more directly, without the view getting out of sync.

When dragging, filter out potential connections that are not visible in the current WorkspaceView (e.g., outside the current view bounds).

To make it easier to customize fields we should refactor so that they can be inflated from a layout (through methods on the WorkspaceHelper). The field can then be passed in to the view after inflation to bind it to the data.

https://blockly-demo.appspot.com/static/demos/code/index.html#r78um6

• Workspace contents.
• Workspace pan & zoom.
• Focus (field or selected block).
• Trash contents.
• Variables list, including unused variables (#499).

Add a demo Activity without a hideable Toolbox.

• Verify clicking on blocks that do not overlap the workspace create their duplicates in the closest available workspace location. Ideally with animation.
• Verify dragging blocks to parts of the screen that are not the Workspace results in a cancelled action.

In order to limit errant connections from occurring, especially in crowded workspaces, limit the connections available connections to the block's output, previous, first statement input, and any external inputs before the first statement. (This is a rough heuristic worthy of discussion.)

Tabs are the labels that open the flyout, as opposed to the area with the blocks.

We need to

• Update all variable fields when a variable is deleted so they don't reference the dead variable.
• Update the list of references in WorkspaceStats when a variable field changes.

Probably root block #0.

Related to google/blockly#265

Results in never saving/restoring updated values, and generating code with only the default field values.

If you use the zoom icons to zoom all the way in, then pinch to zoom all the way out the zoom in icon won't do anything and the zoom out icon will suddenly zoom you to max zoom - 1.

All Block related view models currently have final references to their matching model object. As such view objects can never be reused with other models. (There are also edge concerns with old views accessing models, but the app developer would have to jump through some pretty significant hoops to access / re-add such views.)

Until any side effects are seen (assuming good programming practices in the host app), this is an extremely low-priority bug.

• Blocks
• Inputs
• Fields

"To reproduce, drag blocks to opposite corners of the workspace to make the workspace very large, then pinch to zoom next to a block. The block will fly off screen and the grid will jump around." - @RoboErikG

The following JSON created options ordered 4, 2, 5, 3, 1. It should appear in the same order as the JSON.

{
"id": "move_up",
"message0": "move up %1",
"args0": [
{
"type": "field_dropdown",
"name": "SPACES",
"options": [
[
"1 space",
"1"
],
[
"2 spaces",
"2"
],
[
"3 spaces",
"3"
],
[
"4 spaces",
"4"
],
[
"5 spaces",
"5"
]
]
}
],
"previousStatement": null,
"nextStatement": null,
"colour": 160
}

Compare to the gap at the bottom of any statement input.

We aren't actually using them and they're leftover from an earlier design.

"To clarify, this issue is to consider bumping blocks further when zoomed out to make it easier to figure out that it was bumped." - @RoboErikG

Example:
If zoomed out (i.e., all blocks render smaller), the touch size is effectively a larger number of workspace units. Thus, the workspace unit values of touch slop (distance before a drag is started) and snap/bump distance should also be inversely scaled by zoom. This ensures the sizes are relative to a touch size on the current view.

If zoomed in (i.e., all blocks render larger), the touch slop and snap distances should be short (in workspace units). However, the bump distance might remain the same as a zoom 1.0 bump, so it doesn't snap into place when dragged at zoom 1.0.

Probably just a comment in any minimal example application-specific runtime.js or generator.js file.

See https://github.com/RoboErikG/blockly-android/blob/47aca4faa860bd52af1fa3d5ffbd77bd5fa80302/blocklydemo/src/main/assets/turtle/turtle.js#L47

Tap to select, keeping track of focus, etc.

Variables are a bit messy in their current form. We should sit down and go over them to see if there's a better design.

BlocklyController.trashRootBlock(..) → BlocklyController.trashBlock(..) that can handle the disconnecting a block from it's previous/parent. All children (inputs and next connections) should also fall into the trash.

• Pull disk IO out into a separate helper class (explicit save and load)
• Make disk IO happen in an AsyncTask
• Stress test (de)serialization of workspace
  • If this can take too long consider options for moving serialization off the main thread.
    • Potential option is once events are in send all events to the background service and perform serialization on a copy there.