We are designing a summer app camp using App Inventor. There are two features we are interested in.
The first is logging activity as students build apps. Entries in the log would be things like "drag set" and "delete when". I assume this feature would require modifying the App Inventor source code and running it on our own server. Unless someone has done something similar already?
The second feature is logging activity as the app itself is used. For example, if the app is designed to allow users to record someone saying a joke and then playing it back, entries in the log file would be things like "press record button" and "start playback". I imagine we could achieve this functionality by creating an extension with custom blocks, but it would be really cool if we could somehow use all standard blocks with some kind of logging code running under the hood.
First item sounds like a diary. Try How to make an editable diary? - #2 by SteveJG . Although App Inventor captures the steps, I don't think there is anyway to capture them automatically. Let the students do this manually if there is really a need for this detail.
Second. You can use if..then..else statements. If something executes, it can enter the action in a List or a Label. i.e. when the a Button is pressed, the app can enter which Button was pressed into a List or whatever.
If this doesn't answer your questions; explain a bit more about what is supposed to happen.
Here are some resources to help you learn to use the AI2 tools. A very good way to learn App Inventor is to read the free Inventor's Manual here in the AI2 free online eBook App Inventor 2 Book: Create Your Own Android Apps ... the links are at the bottom of the Web page. The book 'teaches' users how to program with AI2 blocks.
Thanks, Steve! I don't think it quite answers my questions. Our app camp is part of a research project which includes analyzing how students write code. So:
Say we have a student named Sally. At the end of the app camp we would like to have a log file (text, csv, or something similar) of Sally's actions while she was programming. Her actions might be "open AI," "create project X," "grab Set," "drag Set," "drop Set on canvas," etc. We can use these logs to measure student progress and even how interested they are in the project. This is functionality that students wouldn't see at all while they're programming and would probably lose awareness of. (We, of course, will inform students and parents of the logging in research consent documents.)
The second feature has a similar purpose. We want to know if and how students are using their apps when they go home. So, for student Joseph, we want a log file (again, text or csv) that has entries, with timestamps, like "open app," "press button," etc. This helps us gauge interest in the different types of activities and allows us to correlate with family demographics. Again, it would be great if this is transparent to the student.
This is great, thank you! I'll check out those links.
Regarding privacy and confidentiality, we always work through our university's ethics review board on studies like this. The informed consent documents that both students and parents sign are clear about what data is collected and strict measures are in place for how the data is handled.
In 2019 we published a paper on what we called the App Inventor Research Platform, which was built on work to build a version of App Inventor that supported realtime collaboration. The RTC server would be capable of recording the fine grained details like what you're requesting, but you could also build a custom version of App Inventor and use self hosted analytics to collect the data.
The Notifier component has methods like LogInfo that will log to the Android debug logs (accessible using the adb utility). You could use it to log events at points of interest during the app. However, if you're looking to do this in a more distributed fashion that won't work (i.e., you need to be plugged into the phone and have it in developer mode to read the logs). Another potential solution could be having a HTTP server that receives events and transmit the events with the Web component. This requires that you would be systematic in placing the logging calls. If you wanted a more general approach you'd have to modify the runtime library to support it.
