I'm coding in Swift to add Smart Health Cards to Apple Wallet and Health using the guidelines here.
My code works fine with a single part JSON (i.e., shc:/5676290952432060346029243740... snipped for brevity). I am replacing the shc:/ prefix with https://redirect.health.apple.com/SMARTHealthCard/ to use with the Add to Apple Health and Wallet button as described in the link above.
The challenge is when the JSON is in multiple parts, i.e.,
shc:/1/3/567629095243206034602...
shc:/2/3/315057062436201156761...
shc:/3/3/634538347210283310097...
How can I assemble the QR code strings to add multiple vaccines to Apple Wallet and Health using the method described above using one Add to Apple Health and Wallet button? Things I've tried are using the shc:/ prefix on all QR codes in one long string, merging all JSON together and prefixing the entire string with https://redirect.health.apple.com/SMARTHealthCard/ and multiple variations of the above.
I found a solution and am posting here in case anyone else needs this information. What works for me is the following format:
https://redirect.health.apple.com/SMARTHealthCard/<QR string 1><QR string 2><QR string 3>
I removed all characters up to the trailing '/' in the QR codes. So all strings contain only numerics. I append all strings into 1 big string of numeric characters in the order of the ordinal number (i.e., 1/3, 2/3, 3/3). Then I pre-pend the redirect URL (https://redirect.health.apple.com/SMARTHealthCard/).
Related
I have been looking through the spice instant answer source code. Yes, I know it is in maintenance mode, but I am still curious.
The documentation makes it fairly clear that the primary spice to API gets its numerical parameters $1, $2, etc. from the handle function.
My question: should there be secondary API calls included with spice alt_to as, say, in the movie spice IA, where do the numerical parameters to that API call come from?
Note, for instance, the $1 in both the movie_image and cast_image secondary API calls in spice alt_to at the preceding link. I am asking which regex capture returns those instances of $1.
I believe I see how this works now. The flow of information is still a bit murky to me, but at least I see how all of the requisite information is there.
I'll take the cryptocurrency instant answer as an example. The alt_to element in the perl package file at that link has a key named cryptonator. The corresponding .js file constructs a matching endpoint:
var endpoint = "/js/spice/cryptonator/" + from + "/" + to;
Note the general shape of the "remainder" past /js/spice/cryptonator: from/to, where from and to will be two strings.
Back in the perl package the hash alt_to->{cryptonator} has a key from which receives, I think, this remainder from/to. The value corresponding to that key is a regex meant to split up that string into its two constituents:
from => '([^/]+)/([^/]*)'
Applied to from/to, that regex will return $1=from and $2=to. These, then, are the $1 and $2 that go into
to => 'https://api.cryptonator.com/api/full/$1-$2'
in alt_to.
In short:
The to field of alt_to->{blah} receives its numerical parameters by having the from regex operate on the remainder past /js/spice/blah/ of the name of the corresponding endpoint constructed in the relevant .js file.
The speech synthesizer knows that Galway is pronouced 'gol-way' but has no understanding of anglicized versions of other town names such as Portlaoise which it should pronounce 'port-leash' or Thurles 'fur-less'.
Is there a way to correct the default pronunciation in JSON?
While Google should be doing a better job about some of the places, as Leon indicated in the comment, sometimes there will be cases where the audio just doesn't match the text and you want to coerce it yourself.
In these cases, you can use the SSML <sub> tag in your response. It takes an alias parameter which contains how you would like it pronounced, while the body of the tag would contain the displayable text.
I haven't tested it (and I'm not sure I'd know how it should sound, even if I did), but SSML like the following might be what you're looking for:
<speak>
Welcome to <sub alias="furless">Thurles</sub>.
</speak>
If you're using the node.js library from Google, it should detect this as SSML and set parameters in the response accordingly. If you're writing the JSON yourself, you will need to send it in the ssml field instead of the textToSpeech field in your SimpleResponse.
I have this kind of request which seems to be GWT-RPC format :
R7~"61~com.foo.Service~"14~MethodA~D2~"3~F7e~"3~B0e~Ecom.foo.data.BeanType~I116~Lcom.foo.Parameter~I5~"1~b~Z0~"1~n~V~"1~o~Z1~"1~p~Z1~"1~q~V~'
But it is not in line with protocol described here:
https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit
What exactly is this protocol ? Is it really GWT-RPC or something else (deRPC?) ?
Looking into gwt-2.5.1 source code, I notice it seems that following packages could be generating this kind of format:
com.google.gwt.rpc.client
com.google.gwt.rpc.server
Is this deRPC ?
Based on a quick glance through the deRPC classes in the packages you listed, it does indeed appear to be deRPC. Note that deRPC has always been marked as experimental, and is now deprecated, and that either RPC or RequestFactory should be used instead.
Details that seem to confirm this:
com.google.gwt.rpc.client.impl.SimplePayloadSink#RPC_SEPARATOR_CHAR is a constant equal to the ~ character, which appears to be a separator between different tokens in the sample string you provided.
Both com.google.gwt.rpc.client.impl.SimplePayloadSink andcom.google.gwt.rpc.server.SimplePayloadDecoder` have many comments that appear to depict the same basic format that you are seeing in there:
// "4~abcd in endVisit(StringValueCommand x, Context ctx) closely matches several tokens in the sample string - a quote indicating a string, an int describing the length, a ~ separator, then the string itself (this doesnt match everything, I suspect because you removed details about the service and the name of the method):
"3~F7e
"3~B0e
"1~b
Booleans all follow Z1 or Z0, as in your sample string
I am trying to send a search input to a REST service. In some cases the form input is a long string of numbers (example: 1234567890000000000123456789). I am getting 500 error, and it looks like something is trying the convert the string to a number. The data type for the source database is a string.
Is there something that can be done in building the query string that will force the input to be interpreted as a string?
The service is an implementation of ArcGIS server.
More information on this issue per request.
To test, I have been using a client form provided with the service installation (see illustration below).
I have attempted to add single and double quotes, plus wildcard characters in the form entry. The form submission does not error, but no results are found. If I shorten the number("1234"), or add some alpha numeric characters ("1234A"), the form submission does not error.
The problem surfaced after a recent upgrade to 10.1. I have looked for information that would tie this to a known problem, but not found anything yet.
In terms of forcing the input to be interpreted as a string, you enclose the input in single quotes (e.g., '1234567890000000000123456789'). Though if you are querying a field of type string then you need to enclose all search strings in single quotes, and in that case none of your queries should be working. So it's a little hard to tell from the information you've provided what exactly you are doing and what might be going wrong. Can you provide more detail and/or code? Are you formatting a where clause that you are using in a Query object via one of Esri's client side API's (such as the JavaScript API)? In that case, for fields of data type string you definitely need to enclose the search text in single quotes. For example if the field you are querying were called 'FIELD', this is how you'd format the where clause:
FIELD = '1234'
or
FIELD Like '1234%'
for a wildcard search. If you are trying to enter query criteria directly into the Query form of a published ArcGIS Server service/layer, then there too you need to enclose the search in single quotes, as in the above examples.
According to an Esri help technician, this is known bug.
Im working on a script to hash a "fingerprint" for communicating with the secure Pay Direct Post API.
The issue I have is im trying to create a SHA-1 String that matches the sample code provided so that i can ensure things get posted accurately.
the example Sha-1 string appears encoded like
01a1edbb159aa01b99740508d79620251c2f871d
However my string when converted appears as
7871D5C9A366339DA848FC64CB32F6A9AD8FCADD
completely different...
my code for this is as follows..
<cfset variables.finger_print = "ABC0010|txnpassword|0|Test Reference|1.00|20110616221931">
<cfset variables.finger_print = hash(variables.finger_print,'SHA-1')>
<cfoutput>
#variables.finger_print#
</cfoutput>
Im using Coldfusion 8 to do this
it generates a 40 character hash, but i can see its generating completely different strings.
Hopefully someone out there has done this before and can point me in the right direction...
thanks in advance
** EDIT
The article for creating the Hash only contains the following information.
Example: Setting the fingerprint Fields joined with a | separator:
ABC0010|txnpassword|0|Test Reference|1.00|20110616221931
SHA1 the above string: 01a1edbb159aa01b99740508d79620251c2f871d
When generating the above example string using coldfusion hash it turns it into this
7871D5C9A366339DA848FC64CB32F6A9AD8FCADD
01a1edbb159aa01b99740508d79620251c2f871d
Sorry, but I do not see how the sample string could possibly produce that result given that php, CF and java all say otherwise. I suspect an error in the documentation. The one thing that stands out is the use of "txnpassword" instead of a sample value, like with the other fields. Perhaps they used a different value to produce the string and forgot to plug it into the actual example?
Update:
Example 5.2.1.12, on page 27, makes more sense. Ignoring case, the results from ColdFusion match exactly. I noticed the description also mentions something about a summarycode value, which is absent from the example in section 3.3.6. So that tends to support the theory of documentation error with the earlier example.
Code:
<cfset input = "ABC0010|mytxnpasswd|MyReference|1000|201105231545|1">
<cfoutput>#hash(input, "sha-1")#</cfoutput>
Result:
3F97240C9607E86F87C405AF340608828D331E10