Java SDK
Download the Java SDK (version 2.7)
Linux (.tar.gz files):
- Binaries and documentation (application/x-gzip, 3.3 MB)
- Source code and examples (application/x-gzip, 4.4 MB)
Windows (.zip files):
- Binaries and documentation (application/zip, 3.6 MB)
- Source code and examples (application/zip, 4.9 MB)
Veriplace Java SDK Release Notes
Veriplace Java SDK 2.7 Release Notes
What's New
- Location requests can now include a map service query for nearby points of interest and/or street intersections; see LocationOptions. If available, this information appears as new properties in the Location class.
- The LocationOptions class also encapsulates other request properties such as location mode and timeout, which formerly were implemented with overloaded methods. The new versions of the GetLocationAPI methods take a User as their first parameter and a LocationOptions reference (which may be null) as their last. The old versions still exist, but are deprecated.
- For efficiency, the client can now request JSON-encoded responses from the platform for all APIs; see ClientConfiguration.setPreferredEncoding(). The default is still XML encoding.
- The client now uses /api/1.1 URIs for all Veriplace REST APIs, which have slightly different parameters and output schema from the previous /api/1.0 URIs. The platform still supports the 1.0 versions, but the client no longer uses them.
- The obsolete SetLocationAPI, which was not supported in the platform, has been removed from the client and the examples.
- API methods and constants that are only for internal use have been changed from protected to package-private scope, and no longer appear in the API documentation.
Veriplace Java SDK 2.6 Release Notes
What's New
- GetLocationAPI now supports a true asynchronous request mechanism. The requestLocation() method returns an identifier which you can use to poll for the result; or you can pass a callback URI for Veriplace to push the result to your application.
- InvitationAPI now supports both of the asynchronous modes described above, rather than just the callback/push one.
- PermissionAPI has a new method, verifyCarrierLocatability(), which tests whether a mobile number belongs to a supported carrier.
- GetLocationAPI.getLocationById() now allows you to pass the application-specific access token, rather than a user-specific permission token, as long as the application does have permission to locate the user.
Fixes
- A bug in DefaultClientFactory caused the token store properties to be handled in a confusing way: if you set veriplace.client.token-store.path, but did not explicitly set veriplace.client.token-store.type to file (even though the latter is the default), the path property was being ignored. Now, the file path will always be respected unless you explicitly set the type to memory. Also, invalid values for the type property were being ignored, so typos like "memry" would be treated as equivalent to the default; these will now cause a ConfigurationException.
Veriplace Java SDK 2.5 Release Notes
What's New
- Better error reporting if user authorization fails due to a configuration error. Specifically, if the Veriplace client acquires an OAuth request token to be used in an authorization redirect, but then is unable to store the token in the local TokenStore (because, for instance, the web server does not have write permission for the token store directory), it will report an immediate TransportException rather than proceeding with the authorization redirect; otherwise, authorization would appear to succeed, but the application would get a confusing "request token not found" error after receiving the callback and would be unable to continue.
- The implementation of GetLocationAPI.getLocationAccessToken() has changed to use a new platform API for directly querying access tokens. This makes the access token query somewhat faster, as successful queries no longer require a separate OAuth token request. This also affects calls to VeriplaceState.requireGetLocationPermission() and requireLocation().
- The implementation of the response parsing classes (UserFactory, etc.) has changed considerably, for better code reuse and error handling. The change will not affect your code unless you referred to methods of those classes directly, which is not recommended.
Veriplace Java SDK 2.4 Release Notes
What's New
- The new PollingAPI provides a way to query Veriplace for batches of location updates from any users who are opted into your application.
- The new PollingManager class uses a background thread to call PollingAPI and push new locations to a handler object.
- The JSON.simple library is now required and included.
Veriplace Java SDK 2.3 Release Notes
What's New
- The new InvitationAPI supports inviting users to opt into your application via an SMS interface. The source code distribution includes an example of this.
- The "secure" property has been removed from the client configuration. This was only useful for WaveMarket internal testing; the client always uses SSL for direct communication with veriplace.com.
Veriplace Java SDK 2.2 Release Notes
What's New
Update (3/26/10): The Java 2.2 SDK source distribution now includes a new example application, "Here I Am", which is a simplified version of the demo that's accessible at demo.veriplace.com. Only the example code has been updated; the Veriplace client and OAuth client are the same as in the original 2.2 release.
The 2.2 release includes the following new features:
- The new method GetLocationAPI.getPermittedUsers() provides a list of all users that the application currently has permission to locate.
- The new method UserDiscoveryAPI.getUsersByParameters() provides the same user lookup capability as getUserByParameters(), but for a batch of multiple users.
Both of these new methods are illustrated in the web and Swing examples.
Fixes
- Previously, if you ran multiple instances of the same application and they made Veriplace requests at the same time, one of them could get an error due to a duplicate OAuth nonce value. Nonce values are now generated in a different way to avoid such collisions.
Veriplace Java SDK 2.1 Release Notes
What's New
The 2.1 release includes several client API changes for convenience.
- The client can be configured to return a user's last known location if available instead of throwing an exception, or to transform location results using a filter of your own design.
- All required and optional configuration parameters for the client are now encapsulated in a single class, ClientConfiguration.
- Configuration property names are now clearer and more consistent. The old property names are still supported.
- In the web tier classes, all request methods are now available through a single class, VeriplaceState.
Also, the examples now include a Swing GUI application to demonstrate the use of Veriplace APIs in the absence of a web front-end.
Veriplace Java SDK 2.0 Release Notes
What's New
The 2.0 release includes many changes and bug fixes, including:
- The web framework was rewritten for clarity, ease of use, and testability.
- Unit tests, using the JUnit 4 test framework, were added for all major functionality.
- Exceptions were introduced for common error conditions, in lieu of returning null or error values. OAuth error reporting was added to exceptions where appropriate.
- Callback generation was abstracted to an interface and a default implementation.
- Additional API support was provided for retrieving previously obtained location observations, for verifying and deleting known access tokens, and for certain non-interactive use cases.
Known Issues
- The Client API includes "set location" methods for submitting a new location for a user. These are intended for future use; the current version of the Veriplace server does not allow applications to change a user's location.
Distributions
As of the 2.0 release, the SDK source code and example code are now distributed in a separate source archive. The pre-built binaries and documentation are contained together in another archive. Both are available in .tar.gz or .zip format.
Building from source
The source archive contains an Ant build script; run "ant" to build the SDK distribution and run the unit tests. This will also build the examples, as Web Archive (.war) files which can be deployed to a servlet container.
Dependencies
The Veriplace SDK 2.0 was built using JDK 1.5 and Ant 1.7. It uses the Servlet API 2.4. The optional web framework includes additional support for the Servlet API and for Java Server Pages 2.0 using the Standard Tag Library 1.1. Additional support is provided for Spring MVC 2.x; the Veriplace Client was built with Spring 2.5.3, which is included in this distribution.
Integration is provided with Commons Logging 1.1. Alternate logging implementations, such as log4j, can be employed by using the appropriate Commons Logging configuration.
Veriplace Java SDK 1.2 Release Notes
What's New
OAuth Core 1.0 Revision A is now supported and employed by default.
You can force the Client to use the original OAuth Core 1.0 specification by setting the Revision parameter to Core1_0 in the Client constructor, or by setting the property "veriplace.rev_a=false" when using the ClientFactory. However, this is not recommended since Revision A provides additional security and is always supported by the Veriplace server.