The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
As aromero mentioned the developer payload field is limited in size. This is why the docs recommend not to use this key to send data or content.
ReplyDeleteWhat you do instead is save the content to a database somewhere (e.g. on the user's device or your own server), and then put the record's index in the developer payload field. When you receive it back via the PURCHASE_STATE_CHANGED broadcast intent, you can associate it with the data in your database.
Note that the developer payload is not sent by the Market when using any of the test android item ids. You have to be using real in app purchase items.
Also, according to this (I have not verified this yet), you will not be receiving the developerPayload in DEBUG MODE. You need to sign your application to RELEASE MODE to receive developerPayload.
Lastly, as you commented below, the returned JSONObject (in response to GetPurchaseInformation) already includes orderId, productId, purchaseTime and more. So "developer payload" should actually be used for anything but to identify the purchase... i.e. the answer is the opposite of what has been suggested below. What you can use "developer payload" is to add some information not in the JSONObject, like purchaser's additional details (e.g. GPS location if enabled, device brand & model, etc.).
The docs provide a real example:
ReplyDeleteA developer-specified string that can be specified when you make a
REQUEST_PURCHASE request. This field is returned in the JSON string
that contains transaction information for an order. You can use this
key to send supplemental information with an order. For example, you
can use this key to send index keys with an order, which is useful if
you are using a database to store purchase information. We recommend
that you do not use this key to send data or content.
You can use this field to identify the item the user is purchasing. When you issue a REQUEST_PURCHASE request you can put additional information using DEVELOPER_PAYLOAD. When you get the response from PURCHASE_STATE_CHANGED you'll get this info back in the developerPayload field, so you can identify the order.
This field is limited to 256 chars and it's unencrypted (you can verify the signature though), it's not meant to store actual content.