Where’s the source for the current “Timer” app used for the litter box?

Device it uses: Tmo (saffire?) 3g something… running Android 2.2 (aka Froyo).

API level ⇒ API 8

As an exercise, it would be nice to rewrite this in Kotlin to see if it can run on Froyo. (FAQ says there’s no min sdk req).

---

It's time to reflect on Conductor 2 again.

The repo branch has been going nowhere lately. I moved the project to a new repo (in the randall-layout workspace) and only copied the conductor 1 part. That made me realize I'd be throwing away a valuable part with the SVG map.

So first I want to salvage that part. The UI is and should be separated from the engine. This UI was going to drive a simulator, and I can likely make that happen on top of conductor 1.

The next part I want is to formalize the spec for conductor 2. Forget the syntax for now, I need to get the requirements right first: block handling, route management, and fully convert a current script. Also write some examples for eg window block handling.

(Reading between the lines, what I’m saying is that the Conductor-2-with-Groovy-DSL shows me that in fact I want more profound changes than “just a DSL”. I really want to rethink the entire way the automation scripting is done.)

Then once we have that we can figure the implementation. Maybe getting entrenched in groovy is not helpful here. There's clearly some value in not writing my own language, unless it slows me down.

The discussion continues in the Conductor 2 doc.

---

I haven’t written one so it’s worth explaining the status of Conductor 2:

• Entirely rewrote the current v44 script using an “enhanced” version of Conductor 1 syntax to explore a realistic way to describe and use the new routes concept.
• Considered whether it’s worth pursuing the Groovy DSL vs extending the Conductor 1 DSL…
• The decision is that the former Conductor 2 Groovy DSL is obsolete. It was premature. Part of the issue was that it was getting entrenched in bridging the functionality and implementation (at the same time) with the former Conductor 1 engine. That is not the proper way to prototype.
• Instead, modularized the Conductor 1 source code to move the engine/DSL into a sub-project.
• And added a mock Conductor Groovy DSL rewritten from scratch, focusing on how the syntax would work rather than the actual implementation. There are unit tests but they only validate that the DSL can actually encode what it’s supposed to.
• The goal is to later also do a mock Kotlin DSL and compare.
• I still need to create a fat jar where this is invoked as Jython add-on from JMRI, to ensure there’s no library mismatch for example when running Groovy or Kotlin runtime code.
• That led me to explore the fundamental issue with the current route system, namely that we must have “managers”, “active routes”, and the sequence/shuttle manager should deal with a node graph instead of a “block list”. After much back-and-forth debate, I think I finally have a system I can endorse. Now I must encode it using the Groovy DSL.

---

Right now on the laptop for RPisicine I have:

$ node --version        ⇒ v14.11.0

$ npm --version        ⇒ 6.14.8

https://github.com/nvm-sh/nvm

⇒ install.sh

$ nvm list                # takes a while...

Install steps recommend to remove “-g” (global) modules that will likely break when changing version globally:

$ nvm use system

$ npm uninstall -g nwb

$ npm uninstall -g serve

$ nvm install v14.11.0

In rpiscine:

$ node --version > .nvmrc

$ nvm use        # in that directory, to switch to that version

How does changing the Node version with nvm affect the NPM version?

⇒ The NPM version depends (and varies with) the Node version being used. E.g.:

$ nvm use node

Now using node v14.11.0 (npm v6.14.8)

$ nvm install node

Now using node v17.1.0 (npm v8.1.2)

For Windows, there’s https://github.com/coreybutler/nvm-windows

To fix the NVM PATH in CMD.exe: Not really an option when installed using nvm-sh since the latter does not create an “nvm.exe” or “nvm.sh” -- instead all the nvm commands are bash functions loaded in the interpreter (meh). But we can work around it:

• cygwin: $ cygpath -w $(dirname $(nvm which --silent))
• ⇒ C:\Ralf\.nvm\versions\node\v18.8.0\bin
• Copy path to a CMD.exe.
• cmd:         $ refreshenv                ← optional, because I have chocolatey installed.
• $ set PATH=C:\Ralf\.nvm\versions\node\v18.8.0\bin;%PATH%
• $ echo %PATH%

---

An update on Projet RPiscine aka Piscine 2:

• Python service: access RPi PiFace, store data, expose data via REST JSON.
• React JS served via nginx to connect to the Python service + visualize the data.

This worked very well. The “backend vs frontend” split was good.

The setup allows for a local react dev on laptop, build on laptop, then push the build site to the RPi.

This runs on an RPi 1 B (the older kind), with Debian buster, and using systemctl services for the python wrapper. Also a reverse-ssh service wrapper is created, which works very nicely. Using the new systemctl service is a nice improvement over the old initd scripts.

---

What would it take to do an Android app that is modular and where each feature is controlled by a remote server feature flag?

Would I choose something like Firebase, AWS, or a custom server like Alfray or RDRR?

The data itself would likely be json or proto. We would want to have version capabilities.

Notions that become relevant are cold vs hot config, refresh times, networks caching. Also an ETag / checksum system could be used to only send diff/update and minimize network traffic.

---

Time to end the summer project with Bearing B3. Steps needed:

• Publish it!
• Check if I can update only the Installed version, without the “Instant” one.
• I do realize the Installed-vs-Instant doesn't make a lot of sense in this case due to the preference storage for the Waypoints list. When updating, any waypoints created with the Instant one will be lost.

