Mapper: Color choice in Paint-on-template

[ollesmaps]

The color selection on Paint-on-template could be bigger.

Plus pink, orange, light green, violet, light blue, dark brown. It can be optional which colors and how many to add.

More colors mean more readable scribbles. For example now I have to draw all greens in one type of green and add letters inside them to give it meaning. That makes it less legible. In "mylar and pencil" mapping I used for example green for fight, orange for walk and pink for runnable thickets.

Mapper Version: 0.7.0 (Android App)

[dg0yt]

How many colors will you need in total?

[ollesmaps]

I would say 12 would be optimal. 14 would be a luxury.

I counted colors I used on mylar and that was 9. However if I applied some pressure I got different shades. So in total it was 12 colors.

[ollesmaps]

I gave it some more thinking: The colors shall have different shades than map symbols (ISOM). For example now green has the same shade as ISOM green, so it is hard to distinguish between green on template and vector green (to distinguish between what has been vectorised and what not).
Of course that relates to ISOM and if there is a non-ISOM map the clashes might be different. So a custum made palette would serve best.

[lpechacek]

A test build is available from http://liborpechacek.wz.cz/oomapper/OpenOrienteering-Mapper-refs_pull_1738_merge_v20200925.1-Android-armeabi-v7a.apk

[ollesmaps]

It works! I am excited :100:

[ollesmaps]

I experienced a peculiar crash with the above mentioned test build.

• All information in worked upon template _Draft @ 46...png_ got lost.
• This png file got corrupt.
• You could still see it in template list, however OOM could not open it.
• This oom file was saved short time before the crash - vectors, gpx were all fine, the rest of the templates were fine as well
• This png was saved even before this mapping session, previous day.
• The trigger was perhaps a multitouch - I was receiving a phone call and clumsily handled the tablet (but could be also something else).
• I later inspected this file and it was 0 kB, when opened in Notepad - no information inside

[dg0yt]

The trigger was perhaps a multitouch - I was receiving a phone call and clumsily handled the tablet (but could be also something else).

More likely: Android decided to terminate the app forcefully. It probably asked to quit before, but saving changed data took too long.

However, we need to check why saving the PNG didn't happen atomically (valid old version or valid new version, but never broken).

[ollesmaps]

Just to be clear: tablet and phone were two separate instruments.

[dg0yt]

Just to be clear: tablet and phone were two separate instruments.

All right.

Anyway, you do want #1785 to be resolved.

[lpechacek]

More likely: [...] It probably ...

For the record, I looked into the possibility of getting the application crash dump from the end-user device. This is what I found:
1) adb logcat is the way but requires the user to activate Developer mode, install NDK, and play with cables. Not usable in the field and not everyone will be up to the task.
2) Logcat Reader app allows reading and capturing the system log in the field. However, it requires root access or permission settings that can be granted only through adb, making the app installation similarly difficult as 1).
3) Android bug report is Android built-in functionality that collects the system status, including the last ten application crash reports, and packs it into a .zip archive. The process is two-step: enable developer mode (once), generate bug report and share it. The only downside is that the full report contains a lot of system details, which might not be a comfortable setting for some users.
4) For the sake of completeness, Google Play reportedly collects crash reports from end-user devices and makes them available in the console. I have no first-hand experience with this option though.

[dg0yt]

Bonus question: When the app is terminated forcefully, is this considered as a crash at all?

[lpechacek]

Bonus question: When the app is terminated forcefully, is this considered as a crash at all?

I've made a test and it looks like there are no tombstones for terminated applications. For instance, this is how the log records look like for a Mapper instance that was terminated due to an out of memory condition:

12-31 11:20:21.381  1000  2944  2944 I SurfaceFlinger: id=10210 Removed Background for -SurfaceView - org.openorienteering.mapper.developer/org.openorienteering.mapper.MapperActivity@b0864e2@0[263
40]#0 (0/43)
12-31 11:20:21.382  1000  3406  3416 I WindowManager: WIN DEATH: Window{5c12d9c u0 org.openorienteering.mapper.developer/org.openorienteering.mapper.MapperActivity}
12-31 11:20:21.382  1000  2944  2944 I SurfaceFlinger: id=10209 Removed SurfaceView - org.openorienteering.mapper.developer/org.openorienteering.mapper.MapperActivity@b0864e2@0[26340]#0 (0/42)
12-31 11:20:21.382  1000  3406  4535 I ActivityManager: Process org.openorienteering.mapper.developer (pid 26340) has died: fore TOP (2060,257)
12-31 11:20:21.383  1000  3406  3425 W libprocessgroup: kill(-26340, 9) failed: No such process
12-31 11:20:21.384   nfc  3866 21728 D ForegroundUtils: could not check pending caller
12-31 11:20:21.384  1000  3406  4535 W ActivityManager: Force removing ActivityRecord{20f0f47 u0 org.openorienteering.mapper.developer/org.openorienteering.mapper.MapperActivity t1314}: app died, no saved state
12-31 11:20:21.386  root  2987  2987 I Zygote  : Process 26340 exited due to signal (9)
12-31 11:20:21.389  1000  3406  3425 W libprocessgroup: kill(-26340, 9) failed: No such process
12-31 11:20:21.389  1000  3406  3425 I libprocessgroup: Successfully killed process cgroup uid 10220 pid 26340 in 6ms

It seems that the ActivityManager: Process org.openorienteering.mapper.developer (pid 26340) has died: fore TOP (2060,257) is the most informative part in that all. HTH