Support for Android ContentProvider

[lianglge]

HD Model Viewer Version: 0.43 Test Device: Samsung Galaxy Tab 10.1 P7500

In our Android app, we provide our files through a custom ContentProvider. This means when such a file is opened, the path will be something like content://some_provider/model.fbx instead of file://some_path/model.fbx

It appears this kind of paths are not supported by HD Model Viewer. (Because it is not in the list of apps that respond to such Android Intents.)

Currently we have to switch to another model viewer. But it would be great if this issue can be fixed since HD Model Viewer is an otherwise perfect choice for us. Thanks.

[jdduke]

Thanks for the report. The code for importing models is all native (C++), which doesn't interact well with the usual Android approach of using an InputStream for pulling resources via content URI. Unfortunately, there doesn't appear to be a trustworthy and straightforward transformation from content to file URI.

I suppose I could do the dead simple thing of converting the InputStream to a byte array and handing that off via JNI... that'll probably have to do for now, though it's by no means optimal (particularly for large files). I'll see about adding this feature within the next release or two.

[jdduke]

I should mention, the main drawback in this approach is that resource dependency resolution (for textures and/or material files) becomes a lot trickier. Should referenced textures be resolved using a content URI relative to the model URI? Should they use the absolute file path? Any input you have on this would be appreciated (I haven't worked with ContentProviders in the past).

[lianglge]

Much appreciated.

Regarding the referenced resource files, I hope the following could help.

As stated in the Android doc at https://developer.android.com/guide/topics/manifest/provider-element.html, a content URI consists of scheme (content://), authority (provider_authority_name) and path. For example: content://provider_authority_name/files/models/building.obj Say the real path of the "building.obj" file is under /sdcard/some_random_path/files/models/building.obj, and there's a referenced texture file under /sdcard/some_random_path/files/models/textures/shady.png In this case, the texture file can be accessed through the following content URI: content://provider_authority_name/files/models/textures/shady.png

Although, I have to mention that we only deal with files in external storage. So I'm not sure if this would work for files in internal storage since there might be permissions involved (see above mentioned doc).

[jdduke]

Might I ask which model viewer properly handles texture dependencies by synthesizing a content URI? Also out of curiosity, is there a particular reason your app can't expose a file URI? Thanks.

[jdduke]

I mention that because I'm not in the business of supporting DRM or protected content in any fashion.

[lianglge]

As far as I can tell, "Hoops Viewer" is able to deal with such a content URI. https://play.google.com/store/apps/details?id=com.techsoft.hoopsviewer&hl=en But I have no idea if it handles referenced files properly. (will try as soon as I find the time)

Our reason, in this case, has nothing to do with protecting content. It's simply because of the following issue which seems to affect quite a few Android apps. http://stackoverflow.com/questions/3400072/pathpattern-to-match-file-extension-does-not-work-if-a-period-exists-elsewhere-i By converting the "problematic" file paths (removing/replacing dots), this ContentProvider solution helps us to cover more file types / apps.

[jdduke]

Perfect, thanks for the update. I think initially I'll try to support loading the raw model, and down the road I can work toward resolving dependencies appropriately (the latter likely requiring a bit more work given the way dependent resources are currently loaded).

[lianglge]

You are welcome.

Some updates: I checked if referenced files are handled properly by "Hoops Viewer". And the answer is no. But from my testing and another user's review, it looks like the app doesn't support resources at all (file:// or content://).