Either way I’m likely to remove the Instant version as it’s mostly pointless here. It’s only here as an exercise...

---

In the Train-Motion project, I have a fat jar gradle rule to package all the dependencies in a single jar.

To make it work, I had to create a “configuration” in gradle:

configurations {

    runtimeCompile {

        canBeResolved = true

        canBeConsumed = true

    }

    compileClasspath.extendsFrom(runtimeCompile)

    runtimeClasspath.extendsFrom(runtimeCompile)

    testCompileClasspath.extendsFrom(runtimeCompile)

    testRuntimeClasspath.extendsFrom(runtimeCompile)

}

Then I use this configuration to include the dependencies:

dependencies {

    runtimeCompile project(":LibUtilsJava")

    runtimeCompile "commons-cli:commons-cli:1.4"

    runtimeCompile "org.bytedeco:javacv-platform:1.5.3"

    runtimeCompile "org.bytedeco:javacpp-platform:1.5.3"

    runtimeCompile "uk.co.caprica:vlcj:4.7.1"

    runtimeCompile "com.fasterxml.jackson.core:jackson-databind:2.10.2"

    runtimeCompile "com.squareup.okhttp3:okhttp:3.10.0"

    runtimeCompile "org.eclipse.jetty:jetty-server:9.4.29.v20200521"

    runtimeCompile "com.google.dagger:dagger:2.28"

    runtimeCompile  "com.google.auto.factory:auto-factory:1.0.1"

}

And finally a fatJar task collects these specific dependencies and packages them together:

task fatJar(type: Jar) {

    manifest.from jar.manifest

    classifier = "all"

    from {

        configurations.compileClasspath.collect { it.isDirectory() ? it : zipTree(it) }

    } {

        exclude "META-INF/*.SF"

        exclude "META-INF/*.DSA"

        exclude "META-INF/*.RSA"

    }

    with jar

}

Note that “runtimeCompile” is a superset of the “compile” configuration, and the artifacts can be found using configurations.compileClasspath.

That’s neat to create the needed single JAR. That jar is ~760 MB with all the OpenCV deps. And it takes an interminable 4 minutes to create the jar itself.

So now the question is whether I can avoid that. I don’t need to distribute the jar, so I'd be fine with crafting a specific command line with the needed classpath. Or even having a “gradle run” task that does not need the fat jar first.

---

Now that we have a basic “marked locations” list in B3, it’s time to review the UI and adjust.

The goal was to do it in Kotlin, and that’s been done.

One issue was the “Marked Locations” wording, which seems problematic. Isn’t there something better… “waypoints” seem like a better name.

So let’s do a few changes:

• Vocabulary:
• A “Location” is just a raw GPS location coordinate (latitude + longitude).
• A “Waypoint” is a location coordinate combined with a name.
• Screen “Marked Locations” ⇒ “Waypoints”
• “Marked Location” ⇒ “Selected Waypoint”
• “Location N” ⇒ “Waypoint N”
• Rename class Mark to Waypoint / Waypoints / WaypointsAdapter.
• Screen “Compass”
• “Marked Location” ⇒ “Target Location”
• (that should make it more obvious it’s the target of the bearing)
• Menu Recall / Edit ⇒ keep as-is for now.

We’ll keep the wording as “Location” (Target vs GPS) in the Compass screen.

---

I feel like a case of deja vu so I need to write this down.

• Robolectric: simulating an Android runtime working on top of the JVM, local dev machine. No emulator needed.
• Used to be simple and straightforward. Since Robolectric 4 and recent android gradle updates, some things have been deprecated / changed making it harder to use.
• AndroidX runner “AndroidJUnitRunner” tests which go in androidTest folder: run on device or emulator, and are essentially the modern version of the instrumentation tests.
• Setup for gradle imports is highly modular. For ref:
• https://developer.android.com/training/testing/set-up-project 
• AndroidX runner “AndroidJUnit4” tests which go in androidTest folder: run on device or emulator too ⇒ the test folder name indicates which build rule is used and where the test runs.
• AndroidX runner “MockitoJUnitRunner” tests which go in the test folder: run on JVM.
• This is provided by mockito-core and is basically a JUnit runner that also happens to auto-init all the @Mock instances. ⇒ Just a convenience over the usual Mock rule, no relation to Android framework.
• How much of the Android framework can be used with that? ⇒ none
• Robolectric with AndroidX tests:
• http://robolectric.org/androidx_test/
• Use the “AndroidJUnit4” runner.
• Confusing because nothing makes it clear these are Robolectric tests.

What I have done for Cab v2:

• Build.gradle > defaultConfig > testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
• ServersActivityTest:
• @RunWith(AndroidJUnit4.class)
  @Config(application = TestMainApp.class)
  ApplicationProvider.getApplicationContext()
  ActivityScenario.launch(MainActivity.class)
• The cabv2 TestMainApp derives from the LegacyMainApp and replaces the IAppComponent by the ITestAppComponent for testing. That’s how test modules are injected in the app.

Since updating B3, I was getting errors:

• “robolectric RuntimeException Method not mocked”
• They are “solved” by adding this to app gradle:
• testOptions > unitTests >  returnDefaultValues = true
• Which in turn creates another error: “java.lang.ClassNotFoundException: android.content.res.ApkAssets”
• Real solution: following https://github.com/robolectric/robolectric/issues/4740
• The dumb solution is to remove the m2 robolectric cache so that it gets downloaded again.

---