Release of v3.14 of the Red Hat Mobile Application Platform

We have just begun the deployment of the Red Hat Mobile Application Platform v3.14 to all our actively updated grids. This will be complete by Oct 21st.

Please pay particular attention to the notes below on Node.js 0.10.x, Cordova Light and CocoaPods 1.x.

Highlights

• Removal of Cordova Light Templates
• CocoaPods 1.0.1 support - Possible Action Required
• JavaScript Template App dependencies in NPM
• New Devices in Studio App Preview
• Retirement of docs.feedhenry.com
• Reminder - Node.js 0.10.x End of Life – Action Required

Removal of Cordova Light

As we pre-announced in the 3.13 release, we are beginning the removal of support for Cordova Light Apps in the Platform.

We created this App type several years ago to enable users to build Cordova Apps in our Build Farm using only the www folder from Cordova. This was to address several feature/usability gaps in Cordova at that time. However Cordova is now at a point in its maturity where our Light Apps are no longer required.

In order to minimise disruption to customers, we are doing this in phases. In 3.14 we have simply removed the Cordova Light templates from the New Project flow and replaced them all with functionally equivalent Full Cordova Apps. So you can no longer create new Cordova Light Apps from our templates.

However existing Cordova Light Apps will continue to work and build in the platform. We have no short-term plans to remove this support.

If you have existing Cordova Light Apps/Templates in external Git repos, which you use as the basis for new Apps, you can still import these into Projects using the Import App flow.

Whilst it is possible to migrate your Cordova Light Apps to Full Cordova manually, there is no need to do so. We recommend waiting until we release detailed documentation and tooling to make this easier. This will come in a later platform release (TBA).

The Config screen for Cordova Light Apps remains in the Studio to set parameters like Bundle ID. This screen is not used by Full Cordova Apps and you should use the standard config.xml file for this.

For all new developments, where you are not using your own existing Cordova Light template, you should now create a Full Cordova App.

All of our previous Cordova Light templates are now Full Cordova. This includes both our standard Forms App Template and WFM Demo App. If you’d like to see the structure of these updated templates, you can either create new projects in the Studio or you can browse the sources on GitHub.

CocoaPods 1.0.1 Support - Possible Action Required

We have upgraded to the latest stable version of CocoaPods for Native iOS Apps in our Build Farm. This is non-backwards-compatible with the previous CocoaPods v0.39 and you will need to migrate your podfile to the latest DSL format before you can build the app again.

All of our Native iOS template Apps have been migrated.

General migration instructions are available here but it may be as simple as changing the podfile from this format:

source 'https://github.com/CocoaPods/Specs.git'
 xcodeproj 'ProjectName.xcodeproj'
 platform :ios, '8.0'
 use_frameworks!
 pod 'FeedHenry', '4.0.0'

To this format:

source 'https://github.com/CocoaPods/Specs.git'
project 'ProjectName.xcodeproj'
platform :ios, '8.0'
use_frameworks!
target 'TargetName' do
pod 'FeedHenry', '4.1.1'
end

Replace 4.1.1 with the version of RHMAP iOS Swift SDK you are targeting, ProjectName.xcodeproj with the name of your project and TargetName with the name of  the target you want to build (see this Apple doc for distinction between project/target). If you do not specify a version number, the latest version in the CocoaPods central repository will be used.

JavaScript Template App dependencies in NPM

CommonJS is a module format for JavaScript, widely adopted by the Node.js community and popularized by npm, the package manager that’s bundled with Node. It has also become very popular to use it in client-side code using the Browserify tool. Given our usage of Node.js, it makes sense for us to move to npm on the client side too.

In this release we have moved from distributing our JS SDK via the core platform to using NPM. All of our JS-based template apps, including Forms and WFM, now use NPM and Browserify for JS SDK dependency handling.

Note, if you are just using our template Apps in the Studio, you probably don’t need to be concerned about any of this. You also don’t need to make any changes to your own existing Apps if you don’t wish to.

The Preview screen still works as before in the Studio. However this change means that the "update sdk button" in the Editor/Preview in the Studio is redundant, so it has been removed. You can now simply change the version of fh-js-sdk in package.json.

The way it works is as follows:

1. A new file www/js/init.js "requires" the fh-js-sdk
2. package.json is updated to include references to fh-js-sdk, Browserify, various Grunt plugins and the install script
3. "npm install" is run by the Build Farm, which invokes Grunt, which in turn runs Browserify
4. Browserify examines init.js and grabs any dependencies from NPM (such as fh-js-sdk) and bundles everything together into a file called main.js with any necessary supporting code for CommonJS
5. Your index.html file then loads the Browserified file via
6. You load your own JS files as before e.g.

