Okay, so in the process of getting Dynamic Windows Interface Builder to work on Android, I discovered the frustrating source of an issue I was having during the testing of Android in the 3.2 cycle. Essentially the issue is that sometimes the file path returned by dw_file_browse() is inaccessible. I chalked that up to security settings and such, but I discovered workarounds for it by putting the files in different places during my testing. Now with the testing and the need for this function to work as intended in 3.3 for use in the Interface Builder, it has become very clear to me... many of these locations that dw_file_browse() can return are not accessible through the normal filesystem... even if they are verifiably in the locations being returned. The code that returns the path to these files is rather complex, since the API gives us a URI and then we look at the type of URI and figure out the path based on it... if the URI is even resolvable to a path.
Over the course of trying to get it to work in Interface Builder I tried many things... but no matter what I did, some of these URIs, when resolved to a path... and then the path verified in the Android Device Explorer... they would not open via the path either by the native APIs nor from Java/Kotlin APIs. They only are able to be opened via their URI. I discovered there is a way to open the URI and then return a native file descriptor which can be used for IO.
So I added an API specifically for Android dw_file_open() which calls Java/Kotlin fileOpen() function which can open a URI and return a file descriptor. I had been using xmlParseFile() to open the XML, which takes a file path... so this would not work, but fortunately there was a xmlReadFd() which takes a file descriptor. So using this I was able to get Interface Builder to function on Android. (On other platforms dw_file_open() is just a macro to the system open() function)
The problem with this approach is the path returned by dw_file_browse() on Android would no longer be a path, it is a URI instead. So any code that manipulates the path would likely fail because the URI format is completely different. So my current approach is to return both the physical path AND the URI from dw_file_browse() on Android. It returns two back to back strings with a leading \n (newline) before the second string... the first string is the physical path and the second string is the URI. This allows the Android dw_file_open() to locate the second string and pass the URI to to the fileOpen() function allowing it to open and get the file descriptor. This approach allows dw_file_open() calls to function and the main string returned by dw_file_browse() is a physical path that matches the format on all other platforms.
The drawback to this approach is that the physical paths it returns on Android are mostly useless. It really requires the URI to do any file access.
So thinking about other approaches, I have come up with a few options. Adding flags for 3.3 to pass to dw_file_browse() that will change the behavior.
1) Make the default behavior of dw_file_browse() to return a path OR a URI... apps would need to check if it is a URI by something like strstr(path, "://") and if it is a URI use dw_file_open() (or some other name for this function ... maybe dw_uri_open()) which would be able to open the URI on platforms that need to open URIs like Android. Then add flag to force dw_file_browse() to return a URI or a path, maybe: DW_FILE_URI and DW_FILE_PATH.
2) Make the default behavior of dw_file_browse() return a path, which may not be openable on platforms like Android. Adding a flag to dw_file_browse() to force it to return URIs like DW_FILE_URI which would require using dw_file_open() or dw_uri_open() to open the result.
3) Make dw_file_browse() always return a path, which may not be openable on platforms like Android. Add a new function dw_uri_browse() which returns URIs on all plafroms and requires dw_uri_open() to open the result.
All options would require code changes to work on Android, some options would require changes on other platforms.
Does anyone have any thoughts on these changes?
Over the course of trying to get it to work in Interface Builder I tried many things... but no matter what I did, some of these URIs, when resolved to a path... and then the path verified in the Android Device Explorer... they would not open via the path either by the native APIs nor from Java/Kotlin APIs. They only are able to be opened via their URI. I discovered there is a way to open the URI and then return a native file descriptor which can be used for IO.
So I added an API specifically for Android dw_file_open() which calls Java/Kotlin fileOpen() function which can open a URI and return a file descriptor. I had been using xmlParseFile() to open the XML, which takes a file path... so this would not work, but fortunately there was a xmlReadFd() which takes a file descriptor. So using this I was able to get Interface Builder to function on Android. (On other platforms dw_file_open() is just a macro to the system open() function)
The problem with this approach is the path returned by dw_file_browse() on Android would no longer be a path, it is a URI instead. So any code that manipulates the path would likely fail because the URI format is completely different. So my current approach is to return both the physical path AND the URI from dw_file_browse() on Android. It returns two back to back strings with a leading \n (newline) before the second string... the first string is the physical path and the second string is the URI. This allows the Android dw_file_open() to locate the second string and pass the URI to to the fileOpen() function allowing it to open and get the file descriptor. This approach allows dw_file_open() calls to function and the main string returned by dw_file_browse() is a physical path that matches the format on all other platforms.
The drawback to this approach is that the physical paths it returns on Android are mostly useless. It really requires the URI to do any file access.
So thinking about other approaches, I have come up with a few options. Adding flags for 3.3 to pass to dw_file_browse() that will change the behavior.
1) Make the default behavior of dw_file_browse() to return a path OR a URI... apps would need to check if it is a URI by something like strstr(path, "://") and if it is a URI use dw_file_open() (or some other name for this function ... maybe dw_uri_open()) which would be able to open the URI on platforms that need to open URIs like Android. Then add flag to force dw_file_browse() to return a URI or a path, maybe: DW_FILE_URI and DW_FILE_PATH.
2) Make the default behavior of dw_file_browse() return a path, which may not be openable on platforms like Android. Adding a flag to dw_file_browse() to force it to return URIs like DW_FILE_URI which would require using dw_file_open() or dw_uri_open() to open the result.
3) Make dw_file_browse() always return a path, which may not be openable on platforms like Android. Add a new function dw_uri_browse() which returns URIs on all plafroms and requires dw_uri_open() to open the result.
All options would require code changes to work on Android, some options would require changes on other platforms.
Does anyone have any thoughts on these changes?