I am loading a local assetbundle, which is located under streaming assets folder in my Unity game. I am using a simple code to do this:
Assetbundle assetbundle = AssetBundle.LoadFromFile(Path.Combine(Application.streamingAssetsPath,"myresource"));
This code is working perfectly fine but according to Unity documentation and forums, it should not work at all in Android due to fact the streaming asset will be zipped under a path like this: jar:// url.
The following statement is from Unity documentation:
To read streaming Assets on platforms like Android and WebGL, where you cannot access streaming Asset files directly, use UnityWebRequest.
I have created an aab file and tested this code in ARMv7 and AMRv64 devices and it worked perfectly fine.
Unity's documentation is usually outdated so I really wonder if I should move this code to production or not.
Can someone shed a light on this ? Did they somehow fix this ?
It is working as intended and you followed the documentation. Good job, no problem here.
In older times the recommended method was the WWW class, but this class is deprecated now. The documentation on this bit changed for Unity 2018.4, thats quite recent.
Page on StreamingAssets does says that
To read streaming Assets on platforms like Android and WebGL
, where you cannot access streaming Asset files directly, use UnityWebRequest. For an example, see Application.streamingAssetsPath.
but here is the reply from Unity on the forums (and a related "Fixed" Unity Issue), so the issue with bundles was fixed even in 5.3.* and you should be able to use AssetBundle.LoadFromFile on Android. StreamingAssets documentations seems to be correct, it just doesn't mention that there is a special case for reading assets with AssetBundle.LoadFromFile. LoadFromFile documentation also doesn't mention it, but uses streamingAssetsPath as an example.
There is also an alternative to use BetterStreamingAssets that builds the map of files and their offsets in the apk, and then passes the correct offset as one of the AssetBundle.LoadFromFile arguments, although not sure how it handles the compression in that case.
Related
I'll try to make this simple :
If I create an AIR app from the Flash IDE, I can choose to embed folder in my package. Then I can load the files using 'app:/'+filename. Everything is ok.
I have to move to Flash Builder because I can't test workers in the IDE (thanks Adobe). My issue is that, if I test/debug from Flash Builder, it does a stream error when calling 'app:/'+filename. If I launch the test in the IDE from FB, it works but the Workers don't. I should mention, the reason I'm using this method is that I have so many graphical assets, it's just easier to maintain/update this way instead of using [Embed.. ] for all my items, and it just works in the IDE...
I've added my folder to my sources locations in Flash Builder, still it seems I cannot use the 'app:/' thing.
How can I make this work so I don't change my code and still use 'app:/'? FB is such a confusing program...
edit : I tested again the workers in the IDE build launched by FB (the test in flash IDE icon), I can trace its state with :
worker.start();
worker.addEventListener(Event.WORKER_STATE, this._handleWorkerState);
private function _handleWorkerState(__e:Event):void{
trace(__e.currentTarget.state);
}
traces 'new' then 'running'. But for some reason, it doesn't send or receive any data from any message channel, which, again, works in FB4.7 when i run a debug but doesn't find my files....
Error #2044: Unhandled ioError:. text=Error #2032: Stream Error. URL: app:/foldername..
So basically, I'm looking for a solution to at least one of my problems :)
EDIT :
So ok. Here it is, one issue was due to the wrong debugger version installed (for the workers part). So I can now work and compile in the IDE again. I haven't found an answer to why 'app:/' doesn't work from FB4.7. So that would be the remaining question.
One option since you have Flash IDE is to create a library with all of your images. Drop all your images into the library in Flash and export them for actionscript. Then publish and create a a SWC. Then you can use the swc, which is kind of like a zip file for display objects, in flashbuilder and access them like:
var mc:MovieClip = new imageExportedForAS3_1()
Create a top level folder in your flex project called for example images, copy all of your images into that folder, then every time you need to load an image, just use the source attribute and use the absoulte rute, for example.
<mx:Image source="#Embed(source='../images/pic.png')"
I have never used the app:/ sentence before! Good luck!
I have a number of different Android applications building in Eclipse / ADT that share common code and assets. Sharing the common source code folder is easy as I can use Link Source in the Build Path set-up. This works great.
These programs also share the content that's in the assets folder. At the moment I'm duplicating, which is a bit inelegant and error-prone.
Is it trivially possible to tell Eclipse / ADT to use a common assets folder in a similar way that it is trivial to have it share a source code folder? I can't find any similar option or tool.
Notes:
I am not looking for a 'library' solution (indeed that seems
fraught with issues anyway, and I did try that previously and hit
issues like this one). In any case that's less relevant for
assets, and I'm looking for simplicity.
It doesn't matter if the shared assets folder has to contain a
superset of the needs of all the applications.
Assets. Not "resources".
I'm using ADT version 22.2
For many complex reasons, symbolically linking the folders will not suffice. (You do not want to know the details. You'd never believe them anyway.)
Sharing the common source code folder is easy as I can use Link Source in the Build Path set-up
I would not count on that working over the long haul.
At the moment I'm duplicating, which is a bit inelegant and error-prone.
Alas, given your other restrictions, I suspect that it is your only option, though you could take some steps to reduce the error-prone aspect (e.g., script that synchronized the contents).
Long-term, Gradle for Android will be The One True Answer for all builds, Eclipse included. At that point, I expect your "Link Source" will break. However, at that time, you should be able to cut over to Gradle for your builds.
Gradle allows developers to override the default locations of all sorts of directories, including the assets directory. You should be able to set up a build.gradle file that points to some common location for the assets directory, overriding the default location that looks inside the project itself.
It's unclear why you think that symlinks/hardlinks will not work for you as a stopgap measure. You might wish to consider asking a separate StackOverflow question, explaining what you have tried and what problems you encountered with that technique, whether you think we will believe them or not.
Bear in mind that while Eclipse handles the javac step for the Android build, everything else is largely handled by external tools (e.g., aapt). Those will be oblivious to things that exist solely in Eclipse-land. Conversely, that's why symlinks/hardlinks should work, as from the standpoint of those tools, such items should be treated the same as actual files in the filesystem. Hence, the reason why "Link Source" works is not because Android really supports it, but that Android presently delegates that one piece of the build to Eclipse itself. Once Google adds Gradle for Android support for Eclipse (which I hope will be before the end of 2014), then I would expect Eclipse to be completely cut out of the build process, and I expect "Link Source" to fail at that point.
I have one simple question conserning PhoneJS http://phonejs.devexpress.com/Documentation
and it's demos - how to launch and preview them on Android devise?
I've loaded a package and tried to run demos through Eclipse, using
webView.loadUrl("file:///android/html/index.html");
But only black screen is visible.
Thanks!
I also not found this PhoneJS information in documentation. I wrote to support and they told me PhoneJS application is like any PhoneGap based application can be packaged with PhoneGap and in http://build.phonegap.com site.
PhoneGap Build worked well, but it is little slow.
Do you see any errors or simple black screen?
Possible files, mentioned in the index.html file, are spelled in the different case from files on the disk, e.g. you have line
script type="text/javascript" src="data/db.js"
but on the disk there is "Data" (not "data") folder or "Db.js" (not "db.js") file.
It makes sense then application is uploaded on android device. You should ensure file names spelling.
Thanks, Serge
I have what I think is a fairly standard set-up of an existing web-app and would like advice on how best to adapt it for creating native versions via PhoneGap, in a way that we can keep developing the web-app and updating the phonegap generated versions from it with minimal rework.
I am a PhoneGap novice. I have searched around and tried various suggestions from StackOverflow etc with no luck, at least for my set-up.
The app is developed in GWT and consists of:
static resources in a shared folder for all of the app
/static/ with images, fonts, css.
The css define some font-families, referencing font files in /fonts
We refer to these static resources from html files and JavaScript code using absolute
paths.
static resources in a number of sub-folders (by GWT modules FYI)
Such as /LoginGadget, which will have GWT generated html, Javascript and sometimes subfolders with css and css-images.
GWT-RPCs
These are basically servlets where GWT takes care of serialization etc, and are accessed from our client code via XHRs under the covers
PhoneGap Build
I have started looking at creating a packaged app using PhoneGap and run into some problems where I need advice (Android example).
I have created /assets/www and put an index.html file in there and got it going.
I copied a version of our /static/ folder and our /LoginGadget folder under that "root" to see, and started it using
super.loadUrl("file:///android_asset/www/index.html");
which works.
In all our GWT generated html and Javascript files we have references to static resources using both absolute (e.g. "/static/....") and relative paths (e.g. from a LoginGadget Javascript, it might reference "css/some.css").
The relative paths work, as they reside "under" the folder where the html/js that references them lie.
Problem 1
However, references to absolute paths fail, despite PhoneGap starting by saying:
DroidGap: url=file:///android_asset/www/index.html baseUrl=file:///android_asset/www/
I expected a reference to "/static/images/file.png" from say index.html to be appended to the "baseUrl" to give file:///android_asset/www/static/images/file.png and hence work, as that is where the file lies.
I have had to modify index.html to use "static/image/file.png" for it to work.
But I'd have to recompile all our GWT app with a different configuration to modify all references to resources, and references from other files in sub-folders back to "/static/" won't work if modified to be just "static/".
How can I get absolute path references to "map" to /assets/www or similar?
(See below, I've looked at using the "base" tag....)
Problem 2
The GWT RPCs make the XHR request to the server the html/js was served from.
This works great as the app doesn't have the host server name hard-coded, and is in fact deployed on many different appengine appids/domains for testing etc.
Here the html/js files are "served" from file:/// hence I need to specify the server somehow.
I tried specifying with the "base" tag as documented, but then any reference I have in my html/js to a resource that doesn't specify "file://" seems to be made to the server specified in "base"..... hence I am not loading my local resources anymore and I basically have a web-app served from my server.
Want
What I'd like to do, is to be able to take the (pretty large) compiled and tested app from my wab-app's war (/static and all my /GWT-Module folders) untouched and copy them into /assets/www on my PhoneGap app and then add some boiler plate or start-up code and run as is.
Sounds like a big request, but I think if I could properly specify two things:
file path to use as "root" for absolute paths for resource requests that don't specify a http/https protocol (or other protocols.....which I already see are handled in DroidGap.java)
server (protocol, hostname, port) to use for any XHR requests
Then everything would come out in the wash!
I thought this would be a faily "standard" setup and already covered. Maybe it is and I'm just missing something.
Comments? suggestions?
Thanks in advance for any help.
Do you know about mgwt? http://www.m-gwt.com
Its a mobile framework for GWT built by one of the GWT Steering Committee members and it has phonegap integration for GWT apps as well.
There is a lot of docs in the projects and a very friendly user group.
Let me address your problems with a little more detail:
Problem1:
If you are using absolute path you will get that inconsistent behavior with phonegap, since the browser builds those urls locally and a reference to / means the root entry on the phone.
Using absolute URLs is a bad idea most of the times and I would recommend you to change that in your app (as you already did).
Problem2:
To use GWT RPC with phonegap read this blog post that I made to address the issues: http://blog.daniel-kurka.de/2012/04/gwt-rpc-with-phonegap-revisited.html
We solved these problems with two separate actions:
1) I wrote an ant target that as part of our build takes the web-app, and replaces the paths in all internal url references it finds, making them fit what's needed for them to work within the app. It still seems a major bug in phonegap to me. Maybe it's been fixed in newer versions?
2) We subclassed the RPC service class and modified it to have a static member that is the service endpoint. At the start-up of our phonegap app we modify the end-point to point to the desired server and presto.... all our GWT RPCs point to the right place.
I'm porting a rather large game engine written in C++ from Windows/Mac to Android. There is a lot of pre-existing code to read assets for games. In addition, there is quite a bit of code doing file system calls (stat'ing the files to make sure they exist, looking up all of the files and directories inside of a directory, etc.)
Right now, I'm focusing on just getting something up and running as quickly as possible, so I'd prefer not to have to rewrite a lot of this. What would be a good way of getting our game assets onto the device and accessing them with minimal changes to our existing standard C++ file system API usage?
I've got some basic support implemented already using the Asset Manager API, but that doesn't support the file system calls and I'm concerned that the 1 MB asset size limit is going to bite me at some point.
I've also looked at OBB, but the tools for creating an OBB file don't look like they are part of the current SDK/NDK. Otherwise, that looks like it would be perfect.
Is it a horrible idea to package up all of the files and just extract them on the SD Card the first time the app is run? Or is there some better way of dealing with this?
Update: I'm also not very concerned on being able to run on a broad range of devices, I am specifically looking at newish tablets, probably the 10.1" Samsung Galaxy tab.
We ran into a similar problem in developing our (data-file-heavy) app, and we ended up deciding to keep the APK tiny and simply download our data files on first run; they're going to have to be downloaded either way, but a small APK works much better on older devices without a lot of internal storage. Plus, you can potentially rig up a way for people to copy over the files directly from their computer if they have a limited data plan or a slow internet connection on their phone.
The "Downloader" sample app in apps-for-android (confusingly buried under "Samples") is almost a fully-implemented solution for this - you can pretty much just plug in the particulars of your data files and let it do the rest.
I wrote an app that relies on putting a good amount of native code into the Android filesystem. I did this by packaging the files into the APK as 'resources'. Instead of pushing them to the SD card, you can put then into the application's private namespace, I.E. /data/data/com.yourdomain.yourapp/nativeFolder.
For details on how to accomplish this, you can see my answer to this question.
It's fairly simple to package to just unpack them on the first run and never worry about them again. Also, since they're under the application's namespace, they should be deleted if/when someone were to decide to delete your app.
EDIT:
This method can be used to put anything into the app's private area; /data/data/com.yourdomain.yourapp/
However, as far as I know, your application has to be the one to create all the folders and sub-folders in this area. Luckily this is fairly easy to do. For example to have your app make a folder:
Process mkdir = Runtime.getRuntime().exec("mkdir " +localPath);
That works as it would in most linux shells. I walked through the assets folder I packaged into my APK, made the corresponding directories and copied all the native files to those directories.
What you might be more concerned with is the limited Android shell. There are many commands that you might want that aren't present. stat for example isn't available, so all of this may be moot if your native code can't make it's system calls.