Feature/v2 compatibility #35
Conversation
… on v2 (still need to add the new v2 parameters to the SDK)
Fixed crash from trying to access x-request-id in v2 Added mice url parameter for v2
Changed jre example to use local copy of SDK (this is a bit hacky and should probably be done by a local Maven install instead, but it will do for now)
…le (untested due to server-side issue)
…saction Fixed some JSON formatting in the v2 examples (still not tested)
… to allow using the JRE example with an existing TSS
…th various combinations or null or empty existing TSS, PIN, and PUK
…an't test that Changed sdk test to use .com
| @@ -12,7 +12,11 @@ repositories { | |||
| } | |||
|
|
|||
| dependencies { | |||
| implementation 'com.fiskaly.sdk:fiskaly-sdk:1.2.200-jre' | |||
| //implementation 'com.fiskaly.sdk:fiskaly-sdk:1.2.200-jre' | |||
There was a problem hiding this comment.
Is this intentionally still in there? If so, maybe clarify the reasoning behind this with another comment.
There was a problem hiding this comment.
I'm not certain whether this is the best way to make it use the local version of the SDK (I get the impression that it's possible to use a local Maven repository to do it instead, without changing the dependencies in the gradle file, but I wasn't able to get that working due to inexperience with Maven in general), so I left this line commented out in case it was better to go back to it. If you think that the way I've done it is okay, I will remove the commented-out line.
| public class Main { | ||
| static String tssUUID = ""; |
There was a problem hiding this comment.
There is a UUID type in Java. Maybe consider using it.
There was a problem hiding this comment.
Thanks, I do actually use that type when creating the UUIDs, but then store the new UUID as a string — probably just because this is the way the Swift code does it, but maybe it also makes it easier to append to strings to make request URLs, without calling toString every time. But maybe toString is called implicitly when appending a UUID to a string; I will experiment with that.
There was a problem hiding this comment.
I just changed it to store the UUIDs as UUIDs.
| updateTransaction(); | ||
| finishTransaction(); | ||
| //don't disable a TSS we didn't create | ||
| if (existingTSS == null) { |
There was a problem hiding this comment.
Shouldn't this be existingTss != null or am I reading this wrong?
There was a problem hiding this comment.
existingTSS is a TSS UUID you set with the FISKALY_TSS_UUID_V2 environment variable. If you set that (e.g. because there is some problem creating new TSS so you need to use an existing one; I added this code while it was temporarily not possible to create new TSS), then this code uses that existing TSS instead of creating its own, so it doesn't need to disable it. If you don't set FISKALY_TSS_UUID_V2 then the code creates a TSS at the beginning and disables it at the end. The idea is that after the whole thing runs, there should be the same number of active TSS as before it started.
disableTSS disables the TSS tssUUID, which will either be the UUID from existingTSS, or the UUID of the new TSS that the code created for you because you didn't give it an existing one to use. So it will succeed whether existingTSS is null or not.
This has a few changes to the Java SDK to make it compatible with sign API v2, and also a whole lot of new code in the JRE example app, going through all the required steps in v1 and v2 to finish transactions (either creating a TSS or using an existing one if you set the relevant environment variables).