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

ios: fix exporting files (CSV exports, log export, notes export) #2939

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

benma
Copy link
Contributor

@benma benma commented Sep 27, 2024

Similar to Android, we set ExportsDir() to "" and let the backend environment getSaveFilename() construct the full path.

Mobile handling of the dirs/files is a big hack and works on implicit assumptions, e.g. that getSaveFilename() is always called with filepath.Join(exportsDir, filename), which is only the filename on mobile as ExportsDir() returns "". This should be cleaned up, but for now iOS is made to behave like Android in this regard.

@benma
Copy link
Contributor Author

benma commented Oct 10, 2024

Ping @Beerosagos in case you missed it

class GoEnvironment: NSObject, MobileserverGoEnvironmentInterfaceProtocol, UIDocumentInteractionControllerDelegate {
func getSaveFilename(_ fileName: String?) -> String {
let tempDirectory = URL(fileURLWithPath: NSTemporaryDirectory(), isDirectory: true)
let fileURL = tempDirectory.appendingPathComponent(fileName!)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need a guard for fileName, like the one used in systemOpen for the urlString

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am unsure how filename could actually be nil here, any clue? That's why I just used fileName!.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree it should not happen, but from what I could understand, the app would crash if that happened. I just felt that in the future we may exploit this method somewhere else without realizing that it is not safe against null values. wdyt?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fixed it, but I still disagree 👅 this is in the GoEnv interface, so it will only ever be called by the Go backend, and there is no "nil" string in Go. I am unsure why gomobile even types this as optional, it seems almost like a bug.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah now I see your point! I didn't consider that strings are not pointers in Go 😇 Then I agree with you. Feel free to put it back to how it was initially. Maybe it would be nice to have a comment explicitly stating why we don't need the guard, tho

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

return scene.windows.first(where: { $0.isKeyWindow })?.rootViewController
}

func systemOpen(_ urlString: String?) throws {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The function doesn't throw any exception, I think you can remove the throws keyword

Copy link
Contributor Author

@benma benma Oct 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can remove it - this whole class adheres to MobileserverGoEnvironmentInterfaceProtocol, i.e. it follows the Environment interface in backend.go. I assume gomobile translates a Go error return to throws:

SystemOpen(string) error
(i.e. if an exception is thrown, it is translated to a Go error, similar to how it is done in Android/Java).

@benma benma force-pushed the ios-export branch 2 times, most recently from 5302525 to 212d401 Compare October 21, 2024 10:52
@benma benma requested a review from Beerosagos October 21, 2024 10:56
Similar to Android, we set `ExportsDir()` to `""` and let
the backend environment `getSaveFilename()` construct the full path.

Mobile handling of the dirs/files is a big hack and works on implicit
assumptions, e.g. that `getSaveFilename()` is always called with
`filepath.Join(exportsDir, filename)`, which is only the filename on
mobile as `ExportsDir()` returns `""`. This should be cleaned up, but
for now iOS is made to behave like Android in this regard.

We use a temp directory for these files, so the files will be cleaned
up automatically after a while.
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.

2 participants