Description
Is your feature request related to a problem? Please describe.
I think exposed API from NSFileSystem is not coherent with the JS module and confusing. It does not allow to develop an application without relying directly on the JS API, a feature I think is important.
I am assuming the developer knows that for mobile platforms not all the file system is available to the application, that you have just some folder you can access without requiring special permission.
For this reason, the JS API expose knownFolders, which allow retrieving the path to these special folders in a future-proof way, and suggest to use this object as entry-point to the module, getting all the file starting from these folders.
For the Angular side instead, only the currentApp folder is provided, so to get the path to the temp and documents folders the developer has to rely on accessing to the knownFolders object to get the correct paths.
At the same time, the NS class offers two methods that directly access the file system, which might be useful in some situations but take the developer to hard-code paths or to, again, rely on knownFolders object from JS API.
Describe the solution you'd like
I suggest adding to the NSFileSystem API methods to retrieve documents and temp folders, together with providing an iOS custom class which provides the iOS-only folders offered by knownFolders.
Also, export from the ns-file-system.ts file the File and Folder class, so that developers do not have to import the JS API to access the file system anymore.
I would also suggest deprecating the use of fileFromPath and fileExist to discourage the use of hard-coded paths, which in the context of multi-platform mobile application I think is bad practice.
I would submit a pull request myself, I just need guidance about the iOS-only part of the task, and help to test since do not have access to an iOS environment or device.
EDIT
I want to add that I am assuming that one of the objectives of the nativescript-angular module is to provide the same set of APIs offered by the others non-Angular module in an Angular-friendly way, so as to allow the developer to use the existing dependency-injection facilities offered by the framework.