Android development: what is needed to do a theme changer that supports light, dark, and system dynamic theming?

A good candidate is Seeds.

JavaCV: Used in Randall’s camera proxy app to capture data from an RTSP h264 / MJPEG feed, and produce jpeg images or publish an MJPEG web (via a Jetty web server).

OpenCV: for the Randall camera proxy project, need basic motion detection.

Some good tutorials here: https://opencv-python-tutroals.readthedocs.io/en/latest/py_tutorials/py_video/py_bg_subtraction/py_bg_subtraction.html

Example in Python. Java API available here: https://docs.opencv.org/master/javadoc/org/opencv/video/package-summary.html

And in JavaCV it shows how to convert frames between the FFMPEG input and what’s needed by the OpenCV library using “Mat” and an OpenCV converter.

Update 2020-06-09: The “cam-proxy” project is working nicely.

One realisation: I picked up the JavaCV approach as it seemed easier to get started, and that paid off. However it’s worth pointing out that the generated fatJar is an impressive 760 MB!

That is quite a feat.

Looking at the APIs, do I need all of JavaCV, or could I use only OpenCV with its Java bindings? Let’s see which APIs I’m using here:

• JavaCV.FFMpegFrameGrabber ⇒ there’s an OpenCV specific one.
• JavaCV.FFMpegFrameRecorder ⇒ to generate the MJPEG stream. Alternative?
• JavaCV.2dFrameConverters + CanvasFrame ⇒ there’s an OpenCV one.
• OpenCV core: IplImage, Size, Rect, Mat
• OpenCV imgproc: resize
• OpenCV video: cvCreateImage, mediamBlur, createBackgroundSubstractorMOG2.

• Thus one question is whether it’s possible to generate the output stream (MJPEG or h264) using OpenCV and its Java wrappers, or is FFMpeg needed for that?
• Uncompressed fatJar size:         2,762,758,664 bytes
• org/ part of the jar:                 2,227,823,156 bytes
• Opencv:                                1,065,264,936 bytes
• lib/ part of the jar:                  629,358,581 bytes
• Ffmpeg:                                  371,946,457 bytes
• Javacpp:                                   10,261,365 bytes
• Javacv:                                      921,733 bytes
• Jetty part:                              318,8118 bytes

So essentially trying to only use OpenCV would likely not save that much. A huge part of the JavaCV package is indeed OpenCV and a quick look at the final Jar shows that it contains not only java wrappers but also hpp headers, some xml, and most important the jni+si native libs for a lot of architectures (e.g. armhf, armeabi-v7, arm64-v8a, x86, x86_64). If an effort was needed to trim the jar file, it could be by avoiding packaging these in the first place by removing all the arm ones (3 out of 5 archs).

Here’s an interesting problem in Cab v2:

• Main app: Main app component.
• WiThrottle library: Lib component.

The design I want is for the library to be an extension to the main app. The library provides components/modules that the main app can use and inject. The library itself cannot use anything from the app (since it is app-agnostic).

In terms of components/scopes: the library is the outer component, and the app is a sub-component of the library. The app can use elements provided by the library.

When using component dependencies, which one depends on which?

• https://proandroiddev.com/dagger-2-part-ii-custom-scopes-component-dependencies-subcomponents-697c1fa1cfc
• https://proandroiddev.com/dagger-component-dependencies-for-library-development-e2df7ce68233

I think that means the app component has a dependency on the lib component.

This seems to work with some caveats:

• @Singleton @Component AppComponent // dependencies = { LibComponent.class }

Issue:

• At build time “dagger AppComponent scoped may not reference bindings with different scopes”.
• ⇒ Two ways to fix that: either remove all scoping info from the dependencies component and everything provided; Can’t even be in the same @Singleton. Obviously that’s not right.
• ⇒ Both components can have and likely should have different scopes. However the “root” component must provide everything explicitly by using getters in the component.

E.g.:

@Component LibComponent {
 ExportedType1 getExportedType1();
 ExportedType2 getExportedType2();
}
Etc

Module providers in the LibComponent are not exported to the dependent component unless explicitly stated that way. If something needs an explicit module provider, it also needs an “exporter” declaration in the component. If something is not explicitly exported by the root component, dagger will try to use the type as-is, notice the scope discrepancy and basically ask for either a different scope or an explicit provider if the object has no scope.

[win] d: t/dev/jadx … jadx-gui

select apk

prefs select deobfuscation

save gradle project in e: temp android apk

In the “game with train themes” department, it would be interesting to find an engine with actual already available resources to make one demo sample of either. One thing I could learn is the interaction model.

As far as 3D engines go, Godot seems like a viable choice for my needs. That or a full “do it yourself” LibGDX-based approach like I was trying for Tracks.

Eventually it all boils down to assets. That’s the key thing, and the one weakness I strongly have. Looking at both above: The train shunting puzzle is within my reach; except I’m not keen on the end result and thus consider not worth the effort going there; and the large popular game is out of my reach, the number of 3d assets being way beyond my abilities.

It’s also the same usual problem: I’m looking at a bunch of game demos, and realize I don’t really want to spend that much time to get that level of result (the usual 80/80 rule applies here). And I don’t want a me-too result either.

