52a0d525d7
* feat(build): Make build tasks invoke their prerequisites
- Divide gulp targets into three kinds: main sequence,
manually invokable, and script-only. The first two categories
automatically invoke their prerequisites.
- Give (most of) the affected gulp targets shorter and more memorable
names that could become their npm script names in future.
* feat(build): Make package tasks invoke their prerequisites
Have the package task invoke the cleanBuildDir (as well as
cleanPackageDir) and build tasks. Remove the checkBuildDir
task as it is now redundant since a fresh build is done every
time.
* feat(build): Make git tasks invoke their prerequisites
* feat(build): Make cleanup, license [sic] tasks invoke their prerequisites
Turns out they don't have any, so this commit just classifies
their gulp targets according to the established scheme.
* feat(build): Make appengine tasks invoke their prerequisites
In this case prepareDeployDir will eventually depend on package
but does not for now.
* feat(build): Have npm scripts run npm ci first where applicable
Have any npm script that have external effects (e.g. publishing an
npm package, pushing a new version to appengine, or updating GitHub
Pages) start by running npm ci to ensure that all dependencies are
up-to-date with respect to package-lock.json.
(This is done by npm and not a gulp script because gulp itself
might need updating. So might npm, but that is less likely to
make any difference to what gets published/pushed.)
* chore(build): have tests use package target
Have the tests just run the package target (with debug flags)
since that runs the the build target automatically.
* feat(tests): Write Closure Compiler output directly to dist/
Since they are already UMD-wrapped, have Closure Compiler write
output chunks directly to RELEASE_DIR, i.e. dist/.
* chore(tests): Use freshly-build files in compressed mode.
Use the freshly-built build/*_compresssed.js files when bootstrapping
in compressed mode, rather than using the checked-in files in the
repository root.
This helps ensure that compressed and uncompressed mode will be
testing (as closely as possible) the same code.
Obsoletes #6218 (though the issues discussed there have not actually
yet been addressed in this branch).
* chore(build): Write intermediate langfiles to build/msg
Write the results of create_messages.py to build/msg instead of
build/msg/js.
* fix(build): Use build/msg/en.js instead of msg/messages.js in tests
This has no direct effect but fixes a long-standing misdesign
where we are testing against the input to, rather than the output
of, the language file processing pipeline.
* feat(demos): Use freshly-built files
Use the freshly-built dist/*_compresssed.js and build/msg/* files
rather than using the checked-in files in the repository root.
This helps ensure that these demos are using the most recent
version of Blockly (even in the develop branch).
* fix(build): Update appengine deployment to include built files
Modify the prepareDemos task as follows:
- Use the git index instead of HEAD, so that most local changes
will be applied (without copying whatever .gitignored cruft
might be in the local directory).
- Run clean and build and then copy build/msg and
dist/*_compressed.js* to the deploy directory.
This fixes the problem created by the previous commit, wherein the
demos relied on built files that were not being deployed to
appengine.
* fix(build): Update GitHub Pages deployment to include built files
Modify the updateGithubPages task to run clean and build and
then git add build/msg dist/*_compressed.js*, so that they will
be included in the deployed pages.
This fixes the problem created by the previous^2 commit,
wherein the demos relied on built files that were not being
deployed to GitHub Pages.
* chore(build): Remove build products from repository
Remove *_compressed.js* and msg/js/* from the blockly repository.
Also remove the now-obsolete checkinBuilt gulp task.
* chore(build): Apply relevant changes to test_tasks.js
Apply changes made to run_all_tests.sh and check_metadata.sh to
the corresponding parts of their JS replacements in
test_tasks.js.
* chore(build): Make updates suggested in PR #6475
- Remove `clean:builddir` and `clean:releasedir` - `clean`
is sufficient.
- Remove duplicate `require` from `appengine_tasks.js`.
* feat(build): Use shorter npm script names
Since scripts that run build tasks now automatically run their
prerequisite tasks, the previous naming scheme of task `build`
running all the `build:subtask`s no longe really makes very
much sense.
Additionally, following a chat discussion, there seems to be a
rough consensus to use "messages" to refer to the .json input
files, and "langfiles" to the generated .js output files.
Consequently, simplify npm script names by renaming as follows:
- "generate:langfiles" -> "messages"
- "build:langfiles" -> "langfiles"
- "build:js" -> "tsc"
- "build:deps" -> "deps"
- "build:compiled" -> "minify"
- "build:compressed": delete this synonym for "build:compiled",
("minify" was chosen as agnostic to Closure Compiler vs. WebPack.)
* chores(build): Add deprecation notice for old scripts
To reduce potential confusion/frustration, restore the previous
npm scripts but have them display a deprecation notice instead
(note that npm prints the script contents before running it, so
echo is not needed).
* docs(build): Add comments distinguishing 'messages' from 'langfiles'
Blockly in an Android WebView
This code demonstrates how to get Blockly running in an Android app by embedding it in a WebView.
BlocklyWebViewFragment
Most of the work is done within the fragment class BlocklyWebViewFragment.
This fragment instantiates the WebView, loads the HTML
(assets/blockly/webview.html, copied from demos/mobile/html/index.html),
and provides a few helper methods.
Copying web assets with gradle
This android project copies the necessary files from the main Blockly
repository (i.e., parent directory). In app/build.gradle, note the
copyBlocklyHtmlFile and copyBlocklyMoreFiles tasks.
In your own project, the HTML and related files can be placed directly in the
assets/blockly directory without the copy step. However, using the copy tasks
simplifies the synchronization with an iOS app using the same files.
Loading Block Definitions and Generator functions
The webview.html loads the block definitions and generator functions directly
into the page, without support or coordination with the Android classes. This
assumes the app will always utilize the same blocks. This does not mean all
blocks are visible to the user all the time; that is controlled by the toolbox
and workspace files. This should accommodate almost all applications.
This does mean loading your own block definitions and generators will involve
editing the HTML, adding you own <script> tag, and possibly removing
the blocks_compressed.js if you do not use any standard blocks.
Connecting a Developer Console
While the console output of the WebView will be visible in the Android log
(i.e., logcat), some times a more intrusive approach is required to isolate
a problem. For instructions on connecting the WebView to Chrome's Developer
Tools, see this article:
https://developers.google.com/web/tools/chrome-devtools/remote-debugging/
The WebView must be visible in the connect device or emulator before the WebView will included in the list of available pages to connect to.