Architechture enhancement

[blonsky95]

Look at a way of optimising the logic towards a cleaner architechture:

• what can be done with livedata and observers
• what functions can be grouped into blocks and take outside of mainActivity
• draw in paper the mainactivity and its functions and triggers and look better for architechture
• fragment situation

[blonsky95]

Things that should be changed

java -> kotlin - done async tasks -> coroutines - unused here deep view hierarchy -> constraint layout - done shared prefs -> dataStore- relatively new kotlin synthetics -> viewbinding or databinding - could change the speed display to databinding sqlite open helper -> room - unused here listview -> recyclerview - unused here intentservice -> jobscheduler or alarmManager - unused here

In general, leave all the business logic inside the view model and not the view

Design in paper how all the fragments and interactions work

If exoplayer is in the view and I have a reference to it in the view, can I succesfully update its position (frame advancing/reversing) or its playbackparameters from viewmodel? If not, do I simply use live data and observers to change speed and playback parameters, like updating a view (but setting the playback params)?

For fragment handling, have a better system, but first design the screen flow on paper, and then see what is more optimal

The way it checks for first times is fine about the sharedpref, but it sucks that every time main is created it checks for it

Can dialogs be handled through observers/live data?

[blonsky95]

Moving stuff to viewmodel (MainViewModel) instead of the view (MainActivity), so ideally the view doesnt carry out the methods on itself, its the viewmodel that triggers them through livedata (and view observes)

• setupFullScreen is now in MainViewModel, as well as registering the systemUiVisibilityListener for the window.decorview
• permissions will stay as it is for now
• separate comment to talk about the exoplayer config new class

[blonsky95]

The media player logic is going to be taken outside MainActivity

Class VideoPlayerController Takes exoplayer, datasource factory, initializes everything and controls speed, frames... creates an interface MediaPlayerCustomActions with the following methods: fun goForward() fun goRewind() fun goNextFrame() fun goPreviousFrame() So MainActivity then gets them from here, so it only registers the clicklistener, there is no logic in the MainActivity this way.

Next - do the exoplayer calls in the lifecycle events like onPause and onDestroy - then check the todos in videoplayercontroller to make calls to MainActivity UI like resetting speed and shit

OK everything exoplayer related class is done

On another note when resetting buttons and videosource change, there is a speed reset that should be done with fragment listening to viewmodel livedata but not worked first attempt so atm, the reset speed function forces a call to the hard Ided fragment method (meh).

[blonsky95]

Doc on VideoPlayerController

/**
 * Bit of explaining, this class requires an exoplayer instance, a dataSourceFactory and a TestInterface
 *
 * It will handle
 * - preparingvideosource
 * - getCurrentPosition
 * - configure the custom actions of the player controls e.g. forward, rewind, next/previous frame
 * - stop/play video
 * - set speed of playback
 * - listener for player state - READY, END, BUFFERING, IDLE...
 */

[blonsky95]

Moved logic to viewmodel for:

• user gesture listener to trigger the fullscreen or/and show/hide the action fragments
• prompting user to rate app plus the actual rating window

next: (CHANGE THE CODE FOR PROMPTING BACK TO NORMAL) and then billing? and fragment appearing?

[blonsky95]

next - take timesplit controller elsewhere - modify it - DONE next - free trial - 1 per day - DONE next - billing + getting subscription dialog - DONE next - fragments appearing - DONE

[blonsky95]

clear time stufff between videos - DONE

[blonsky95]

So for BillingClientLifecycle,

There is LiveData in that class that I need to observe to get informed of information retrievals and things, but making the viewmodel observe that is not good.

Instead, the mainActivity will continue to observe the billingClientLifecycle variables, but call the mainViewModels functions to carry out the response code. It will observe through mainViewModel.billingClientLifecycle.variablename.observe

NEEEEEEXT alright going to need to test billing client well

also write in paper how many times main activity and mvm are actually exchanging info and see if i can be more efficient with the flow

[blonsky95]

Will test in a bit but the dialog/bCL logic/architecture is:

mainActivity observes the livedata in bcl which is inside viewmodel. From here it gets to know if it has to

• display possible subscription plans
• display already subscribed status
• display error

So when this livedata is updated, mainactivity calls its respective method in viewmodel, which will update the AlertDialog LiveData. When updated, the observer response is to dismiss (if there is) any dialog before that, and display the new one. So its a BCL --> mainactivity --> viewmodel --> main activity ---- communication as to say

[blonsky95]

next - fragments appearing - NEXT - did the onbackpressed viewmodel via - continue fragments - NEXT - DONE