You can optionally choose to make the same changes in your own Cordova or Web Apps. The steps are as follows:

1. Remove this call:

   var $fh = require('fh-js-sdk');

   from your JS code

2. Create www/js/init.js with the following contents:

   window.$fh = require('fh-js-sdk');

3. Add this to your Gruntfile (See full code from our template here):

   browserify: { 'www/main.js': ['www/js/init.js'] }

4.  Addto your index.html
5. You can optionally choose to use the same approach with your own JS code (but see note below) by modifying the Gruntfile to pull in all JS files e.g.

   'www/main.js': ['www/js/*.js']

6. Create a package.json with contents very similar to our template here.
7. Run npm install to generate main.js (Obviously you need Node/NPM/Grunt/Browserify installed locally)
8. Check all the new files into your repo

Note: You may be wondering why we run this process on init.js but not on your code by default. Browserifying only init.js ensures that live reload of the code in the Preview screen in the Studio will continue to work. If you do not require this feature, you can Browserify all of the JS.

New Devices in Studio App Preview

When using the Studio to preview Cordova Apps, you can now select from the following device profiles:

• iPhone 7
• iPhone 7 Plus
• Samsung Galaxy S7
• Samsung - Galaxy Note 4
• Samsung - Galaxy Note 5
• HTC - HTC 10
• Google - Nexus 6P
• Lenovo - Moto G Plus

Retirement of docs.feedhenry.com

Please use the Red Hat Customer Portal for all Red Hat Mobile Application Platform Docs for v3+ from now on. Users on the old FeedHenry 2 platform may continue to access those docs on docs.feedhenry.com/v2

• RHMAP Hosted Docs (3.x)
• RHMAP Docs (4.x)

Reminder - Node.js 0.10.x End of Life – Action Required

The Node.js Foundation Long-term Support (LTS) Working Group has stated that Node 0.10.x will end LTS on October 31st 2016. This means no more maintenance updates or security fixes. The current LTS is Node 4.x which is available in all of our actively updated Grids and will be in LTS until April 2018.

We strongly recommend that all customers begin deploying their Cloud Apps and MBaaS Services using Node 4.x from now on. Our experience has been that most apps need minimal changes to work with Node 4.x. You may need to update the versions of various module dependencies in package.json if you see errors in deployment. Modules which have native code dependencies appear to be the most likely to need updating to latest versions.

Whilst is is not mandatory, you should update the version of fh-mbaas-api to 5.13.1 or later in package.json. This gives you all of our latest server sdk bug-fixes and performance improvements.

Detailed Node.js API changes from 0.10 to 4.x are listed here.

Bug Fixes

• General: Times are inconsistent across the platform
• Forms: $fh.forms.getSubmissions API does not respect the search parameters
• Forms: Forms Submissions - Timestamps not consistent
• Forms: When applying Field Rules first option values fail validation
• Forms: Unable to apply rules to repeating fields
• Forms: Page and Field rule events are not being fired in the forms template app
• Forms: New Form screen preview not showing fields
• Forms: Edit form screen not displaying properly
• Data Browser: Import treats escaped commas as unescaped
• Data Browser: No way to delete collections or bulk delete data
• Data Browser: Users cannot view Data Browser when they should have access
• RHMAP App Store: Unable to download app if both iPhone and universal binary exists
• Build Farm: Exported iOS app fails to build in xcode
• Build Farm: iOS builds for Cordova Push Starter Template fails
• Build Farm: Native Android Builds - Time out
• Build Farm: pushstarter-cordova-app template fails to build for Android
• Build Farm: Splash screens do not work on Android builds
• SDKs: Unable to build Swift template apps

Minor Enhancements

• Studio: Mask sensitive environment variable values in Studio

Known Issues

• The App Store logs section under Mobile App Management in the Studio does not display any logs
• Lists on Project and Environment tabs are not sorted based on creation time.
• While deploying a Cloud App using the Studio, the progress bar sometimes hangs on "In progress" even after the App has been successfully deployed. You can ignore this.
• Performing certain actions in the Forms management section in the Studio results in errors due to unreachable MBaaSes. To work around this problem, you need to manually update the MBaaS access route for the Environment, or delete the Environment that references the unreachable MBaaS.
• Location capture and weather functionality in the Welcome template app is broken. This will be fixed in v3.15