This discussion covers multiple unmet needs with regard to programming using App Inventor 2 (AI2).
One is the need to copy blocks between current AI2 projects – a Copy & Paste facility would be great – something that these days (IMHO) should be a basic editing function. In Development there are always competing priorities and this feature seems to have lost out for years, going back to App Inventor under Google and perhaps before that.
Another need is to copy blocks from external AI2-compatible repositories or other resources and insert them into your own project(s). There doesn’t even seem to be a “merge” facility to allow useful external code blocks to be incorporated into an existing project.
Yet another is the need to bring blocks from non-AI2 sources – the original App Inventor, perhaps, or Blockly, or the Block Factory, or whatever. This is a more complex issue since there is a compatibility problem with blocks from App Inventor and App Inventor 2.
And then there’s the issue of copying/pasting screens from one project to another, or even within the same project (which you might want to do as a template, which you would then modify accordingly. Saves lots of reinventing the wheel).
It’s hard to define the precise characteristics of the audience for this discussion. Certainly a fair amount of experience in a variety of software technologies would be a distinct advantage. Some understanding of XML would be useful. The ability to recognize a likely .zip file header would come in handy. A tendency to be risk-averse would be preferable.
Age/gender is/are irrelevant. Curiosity knows no bounds.
It should go without saying that any changes that are made to an AI2 project using methods that are not provided by the tools available must be done with extreme care, with the understanding that the results could be a mess.
So make sure there are backups – and backups of backups – and check, double-check and triple-check any work before submitting the results to AI2 using the feature to import .aia files.
Others have trodden this path before me, primarily for the original App Inventor, and at least one updated their AI1 copy/merge tool to work with AI2 but it appears to have tripped over subsequent changes in AI2 that were sufficiently fundamental that their tool broke, and at the time of writing is still undergoing repair (other priorities, understandably, take precedence).
So keep an eye on these resources (descriptions in italics taken from the resources):
One feature missing from App inventor is the ability to merge projects or even take a snippet of code from one project and add it to another on the same screen. To overcome this I’ve created a small Windows utility call the “AI Project Constructor” which gives you the ability to merging number separate App Inventor projects into or one or many screens in a new project. (Software written by Gareth Haylings)
I (the author of this blog) lack the skill and experience to create such tools – my strengths tend to lie in devising temporary workarounds until the smarter guys finish their work and render mine irrelevant.
Other URLs to check out include:
The easiest way to create new blocks is to use the Block Factory. Use the GUI to form a new block, then copy and paste the generated code into your application:
Improving App Inventor Usability via Conversion between Blocks and Text (Karishma Chadha, Franklyn Turbak):
Improving the Usability of App Inventor
through Conversion between Blocks and Text (Thesis, Karishma Chadha)
This article is from 28 months ago and doesn’t fully apply to AI2, but it’s useful background:
Android Programming with App Inventor, Aug 15, 2012, By Amit Saha
I will add to these as further research uncovers more useful resources.
The first step has to be a relatively high level examination of the .aia AI2 file format. This is the only client-side data source available to us. Ironically the first steps involve a low-level view 🙂
I took one of my current AI2 projects and exported it to an .aia file on my local machine (which is running Windows XP SP3 by the way, and for now I have no option but to use that system for all my work):
I made an initial examination of the .aia file using a hex editor called HexEdit 4.0 from Expert Commercial Software Pty Ltd (www.hexedit.com (1)). You can use whatever tool you prefer, as long as it allows you to look at the first few bytes of the file as ASCII characters, with or without the hex representation.
This was the result:
The key information here (aside from the interesting viewable text that seems to show a directory structure) is contained in the first two bytes: PK.
Those two letters strongly suggest that this is in fact a ZIP file (from PK-ZIP). It’s not guaranteed, so the best way to test the hypothesis is to try to extract the original data using an UNZIP-compatible application, which will complain if it isn’t truly a PK-ZIP file.
These days I tend to use 7-ZIP (www.7-zip.org, © Igor Pavlov) primarily because it seems capable of spotting a PK-ZIP file even if the extension isn’t .zip, and working with it. You can use whatever tool you prefer, but you may have to rename the extension of your .aia file to .zip in order to work with it.
Alternatively, you can read around the subject online and discover that the original App Inventor used .zip files instead of .aia files, which helps explain its provenance 🙂
I used 7-ZIP to extract my sample .aia file and reveal its directory structure:
The top level folder is the .aia file name (sans extension). The next level down shows “src” and “youngandroidproject“. Note that this may not always be the case, and we should always be alert to changes.
The youngandroidproject folder contains a single file called “project.properties”. We’ll examine that shortly.
The src folder contains a nested set of folders, only one of which contains any files. We can hazard a guess that “src” is a contraction of “source”.
The structure shows “appinventor” as the first level child (if we take src to be the parent), and that’s possibly because some backward compatibility with the original App Inventor is required (or it might have been called “appinventor2”).
The next level child is “ai_AncientBrit”, which, when you know that my ID on the AI2 site is AncientBrit, should be self-explanatory (i.e., we’re still dealing with backward compatibility so it’s ai_… and not ai2_…).
The final level child is “MRF1”, which is the actual AI2 project name (different from the file name, which was chosen specifically for the fact that I collapsed all the blocks for one of the screens – and then saved another version in which all the blocks were expanded, so I could use the two for a comparison of their contents to investigate whether the difference(s) were recorded).
Within this bottom level folder lies the rest of a treasure trove of information (project.properties was the first nugget that I found).
There are three apparent file types: .bky, .scm, and .yail. In my sample project there are three screens, and here there are three corresponding sets of those file types – one of each for each screen.
The extension .yail is harder to pin down. There are countless references online, and only a few that seem to make sense in this context.
It doesn’t yet have a Wikipedia page, but it does exist in SourceForge (which Wikipedia describes as a “… web-based source code repository. It acts as a centralized location for software developers to control and manage free and open-source software development.“).
Its SourceForge entry describes it as “…semi-interpreted programming language which runs under a virtual machine.” Elsewhere it is described as “an intermediate language for the native compilation of Prolog programs“, which doesn’t clarify things tremendously.
More informative is the article from Amit Saha (see References above) where Amit describes the .yail file content as “…an intermediate language based on the Scheme language used by App Inventor, which is then fed to Kawa to create the Android package for installation on Android devices.” So there you go. At least someone knows what it is 🙂
The good news: all of the files (including project.properties) are plain text files, which makes life considerably easier, at least as far as examination and manipulation are concerned. Comprehension is a different matter…
Part of this article is concerned with copying code blocks from one screen to another, or one project to another, or inserting code blocks from another resource into a project.
So it seems likely that our focus should initially be on the .bky files. Here we may catch a break: when I examined the content of one of the .bky files I spotted a familiar friend: XML.
Where there is XML, there is the possibility of viewing it in a formatted manner using an XML editor, and I just happened to have Microsoft’s XML Notepad 2007 to hand, so I fired it up and loaded one of the .bky files – the one for Screen1, which is the start screen for all AI2 projects as far as I can tell.
XML would also make copying blocks of code much easier; find the start and end tags for a particular XML block and regular Ctrl-C and Ctrl-V might suffice to transfer blocks from one file to another (and thence from one project or screen to another). I can but dream…
Before viewing in XML Notepad (available for free), the content of screen1.bky looked like this in a plain text editor (I favor TextPad from Helios Software Solutions but I don’t have the latest version; I’m still evaluating it):
Loading the same file into XML Notepad 2007 gives this:
What makes this look promising is the fact that it’s been neatly formatted. That implies the task ahead might be less complicated than it first appeared to be.
More to follow…
(1) The site appears to be down, but the WayBack Machine (Internet Archive – https://archive.org/web) shows the site active as of December 2014).