problem
Right now managing paths that relate to encapsulated assets and libs in a widget is a bit unwieldily. For example, let's say you have a widget structure that looks like this:
* com.domain.widget
** assets
*** android
**** images
***** someimage.png
*** iphone
**** images
***** someimage.png
***** someimage@2x.png
** controllers
*** widget.js
** lib
*** somemodule.js
** views
*** widget.xml
** widget.json
Here's some sample code from widget.js that would make use of those (ugly) encapsulated paths
var mod = require('com.domain.widget/somemodule');
var iv = Ti.UI.createImageView({
image: 'images/com.domain.widget/someimage.png',
});
So like I mentioned, doable but ugly. It would benefit developers to have a shorthand method for defining asset and lib paths.
Possible Solution
We could use something like *WPATH()* wrapped around all paths in a widget to take care of proper pathing.
var mod = require(WPATH('somemodule'));
var iv = Ti.UI.createImageView({
image: WPATH('images/someimage.png'),
});
Let's discuss this a bit more I think of WPATH as a constant but maybe a Alloy function call like getResource(...) and from the javascript argument somehow get the path. How does Android do it? I thought they grabbed resources using some kind of wrapper correct.
What would be the advantages of the Alloy.getResource() method? I ask mainly because that would have to be performed at runtime, where WPATH (or any other name) could be done at compile time, potentially improving performance. I don't understand your questions as it relates to Android. Android doesn't have to worry about encapsulation. The reason the widgets assets and libraries are structured as such is to ensure that they don't conflict with any other installed widgets in your project.