Visual cues on played/unplayed video files

[octacode]

We'd like to display the last time the file was opened of the file to the user. The most feasible approach for this is to show the last opened time in the ListView.

Also for this I'd recommend using SQLite with three entries:

1. Path (Stores the path of the file).
2. Time.
3. Date.

[adi23arora]

@octacode So, how are we planning to implement this, using Android's SQLite APIs or Room Persistence Library? I would prefer the latter because it involves less boilerplate code and is less time-consuming.

[octacode]

Room Persistence Library is good option, however the present code uses Android's SQLite APIs and also including Room will increase the apk size, and we don't really want it cause we already are at 80.1 MB :open_mouth:

[adi23arora]

Yes, the apk size might be a concern here. So, where exactly the last opened date-time is to be placed in ListView?

[octacode]

In the list we are already displaying the last modified time which is fetched from the server, Honestly I want to keep that. What we can do here is that onLongPress we can show an info icon in the activated action bar. Clicking on which will open an alert dialog box with title as Info and it will contain the following details:

1. Name of the file
2. Mime Type
3. Size of the file
4. Last opened
5. Last modified

@cpg @csoni111 How does this sound to you? Also @adi23arora should I assign this to you?

[adi23arora]

@octacode Yes, please assign me, I want to work on this.

[octacode]

Assigned to @adi23arora .

Somehow I wasn't able to see his name in the Assignees, So for the time being this will do.

@cpg can you please look into the reason for this^.

[csoni111]

How about instead of storing the path of the file, we store a unique key for each file/folder. This key can be generated using some fields from its metadata like name, last_modified etc. This can be reused if it serves the purpose.

Also instead of storing the date and time separately, it will be easier to store just the timestamp/epoch in Long.

[octacode]

1. Yes we can store the timestamp instead of date and time separately :+1:
2. Why complicate it for us? Instead of having some keys which definitely are not going to be readable since they are comp generated we can have the path in the db entries (will make debugging a bit easier for us). Also there'll be overload of creating keys while we have direct access to the path of the file.

This way we'll have two entries:

1. Path
2. Timestamp

[anandwana001]

Just a suggestion We should use RecyclerView instead of ListView. Here are some benefits why to use RecyclerView instead of ListView

[adi23arora]

@anandwana001 Thanks for suggestion. But, in this issue we are only concerned about developing the last opened feature. We understand the advantages of RecyclerView over ListView and will be replacing them very soon.

[anandwana001]

If I could do that part by the time other are setting database!! can I?

[cpg]

This is my fault. I did not specify this feature properly.

I think the technical things are going to be largely the same or very similar.

Displaying a date is not what I meant. I don't think that is what people want. I meant some visual cue like bold name when not played, or, alternatively, slightly greyed out when played.

The definition of played is up for grabs: some have it so that when a video is played for more than, say, 10 seconds in a row, it's considered played. This is also per-user and video file (maybe audio files too? maybe not) in the app.

Sorry I should have been more clear.

Perhaps I should also have taken a step back regarding a DB. A DB can be somewhat generic for multiple uses.

One other feature that could be related using the DB is to display a "virtual share" Recent ... which is like an area that shows the latest files added to a given folder. There may be some back-end component, not sure.

So, before any considerations of a DB, it has to be structured in a safe way (any inconsistencies, crashes have to self-heal automatically), efficient way (scanning things recursively is not doable), and more ... we may need to work on specifying this separately.

[octacode]

1. For the visual part we can use slightly greyed out after it has been played. :+1:
2. Also should we implement this for just audio and video files after they have been played or for all Mime types.

I think then the db will only store the path of the video and audio files and duration of play also for the non media files we'll set the duration as negative.

While implementing there will be two check

if (file.getMime() == AUDIO || file.getMime() == VIDEO) {
    if (file.getStoredDuration() > 10) {
        // GRAY THE ITEM
    }   
}
else {
    if (file.existsInDb()) {
    // GRAY THE ITEM
    }  
}

[adi23arora]

1. As discussed, I guess now we're up for something different than asked for. Should I continue with last opened feature?
2. About the Played and NotPlayed thing, should it be implemented locally because it won't persist when app is uninstalled or app's data is cleared. I think that it should be stored on server and then it can be synced across all clients on different devices and platforms like mobile apps(iOS, Android) and Android TV app.
3. I think along with the above feature we can also implement a feature like resume from last stopped position. This could prove to be useful when a user quits app due to some other work and when he restarts he could resume from the previous stopped location.

[cpg]

1 - The feature is not different in essence, just what is shown. 2 - No, I don't think server-side is wise, though it's something that can be discussed 3 - Yes. I think we should list this feature as a separate issue. This is another use for the DB