Bug Fix and Recycler View optimisation

[archie94]

Well I started this to eliminate the flicker first time an audio item is inflated. Turns it it is due to the view used to display the Wave form.

Anyways for multiple view type in a recyclerview we should use different layouts. This removes the burden of changing the visibility of items in onBind. This multiple view type maps well with the multiple type of EventTrigger we have.

This also removes a bug: clicking on any image in Event we always start the ImageViewer with startPosition = 0. This should be the index of image clicked.

[archie94]

Added index numbers to Logs and Event Triggers. Should resolve #337

[archie94]

Well I started this to eliminate the flicker first time an audio item is inflated. Turns it it is due to the view used to display the Wave form.

Regarding this the audio-waveform library documentation says not to call mWaveformView.setAudioFile(soundFile); from the main thread but that method calls invalidate() on a view which should only be called on UI thread. :/

Also the library seems un-maintained which brings me to the question should we look for an alternative?

[archie94]

Well I started this to eliminate the flicker first time an audio item is inflated. Turns it it is due to the view used to display the Wave form.

Regarding this the audio-waveform library documentation says not to call mWaveformView.setAudioFile(soundFile); from the main thread but that method calls invalidate() on a view which should only be called on UI thread. :/

Hmm in order to do this asynchronously it appears we should use WaveformView instead of SimpleWaveformView but getting frequent crashes on that.

[lukeswitz]

I realize this is a WIP but here's a few notes I get when testing, will supply logs if needed:

• mWaveform lib has been stale for a long time; it breaks things when setting encoder options for mic/audio. Very worth replacing. WaveformView with some async k-filtering would give us a usable value for calibration. Reuse it with sample rate & buffer increased for monitoring, maybe?
• Adding a line for # 1, # 2, etc, labeling is confusing/unnecessary, in my personal opinion. If the timestamps are readable & ordered, these remove needed real-estate on smaller devices
• sensor events not triggering camera/video recording: tested AOS 5.1.1 & 6 device & emulators. (Icons don't animate, no indication of anything being detected on the MonitorView)

All branches: ListView doesn't show the latest session until after the mp4 muxer is finished, which is never for legacy devices

• frame encoding issue when using fallback methods, likely ffmpeg. I'll try fixing this before opening a ticket. Thanks for your work, there's so much to be done once you look under the hood of this beast.

[archie94]

• Adding a line for # 1, # 2, etc, labeling is confusing/unnecessary, in my personal opinion. If the timestamps are readable & ordered, these remove needed real-estate on smaller devices

Well I feel we should keep some form of indexing given that triggers can occur in fraction of a second or even a few second(s) apart. Add to it if there are more than 100 triggers (say) in one session readability is hindered.

Having said that I understand where you are coming from and yes, adding one line for index does not help legacy / small screen devices. Let's explore better UI/UX options for this.

Thanks a lot for testing and these feedbacks. Much appreciated :D

[archie94]

Have changed the position of index number for trigger items. @lukeswitz please check if this makes sense.

[lukeswitz]

Makes sense, nice addition!

[n8fr8]

Thanks all, jumping back in here soon!