*This is now scheduled to release 7/3/2013 evening.*
Hi All, we are happy to announce the iFormBuilder 5.2 server upgrade has been deployed to all environments. There is a major performance update when viewing data with many subforms (forms and records) in the different Views and Feeds. The client updates (iForm and iForm ES) are scheduled for release the week of July 1 2013. Please read the notes below for more details, and please feel free to reach out if you have any additional questions.
Client Side (iForm)
-Addressed the upgrade path issue between (184.108.40.206) or (220.127.116.11) to 18.104.22.168. Users will not have application crash from upgrade path with this build
- Completed record wasn't showing a cancel button in top left hand corner when being viewed client side
-Replaced default UDID given to all devices by Apple.. with an alternate UDID solution to comply with new App Store rules. The solution requires a check when a user is syncing to the server to see if the application version is 5.2 or greater. When a user syncs with the 5.2 client, we find all licenses for that username, matching the same device type and log them out. As we are creating a new UDID if we did not log out the old licenses you could hit max license error.
Tony has a 1 user account
Tony signed in on iPad which has the following UDID (123456) and client version 22.214.171.124
Tony upgrades to 5.2 client and goes to sync with the server.
I will be able to login successfully even though with my new App Version I will see the following UDID in the license page (abc123).. which will try to obtain a new license given the UDID is different.
Server Side (iFormBuilder)
- No longer returning 300 level HTTP responses for POST XML (only 400 and above will generate an error email)
- Improved query for DEEP Data Feed requests (enhance performance on queries which must grab parent and child rows).
- API Validation on ZipCode widget no longer requires the user to include the "-" separator in the request
- Record API 5.1 - A new parameter "BASE64" is going to be introduced to the POST record API, on the same level of parameter "EXT" (which stands for the extension of the file, e.g. "jpg"). This is a boolean, which only 0 or 1 or true or false will be accepted by the API when "BASE64" is on (1 or true), the data in the "VALUE" parameter will be base64 decode before processing. ("BASE64" is default as 0, therefore wont affect existing users who do not pass in this parameter)
- Fixed a bug in Form localization which introduces a "\" character when using apostrophes.