A while ago I wanted to take a consistent approach at splitting my projects into a “UI vs core” pattern. My old C# skeleton generated 2 libs upfront for that. In other android apps, I have either an android lib or at least clear packages “core vs ui”.

Looking at something like Flutter, the benefits would be useful if the app and UI is using one framework and then the “core” of the app uses another framework, namely a POJO or at least an Android lib. In the case of a game, the latter could be a Unity library.

When doing a pure Android app of a limited scope, there’s little value in that separation. It becomes more useful when I try alternate frameworks, for example Flutter or Kotlin. The idea is that if I write the UI part in Flutter now and the framework falls in desuetude, I could rewrite just the UI later.

One thing I noticed is that if I do not force myself to do the split upfront using actual libraries, it will not happen easily after. Forcing to have an android app + an android lib imposes some constraints in the import/dependency structure. It forces us to make callbacks instead of direct bi-directional calls. It forces us to make the boundaries clear. Dagger would help a bit to ease using one with the other.

As far as patterns go, there’s MVP and MVC. I suggest a mix, which I’m calling MCVP:

• Model: Model data/classes, in the core feature library.
• Controllers: Action classes acting solely on the model, in the core feature library.
• Views: Pure UI elements display model, in the app/ui library.
• Presenters: Action classes managing the interaction, in the app/ui library.

The app logic would be both in controllers and presenters. The controllers are purely model-oriented and by having them in the core lib, they have no impact on the UI. The presenters on the other hand coordinate between the views, model, and controllers. They are the “business logic” that is located at the app/ui level.

As a graph, we would have:

[model] ⇐⇒ [controllers] ⇐⇒ [presenters] ⇐⇒ [views]

It’s time to get a look at Flutter… What would this be good for?

https://flutter.dev/docs/get-started/install/windows

Now the question is what will be the throw-away project and the goal for it?

One thing Flutter targets is Android vs iOS and then “rescalable” app for Chrome OS.

It does not do “web apps” per se. It is not a server-side html thing.

I was going to start a “Service [idea]” doc as a Summer Project, but honestly at that point it’s more like a reboot as it feels really deja-vu:

• Menerba is the obvious canonical example.
• Home Monitor App.

Not every far:

• Mobile dev and Hint v3.
• Ikaria and Ikaria v2.
• And of course “\pɔʁt.na.wak\” as a meta-meta project.

Part of the motivation for Portnawak was exactly what the name says, it’s a place to put temporary projects without the pretense of ever finishing them. They can be left there and not be too visible, so it’s not an inconvenience to anyone.

This looks worth looking into for the kids:

https://microbit.org/guide/quick/ 

Should be around $17 per kit.

https://www.adafruit.com/product/3362 (properly packaged I guess)

https://amzn.to/2Dh7Wb7 (not the full kit, see comments)

Showed that to the kids. Is it interesting? Maybe. Should I get one? Nah. OK fine I tried.

Of note:

• RPi 1 = 700 MHz Arm11
• RPi 2 = 900 MHz ARM Cortex-A7, 1 GB RAM (all 2 and 3 models)
• RPi 2 = 900 MHz ARM Cortex-A53
• RPi 3 = 1.2 GHz ARM Cortex-A53, arm64.
• RPi 3 B+ = 1.4 GHz ARMv8, arm64, 1 GB RAM.
• USB/Eth combined with 30 MB/s max.

https://www.zdnet.com/pictures/top-12-raspberry-pi-alternatives-2018-edition/

Similar clones:

• NanoPi NEO4, $45
• Rockpi4
• Libre.Computer “Le Potato”, $45 on Amazon with 2 GB RAM
• UDOO makes the NEO (an RPi like), an x86+arduino, and the Dual is some kind of Android/Arduino DUE mix. One has SATA.
• VoCore has a super-mini linux box (1 inch square), limited RAM, etc.

Depends on needs:

• For very low computing, the VoCore seems interesting. The Nano/Rock Pi are just clones with no specific advantages (cpu speed maybe?)
• Le Potato looks interesting, until one reads the comments about the limits of the Linux distro with specific builds made for it.

The problem with those is the custom linux kernels. It means no “default debian” install (even with the RPi3), but at least Raspbian is well maintained (and the official way to go). For some of the other boards, the deal is more muddy, with typically a single image to deal with, no updates. For example the BeagleBoards have precompiled kernels and linux images to be installed as a whole. This is good from an IoT “fire and forget” standpoint but much less attractive to customize the distro & keep up-to-date with security patches.

Maybe I should take another look at BeagleBone/Board (board matrix): the Black is a bit under an RPi 3 (1 GHz Arm A8, 512 MB RAM, $65 Amazon, $55+s/h e14/mouser), the SanCloud version has 1 GB RAM & Gigabit eth ($60-80). [Note: names were BeagleBoard before 2010, and BeagleBone after 2010].

I happen to have a BeagleBone Black. I should use it. Which rev? What specs?

• Markings: “PCB Rev B3” (in black other side of power plug). “STM-5 94V-0 1013” next to eth, proc “XAM3359AZCZ100”, eMMC U13 “3DA18 JW896”, DDR3 U12 “2ZE12 D9PXV”.
• BeagleBoard images & instructions: https://beagleboard.org/latest-images
• List of revision changes: https://elinux.org/Beagleboard:BeagleBoneBlack#Board_Revisions_and_Changes
• Rev B has 2 GB of eMMC (Armstrong Linux pre-installed); Rev C has 4 GB of eMMC with Debian pre-installed.
• The one I have appears thus to be a Rev B with 2 GB of eMMC.
• Confirmed by eMMC Micron JW896 [FBGA part search] ⇒ Micro part MTFC2GMVEA-0M WT, and “MT FC 2G” is the Micron model code for a 2 GB NAND Flash [link].

