Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

shows files in Files app and iTunes sharing done #143

Closed
wants to merge 0 commits into from

Conversation

iswiftshek
Copy link
Contributor

@iswiftshek iswiftshek commented Mar 14, 2019

  • Updated Info.plist to show files in File app and enabled iTunes file sharing.
  • The files appear as shown below in the Files app:
    desk
  • We can add files to Amahi's directory in the files app through iTunes and access the downloads under "Apps" in iTunes. Here's how it looks:
    gifAmahi

Issues solved: #101

P.S. The files deleted or added through iTunes are shown in Files and can be opened, shared and deleted, but reflecting the same in the Downloads section in Amahi is yet to be done. So I'm currently working on that #142

@codedentwickler
Copy link
Member

Great job on this feature. @iswiftshek.
Seems you’re still working on the updates.

@cpg I understand why a user would want to add files to the App directly like in the VLC App.

But the files in the download folder are currently linked to a server share.

Perhaps, We could have another folder like maybe an “imported files folder”. Where the user is allowed to add in imported files from their device and we leave the current folder for offline downloads from an Amahi server.

It makes it a bit more complicated from what we thought about when we designed the offline feature.

If we have to do it as you said, I think this will be an issue later if we don’t consider what is changing all through and what it affects.
I would advice we take a look at the offline feature issue and modify it to allow user use the files app to create and modify. Then we can modify our CoreData implementation to suit the new requirements.

I totally agree with what @cpg said in #142.

Quick question @iswiftshek Have you read through this issue and the documents attached?#101, I want to be sure you understand the current implementation.

Another concern is how does this affect our offline implementation on the Android app?

@iswiftshek
Copy link
Contributor Author

Great job on this feature. @iswiftshek.
Seems you’re still working on the updates.

@cpg I understand why a user would want to add files to the App directly like in the VLC App.

But the files in the download folder are currently linked to a server share.

Perhaps, We could have another folder like maybe an “imported files folder”. Where the user is allowed to add in imported files from their device and we leave the current folder for offline downloads from an Amahi server.

It makes it a bit more complicated from what we thought about when we designed the offline feature.

If we have to do it as you said, I think this will be an issue later if we don’t consider what is changing all through and what it affects.
I would advice we take a look at the offline feature issue and modify it to allow user use the files app to create and modify. Then we can modify our CoreData implementation to suit the new requirements.

I totally agree with what @cpg said in #142.

Quick question @iswiftshek Have you read through this issue and the documents attached?#101, I want to be sure you understand the current implementation.

Another concern is how does this affect our offline implementation on the Android app?

I think I got it. I'll try and do it asap

@cpg
Copy link
Member

cpg commented Apr 1, 2019

But the files in the download folder are currently linked to a server share.

What is the reason for that?? It seems like a design flaw.

The way I see it, once a file is in the downloads area, it's independent (well, and really, irrelevant) where it came from. How does it matter that it came from share X or Y or in share W in folder Z?

It's not like the user can upload it or sync it back to the original location or anything.

Adding an extra folder is adding a layer of complexity to the problem for something that in my mind is irrelevant.

@codedentwickler
Copy link
Member

Okay @cpg. I'll update the offline implementation so the offline files have no ties to where they are downloaded.

@cpg
Copy link
Member

cpg commented Apr 6, 2019

ok, I filed #155 for that internal design issue of files being linked to the origin.

Is this ready to go? Does it add any extraneous things like an extra folder or whatever?

@codedentwickler
Copy link
Member

No @cpg, Once we remove the link between offline files and their server locations, then how the files get to the download folder does not matter anymore.

@codedentwickler
Copy link
Member

codedentwickler commented Apr 6, 2019

However what we would need to change is how files gets displayed in the offline folder.

Currently, we are managing it with CoreData(iOS version of a database), i.e we download the file to the folder and add a record that contains information about the media files in CoreData. Then to display a file in Offline. We basically read all our records in the Database.
When files get deleted in the app, we delete the corresponding record.

But if the user drops the file directly to the download folder, we won't have a record linked to that file in our database. Hence the file wont show in the offline section for now.

@codedentwickler
Copy link
Member

We can update this by coming up with a way to add records to our database whenever the user add files directly to the folder.

Another way would be to read the download folder and add the files not linked with our database directly in the offline section.

@iswiftshek
Copy link
Contributor Author

I was fixing branches on my repo, I hope I didn't break anything here.
iTune sharing is a minor change in .plist, I'll fix/update (if anything needed) in the next PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants