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.
Related
I have a nuxt.js 3 generated javascript app, which is just some html, JS & other assets. My issue is that passing a file://<path>/index.html as a url to a web_view means that assets are broken since all addresses are origin-relative, e.g. /home/index.html, /_nuxt/entry.123456.css, not path-relative like home/index.html. (i think it would not work for subpages anyway, being path-relative)
How to overcome this?
is there any way to set the web_view to know where to get the static files from? there are no other requests from the web_view other than GETs for static assets & changes of location. I'm thinking something like request interception and rewriting the path or even the response. but that sounds just like a server, so:
I guess I'm gonna need a http server. Can you suggest me some simple up-to-date library that can serve files within an android app? Or can you point me to some API from android native toolbox to open a socket and serve static files via http response? Also, will such a server be accessible for other apps, for the whole android device on localhost? I would like to avert that; the only consumer of the files should be the web_view.
To avoid obvious counter-question - but why? It's that I intend to build a hybrid android app, that does simply open a web_view full-screen. I am aware of limitations of such solution and I'm fine with that. The android part is where I'm not well experienced. If this gets too over-complicated, I'm gonna just change the way how to produce the js app in the first place. but nuxt.js is my best option for now.
There are a couple of similar SO questions here about Cordova paths, and that they should always be relative due to the Android and iOS platforms. But my web app takes advantage of the browser's address bar by altering the current path for bookmarking purposes.
For example, you might be on the books page
mywebsite.com/books
and then click a book, leading you to
mywebsite.com/books/some-book
but the page itself never changed as it is an SPA. However if I used relative paths everywhere, then refreshing on mywebsite.com/books/some-book would now try and load assets relative to /some-book such as app.min.js, etc.
So this relative path system fails both on the browser and on a mobile built cordova app for Android and iOS.
For browser I can maintain the absolute paths I have like /js/app.min.js but I was hoping for some solution for Android/iOS/Cordova to use fixed paths as well. When I try /js/app.min.js it looks for files in files:///js/app.min.js which fails.
I have the power of manipulating the output of my builds quite easily, so if there were some magic path I could inject after my builds for iOS/Android or Cordova in general, such as file:// or whatever other magic paths there are, then I can solve this problem.
So does absolute pathing exist when building a web app into a mobile app with Cordova?
Try setting your paths with
<... src="assets/www/js/some.js">
Im thinking about trying to build a complex android app structure for a game maybe or just for practice reasons. Im used to code in objective-c, so im not that much experienced in android...
Anyway in work, we structure our app on ios like this:
-core framework: handling all core items, navigation, datahandling, mechanisms, etc. its the same in all of our project
-project framework: its files are mostly relying (including) the core framework's files, extending/modifying them, and doing the project depending stuff
-skin framework: this contains all the resources and images, if we want to do a re-skinned project, we only have to alter this
-main project: this includes everything just bashing together everything into an app. just starts the application, nothing more, anything else is done by the different frameworks
So I wanted to do a similar structure on android, but I'm not sure that I'm even able to do it... I see that there is android project and library project, I can include them into eachother... but my questions are:
1: can I build a similar structure as on ios?
2: can I make for example a "core" library what contains the basics of mechanisms, and another library containing only the resources, and a third one (or the third could be the actual runnable project), what can get resources from the resource library, can distribute jobs to the core library, etc...
3: can I organize the resources as I like (so not to throw every picture into the drawable folder root for example). For example to have somehow a characters folder (i know i cant do forlders in the res folder), and map files into map folder, etc... My only chance to name them "properly"? (map_sheet_type_1, map_sheet_type_2, character_sheet_type_1, etc) (if its going to be a game, it would use opengl, lots of sprite drawing, etc)
or I should do everything in a single project, dividing everything into a lot of packages, and use libraries only for jobs like "how to transcode "A" object into "B" object" ?
Thanks for the answers in advance
although I've never developed a game before, but an app is an app:
yes
as you mention you have executable projects and libraries projects, libraries can use other libraries and the only thing that goes to the device is whatever the executable project is building. It's just important to remark that compiled libraries *.jar files resources cannot be used in your executable project (that's why the ActionBar Sherlock have to be used as a library-project). In order to use a resource placed in a library project the project must be with its full source code open in the Eclipse so it can be compiled together. That is because inside an app, there's only one R (resources) object, and during build all the resources from all the projects are put together.
unfortunately no. As you mentioned yourself the resources cannot be in subfolders and even their file names are restricted as they can only use lower case letters, numbers and _ (underline). Just be clever and organised, write a spec or something.
packages IS the way to organize a single project in Java. If you gonna use multiple or single is your choice. Usually you can encapsulate in a library-project stuff that can easily be re-used in different projects, and the final project will contain everything that is specific to that one app/game. I'll give you an example on the place I work, we have a KicthenLibrary that is a library-project that we use in every single Android app we do. That library already contains an excellent multi-threaded bitmap download and cache classes, we used to have a MapFragment (now deprecated) before Google released their MapFragment, easy Http GET/POST methods, etc. As you can see, all of those are stuff that can easily be re-used in several different projects.
And just as a last trick, http://www.eclipse.org/egit/ IMHO is much easier to use GIT directly from inside Eclipse.
Here are a couple links that should help you get started on this.
http://kasperholtze.com/android/how-to-best-organize-your-android-source/
http://bartinger.at/organization-tips-for-android-projects/
Also, when I worked at a start-up, we made an app for both iOS and Android. We started creating native apps for each, and ended up having somewhat different structure. Global information/variables were handled different, and I couldn't structure my files quite like iOS did. That said, Android structure isn't terribly hard to figure out, and I made a fair amount of sub-folders in my assets folder (for libraries and js and such). And yes, you can definitely have several libraries.
As for having several projects in several in one app, see this link How to create a single application from multiple Android projects
I have a small Android application that uses different sets of files (a couple of images, a small SQLite DB and a couple of XML files) depending on the specific task at hand.
I know I can include my files into the main application APK using resources or assets but I would be happy to distribute them in a separated APK.
How can I create a data-only APK file?
How can I distribute it? In particular, do I have to do anything special for a data-only package (for example for associating it to the main application package in some way)?
(I'm intentioned to give the user a link to the data package and ask him to install it. No automatic installation required.)
How can I install my files into the internal or into the external storage area of my application? Is it possible at all to install files into the internal storage area created by the main application installer? Do I have to set any particular permission for this?
My approach to this would be to create a wrapper app that's nothing but a content-provider and serves up the files per request by your main app. This would allow you to supply different data packages for the user -- you could even have your main app select between those relatively easily.
It looks like that the commonly accepted way to have the same application with different contents (or styles, or configurations) is to use an Android Library Project for the common code (that is: the whole application, the "engine", the "app framework") and a standard Android Application Project for the contents (that is: an application that actually contains just data). A little bit confusing, just because the "library" here is actually the whole "app", but this seems to be the way to go.
More in detail:
Create an Android Library Application and put into it as much code as you can (all of the non-changing stuff). Please note that this library cannot be launched and cannot be distributed alone. It must be included in a hosting application.
Create a standard Android Application. Include your library into this project. Put in /res and in /asset all of your data (files, XML, etc.).
Compile everything and distribute.
Repeat this cycle every time you need a different version. Different because of data, style, configuration or anything else. Publish the resulting app with a new name.
For what regards me, I'm not completely satisfied by this approach.
A possible alternative is preprocessing the source code with Ruby, Python, Perl, GIT, bash, Ant, Maven, Rake or any other tool that is able to read a file from here, make some change here and there, and write the file there.
The general outline is something like this:
Make a "template" application. Leave your /res and /assset empty.
Run a custom-made script. The script reads a configuration file, copy the /res and /asset files from your repository into the project /res and /asset directories, changes some Java source file and creates/changes some XML file.
Compile and distribute (with a new name, of course).
Using GIT or other SCMs, you just make a new branch for every new version and compile it. Not very elegant (because it can strongly interfere with the normal use of the SCM) but...
There are a few example of these approaches on the web. I'm not completely satisfied by them, either.
Frankly, what the Android ecosystem should offer to solve this problem is some kind of "in-app package manager". Something like the Eclipse Update Manager. This would allow us to use the same application framework to handle different scenarios.
As an alternative, a solid, officially-supported, template-based code-generation mechanism would be nice. Something in the spirit of "Software Production Line": https://en.wikipedia.org/wiki/Software_production_line . Have a look at fw4spl, for example: http://code.google.com/p/fw4spl/ .
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.