Here’s a random idea: try Dart for a web project.

Here’s another random idea: While not rewrite Track for the web?

• Data files provided by a web server.
• User accounts and all that: Firebase.
• 2d canvas editor.
• 3d view in browser?

One thing from “\pɔʁt.na.wak\” experiment is that editing in 3d is a PITA. I should focus on a 2d editor and then adapt it to 3d as it’s not my strong point.

Also I didn’t like the model I had in Track, especially the connectors. It seemed like a good idea initially but ended up troublesome. Tests were inadequate.

If I wanted to try Dart, there are 2 other possible projects:

• Rewrite Wazz.
• A bit moot since there’s nothing complicated nor wrong with the current version. It could be an interesting test to get a direct comparison between Dart and pure JS ES6.
• Write a simple single-page web-page game. Nerdkill for example ;-)

Next thing to try: Windows Linux Subsystem.

Can it replace Cygwin?

Does it integrate nicely with win ntfs / apps?

[Summary from the FAQ] ⇒ Provides a bash shell and /mnt access to the win fs. Does not provide GUI support. Mentions apt-get (with potential errors due to a lack of udev).

I should also (re)learn Powershell (again and/or for real) and take cheat notes on how to be proficient / use it.

Desktop app to access Wyze cams.

The TinyCam code seems easily reversible, and could be done as a desktop app instead of android.

To play an h264 stream, have a look at JavaCV https://github.com/bytedeco/javacv (Java wrappers around OpenCV ... can be useful for a lot of other applications).

In that specific case, a C# app might be better than Java as main target is Windows (potentially cross-platform with MonoDevelop, not sure if it’s even worth bothering here).

It’s a throw-away prototype, so failure is an option. The simplified goals would be:

• Start by simulating whatever tinycam came up with, because it’s an easy start.
• TinyCam only takes care of discovering and connecting to local live feeds.
• Need to realize this is not my end goal. What I want is really:
• View remote notifications.
• View remote live feeds.
• View remote playback feeds.
• Doing this would probably looking at the wyze apk with an ssl proxy to capture the json payloads.

Doing it in C# would be also a good exercise to do an UWP.

https://docs.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide

UWP:

• Requires/useful if using the Windows App Store
• Can be sideloaded in Win 10 if device is set in dev mode.
• APIs access to Win 10 features: Tiles, badges, Cortana, bunch of other crap.
• Various languages/UI combos supported: JS HTML, C# XAML, C++ DirectX.

So maybe UWP is overkill in this case. Just stick to a regular C# desktop with the old style C# gui builder. Use VS Community, and expect it to be ages behind in terms of code completion.

Why not a web app instead of a desktop app?

• Live viewing should work using any web page that can play an h264 feed. “In theory”?
• In the mobile app, notifications are seen using a download + local player. A web app could use local storage and/or just stream the video feed.

So it’s worth investigating, even if it turns out to not work well.

Results (done in JS):

• Public: https://bitbucket.org/ralfoide/wyze-web-interface/overview 

• Track: Has not changed since “\pɔʁt.na.wak\” dev in PA.
• Track is part of “\pɔʁt.na.wak\” and is supposed to be a throw-away “quick” project. At that point it’s worth thinking whether there’s some real long term value in the project and in which case build a real standalone one.
• What I need is a more generic way to describe track segments.
• And import the ones from SCARM.
• Then use it on my own layout design.
• The 2D view lacks precise geometry tools that I’d take as a given:
• rulers x/y,
• units (inch vs mm),
• ability to move something at a specific place by x/y coords,
• rotate by entering an angle,
• ability to measure distance,
• ability to dup/offset a track to another one (or an anchor point).
• NCE Cab:
• Wrote a “design doc” / spec / desiderata doc for it.
• Need to do a prototype.
• First need to validate can use the RS485 interface on Windows/Java & Linux/Java (instead of Linux/Python). That first test could be a simple Java port of the existing python nce protocol decoder, without the ncurses part.
• 3D Blender:
• Desired goal would be to have a quick export from Tracks or for Scarm into a blender file, then play with materials there.
• “Cab Engineer” Android Mobile WiThrottle:
• I’ve started this for my own need as part of the old JMRI / JED experiment, then made a single use app with Wear integration also as an experiment.
• I had some desire last to reboot that into a formal project.
• See “Cab Engineer” below in 2017-12-18 update.
• Randall replacement for the NCE Button Board.
• Desktop app to access Wyze cams

It’s interesting to consider scopes:

• Cab Engineer: For me + public app.
• Value for me: mild.
• Existing apps: Engine Driver.
• 3D Blender: Only for me.
• Track: For me + public app.
• Value for me: medium/high.
• Existing apps: Plenty on desktop (can’t match), none on Mobile.
• Would be satisfied if I could just match desktop Scarm.
• NCE Cab: For me + public / for club.
• Value for me: medium / low. Technical challenge.
• Experimental: high value.
• Finished product: low value.
• Public / club: No adoption realistically expected at all.

So of these, based on value:

• Track / desktop is highest.
• Track / mobile is for fun and shows some interest.
• NCE Cab for the experimental phase value.
• 3D blender for some moderate value.

Based on this my order is going to be:

• NCE Cab - experimental phase aka validation prototype.
• Track / desktop.
• Revamp of experimental project, focusing on Scarm level.
• No mobile target at first but keep in mind for feasibility.
• Track / mobile. Maybe.

Not so quick test in 3d + Java + desktop. Part of portnawak. Could be made in its own project.

What I want, for me:

• Android version.
• Touch UX
• Running trains.
• Save online. G drive, drop box.

Doc Link from “\pɔʁt.na.wak\” in google docs.