[TIMOB-7119] iOS: Filesystem.getFile() - path always relative to Resources instead of calling context
| GitHub Issue | n/a |
|---|
| Type | Bug |
|---|
| Priority | Low |
|---|
| Status | Closed |
|---|
| Resolution | Won't Do |
|---|
| Resolution Date | 2020-01-09T19:36:44.000+0000 |
|---|
| Affected Version/s | Release 1.8.0.1 |
|---|
| Fix Version/s | n/a |
|---|
| Components | iOS |
|---|
| Labels | parity |
|---|
| Reporter | Bill Dawson |
|---|
| Assignee | Ingo Muschenetz |
|---|
| Created | 2012-01-11T16:46:10.000+0000 |
|---|
| Updated | 2020-01-09T19:36:44.000+0000 |
|---|
Description
If a relative path is passed as the first argument to Ti.Filesystem.getFile(..), that path is interpreted differently, android vs. iOS:
* In Android, it's relative to the calling context. So if the getFile is called from within a window with JS url "a/b/c.js", then the path argument to getFile (if relative) is interpreted as being relative to folder "b".
* In iOS, a relative path passed as first argument to getFile is interpreted as being relative to root Resources, no matter which code is calling it.
Fail Case / Test Case App
Attached GetFilePath.zip contains app that, when run on Android, will show a graphic on the _second_ window. On iPhone, it won't show the graphic and you'll see "ERROR Couldn't get image file" in console.
Attachments
Based on discussions in today's parity meeting, there seems to be agreement that Android's current behavior is the correct one (paths are relative to the current script). I'm changing this to an iOS bug and updating the docs accordingly.
It has been decided that this issue should be closed as “Won’t do.” This issue is out of date with our current supported SDK release (7.5.2.GA as of the date of closure), and out of date with mobile OS versions. If community members feel that the issue is still valid, please create a new ticket. Please reference this closed ticket number, include SDK used, comments, and code that demonstrates/reproduces the issue.