One feature I miss with trains is scripting. Back in 2014 or 2015, I wrote a very simple cab command interpreter in python for JMRI, “cab3.py”.

I should add something like in Cab Engineer:

• Tie it with an existing throttle (e.g. for a specific DCC address)
• Or let the script change/mix engines.
• Be able to save / recall scripts.
• Also control turnouts.
• Introduce a mini-editor with a less cryptic language, and buttons to quickly insert language keywords.
• Make it line-agnostic so that the script can be one line or multi lines.

Random examples:

Label start

Throttle 537 speed +12 for 5s until B370 then speed 0

Reverse T330

F2 press

F5 on

Throttle 113 speed +12 for 2s

Speed 0

Speed -12 for 2s

Normal T330

F5 off

Throttle 537 speed -12 for 5s until B310 then speed 0

Loop start

Here each command is one keyword + one value, and the “then” keyword is a no-op.

A command like “for” or “until” would simply introduce a pause.

A “function press” would toggle it for a fixed time, e.g. 300-500 ms.

A logical extension is a “record macro” mode, that records the actions, generates the script, which can then be edited, saved, recalled.

Recalling a script would open a card on the recycle view with a status/run/stop. Running would “inject” commands in controllers, but not block the user. E.g. one could try to “beat” the system, or start/stop an engine during a macro run. Useful for things like horn/bell, or prevent a collision.

A follow up to 2020-04-04 Cab Throttle aka “Cab Engineer”: Importing Cab Throttle source has been done. It’s called “Cab Engineer”, and as all the source from Cab Throttle + WiThrottleLib.

The project has been changed to be compliant with Permanent Service & notifications required by API 26+.

Next steps are:

• Add dagger support.
• Use my mini RxJava instead of the event bus.
• Add new features:
• Toggle turnouts. [added as of 2020-04-10]
• Recall previous DCC addresses.
• Recall JMRI roster.
• Some less important yet desirable features for me:
• Support Day vs Night modes (with a quick toggle change).
• Support “soft” consisting.

I may not do it in that order. E.g. dagger/rx are less useful than core new features.

Note that when I started it, WiThrottleLib was able to support 2 modes:

• “Single throttle protocol” with multiple sockets to JMRI, for JMRI < 2.
• “Multi-throttle protocol” with a single socket to JMRI, for JMRI >= 2.

Now that JMRI is in v4, I think the “< v2” support is… useless. I won’t remove it but I won’t extend it either. Things like roster & turnouts are only going to be added to the more modern part.

As for the name, I'm pretty sure I don’t want to tie it to the “DCC” name publicly, even though the current implementation is very DCC and JMRI centric. E.g. for addresses, only DCC specs are supported, with short vs long addresses.

I’m currently in the process of a full rewrite of Cab Throttle, and to make a long story short, I decided to entirely rewrite it. Cab v2 is the new project.

Somewhat of a tangent, looking back at Cab Throttle vs Cab v2 makes me wonder: is LibUtils useful anymore?

Maybe, but I think it’s time to change from android-lib-v2 to android-lib-v3

https://bitbucket.org/ralfoide/libutils/src/android-lib-v2/LibUtilsAndroid/build.gradle

One of the issues here is the cross-project dependencies. LibUtils depends on Dagger, on Mockito, on Robolectric, and on JUnit. All these versions must match together, otherwise imports get wonky. Robolectric and Dagger are the main drivers and are very opinionated.

For example that means I can’t have a lib with Robolectric v3 and a main project with v4. And even within versions, I’ve had conflicts when multiple JUnit or Mockito libs are imported.

One thought is to fix that by revisions. Lib-v2 goes up to Robolectric 3, and lib-v3 is to be used for “modern” projects with Robolectric 4.

Tutorials / intro / 2d game step by step:
https://www.gamefromscratch.com/page/Godot-3-Tutorial-Series-Index.aspx

https://godotengine.org/download/windows

The download is not an installer, it’s the full thing just zipped in-place.

Which means if I won’t use C#, just use the standard thing and I can always trivially change later.

“Godot… standard vs Mono C#” -- the difference is that the 2nd supports everything(?) including C#, whereas the former is limited to using GDScript (a python look-alike). I’d venture the C# one is designed to ease people coming from Unity.

The C# version requires the Mono SDK: https://www.mono-project.com/download/stable/

Or the Visual Studio Build Tools: https://visualstudio.microsoft.com/downloads/?q=build+tools (which seem packaged separately from the full VS.Net?)

Thus going with Standard for now.

Doing what?

Either 2d or 3d (fixed perspective, toy like rendering), something with trains and tracks. First do a prototype demo to see if I can even render what I like. Game wise I'd like a tower defense/attack.

Pending home projects, in that order, that I’d really like to see completed this year:

• React Otter:
• For the demo, finish learning how to do the data-server backend part.
• For the MVP, implement a cron task sending tweets & creating images.
• Conductor 2:
• Finish the Groovy design. It has potential, yet right now it is in an unfinished design state.
• Rework the implementation with a focus on tests.
• ESP32-CAM:
• Work on video track detection, with the smaller goal of doing a crossing gate controller.
• The desire is for that work to be later used to control Fairfield or other automation.