I have a situation where I\'d like for some data to be passed from a mobile web site to a native Android app. A complication is that, in the normal case, the native Android app
Is there any other way to "leave a crumbtrail" or set a message that an app installed later can access from the Browser?
I think there is a simpler solution, a variation on the one employed by Barcode Scanner.
Step #1: Create a nice RESTful URL that contains the information you want. By RESTful I mean no ?
, no #
, none of that crap. It'll be a smidge simpler if this is on a distinct domain name, but this could just be something on your existing domain. For the purposes of this answer, I will assume that this URL looks like http://android.exampleapp.com/our/custom/data/goes/in/here/somewhere
.
Step #2: For all URLs that could be created following the pattern of Step #1 (anything in http://android.exampleapp.com
), your Web server should serve up a page saying "Hey! You don't have ExampleApp installed! If you click this link here, it will take you to the Android Market, where you can install ExampleApp! Then, try clicking the link that brought you to this page, and it will start up ExampleApp and give you...ummm...all this good data".
Step #3: Implement an activity in ExampleApp that has an
with the VIEW
action, the BROWSEABLE
category, and a element identifying your scheme and domain (and, if needed, the base path, if that will be the same for all of these links).
What the user sees, if they do not have ExampleApp installed and click the link, is your Web page from step #2, from which they can go install ExampleApp.
What the user sees, if they do have ExampleApp installed and click the link, is your activity, which can grab the URL via getIntent().getData()
and do something useful.
UPDATE
In a comment, you wrote:
mobile web page => store data => user installs app => user opens app => app retrieves data => app opens directly to the content retrieved
IMHO, you make too many assumptions about what the user is going to do. There may be days, weeks, or months of delay in between the arrows that I put in bold.
If you are going to distribute it yourself (e.g., off of your Web server), you always have the option of "burning" them a custom APK with the data inside of it, but then you have to deal with managing updates yourself.
Or, if you are going with an account-based system, have them create an account on your site before sending them to the Android Market. Store the data under that account, and when they connect back to that account from the app, you can match up the data with the app.