Critique of: Blom, K. J., & Beckhaus, S. (2007). Functional reactive virtual reality. Paper presented at the IPT-EGVE Symposium (2007).
Introduction and Problem Addressed
Modern computer games use labor intensive and expensive keyframe animations to provide rich, interactive, animated experiences to players. Virtual reality applications require a general, procedural solution to creating interactivity that does not require the same investment in game art. (Blom & Beckhaus 2007) A key feature of a solution should be abstractions that are cognizant of time varying values, with first class support for operations involving time sequenced data, rather than frame-locked clocks (Khare, Kyoungho, Gokhale & Tambe, 2015). Functional Reactive Programming (FRP) is a solution to this problem whereby a data flow directed graph from discrete events (keypress, mouse click..etc) and continuous streams (eg, time) can be bound to reactive behaviors in the environment. (Bainomugisha, Carreton, Cutsem, Mostinckx & Mueter 2013)
Furthermore, a typical non FRP solution to providing animation and interactivity in VR and visualization is to use procedures bound to events and data that update the graphics on callback, as in MVC, where changes to the model must explicitly update the view (Xie, Hofmann & Cheng 2014). However, managing ad-hoc data flow through callbacks can become unwieldy, and event driven graphics can be hard to debug. (Bainomugisha et. al., 2013)
Data stored in GIS databases is often amenable to extraction and translation for visualization. Prototyped here is implementational research that uses an Oculus Rift head mounted display to navigate GIS data in real time. The interface used is an egocentric interface to the data, meaning that the user may walk around the map, rather than rotate it while standing at a fixed perspective. Novel solutions like the use of a cut plane to better visualize changing values, as well as standards based data interchange are presented in proof of concept form.
I gave a quick intro to Reactive programming in Java for Android at NSU’s College of Engineering and Computing this weekend. It’s not a subject that I know in much depth, but I am excited about it! The slides are here.
“Your Activities seem a little monolithic, that’s pretty common…”
— Code review
I recently refactored one of my apps to take code out of the Activities and encapsulate features into custom Views. The result was that my Activities now are very sparse, and basically just implement the Activity lifecycle callbacks, with the Views themselves being responsible for their own data and data binding. A future iteration will consider the use case where we want to incorporate a more traditional Controller class so that we might better share data between Views, but for now, these standalone Views serve to better organize the code for maintainability.
The challenge here is that we want to re-use our ContentProvider across free and paid flavors of an app, but Android requires CP’s to have unique ‘authorities’ (more on that later). In this article we will solve that problem. If you are curious about the context for these snippets, see the Philly Crime Map project on github here.
10. AND is scheduled for 12 months, but you can (and should) do it in 3.
The Nanodegree is set up for a 12 month timeline, but it would be hard to imagine being able to maintain any kind of continuity between development sessions if you spent the entire 12 months on it. I had the summer off, and even though I had quite a bit of Android experience already, I still believe that the best way for someone (even a beginner) to do this program is to hit it as hard as possible for as short a period of time as possible.