Just a quick post to let you know that we’ve seen an issue with the Codeflow CORS proxy crashing out when trying to refresh the access token used to make authenticated calls to the Salesforce platform.
This crash itself isn’t always easy to spot, but can be seen in your terminal window with this kind of output.
Started connect web server on http://localhost:3030
Starting background Express server
Proxy server listening on port3000
thrownewError('"name" and "value" are required for setHeader().');
The issue here can be seen if running 0.12.X version of node, and is caused by a breaking change that was introduced. The latest versions of the request NPM package (that is used in Codeflow) fixes this issue, and can be installed into your setup with this one command.
npm install firstname.lastname@example.org
This line installs the 2.64 version of request and updates it’s dependencies and also updates your package.json file to represent this.
With this version of request in place the Salesforce token refreshing should now take place as expected. Of course if you see issues still then please message us on our support boards.
We are just in the process of updating our public seed and shell app repositories to include these dependency updates, they should be made public in the coming days following our test cycles.
A wave of excitement rippled through the MobileCaddy office when we heard that the next get-together of the Ionic UK user group will be on the 27th April. You can see the official Meetup page with all the info here. Continue reading…
The meetup took place at the excellent SkillsMatter, and they had everything that could have been asked for from a venue.
Sani Yusuf – Kick Off
An introduction to Ionic, it’s past, present and future was the starter dish for the evening. Sani took to the front in his famous Google Glass and took us through what life was like before tools like Ionic arrived on the scene. This was a time when to develop apps for mobiles meant using different languages for the different platforms. A time when these restrictions meant porting apps and having multiple, non-interchangeable teams of developers. He told us how the first wave of Hybrid apps promised to free us from these constraints and how these promises never really delivered… and then came Ionic.
Ionic, for those that don’t know, is a framework/SDK enabling folk to quickly build hybrid mobile apps using HTML5 technologies. Ionic uses the amazing Apache Cordova tools to take advantage of device features (GPS, camera, etc) as well as enabling the apps to be built into suitable formats for submission onto the different app stores (iTunes, Google Play, etc).
With Ionic came a toolset that removed some of the pains that developers were used to when initially building Cordova apps. A focus on performance meant that apps could now be built that had native like experiences… users shouldn’t/wouldn’t need to know if apps were native or hybrid. And this is what we really like about using Ionic ourselves at MobileCaddy. With every release (and keep in mind it’s still in Beta) the performance across all platforms just keeps getting better. Have I mentioned yet that we big fans of Ionic at MobileCaddy?
A quick demo was then rolled out to demonstrate just how quick it is to get started with Ionic… and if you want to see for yourself head over here. Sani joked at how you could have a $1bn app in minutes, in a way there are real serious opportunities available.
And just then not only did the beer and Pizza arrive, but we were also privileged to have Max Lynch (one of Ionic’s founders) join us on a Hangout.
Max Lynch – A Hangout
Max mainly focused on chatting about the new and upcoming features and tools that he and the Ionic folk were working on. Most of the focus was on the upcoming Ionic.IO. He discussed how that even though Ionic was currently enabling devs to build amazing hybrid apps that there were still pain-points and a lot more that could be done. Ionic.IO essentially delivers a platform to sit alongside the actual apps. This would deliver the following types of features;
Dynamic Versioning – Being able to update your app without having to go through the app submission rigmarole.
At MobileCaddy we have already started addressing some of these issues using the Salesforce platform, for example we can already do Dynamic Versioning and have taken the idea even further with a greater level of control.
Max also talked about the recent work they have done with the Crosswalk project, and how this is further pushing increased performance on Android devices. Essentially this allows you to bundle a specific version of webkit with your APK (the binary application file that is installed on people’s devices). This has the effect of meaning, as a developer, you have a known landscape when dealing with your HTML/JS/CSS, as well as of course meaning you can take advantage of newer builds and their feature sets sooner that might otherwise have been possible.
One question came up for Max about Angular 2. His reaction was positive, saying he was excited and that Ionic for Angular 2 would be on the cards. He also mentioned that Angular 2 is pushing towards a component based framework. I’ve not really looked into Angular 2 in any great detail, but this component based framework might play very nicely with Salesforce’s Lightning components. We heard about these from Doug and Skip from Salesforce at the last London Salesforce Developer’s meetup, so see our review for more information.
Ryan Hanna – Showcase
Co-organiser Ryan was next up, with the task of showing off a few apps built with Ionic, but before I get to that I should cover some of Ryan’s background. He’s a self taught developer (using Code Academy) and has only been in the game for three or so years. What’s amazing then is the fact that he’s the sole developer on his own app Sworkit, and the success that this has had… but more about that later.
(Secure) Offline, Data Synchronisation out the box
Salesforce authentication with no coding
A controlled application development/deployment lifecycyle, including OTA app updates.
We also demonstrated our Deploy to Salesforce feature for the first time.
This allows developers to deploy new versions of their mobile applications to the Salesforce platform from within the very app they are building. I have to be honest and say that I am very excited about this, and even more so about where we see this heading. Just another tool that we hope will ease enterprise mobile application development.
Richard Sands – Angular Fullstack Ionic
A late entry to the lineup, Richard give us a whirlwind tour of his new Angular Fullstack Ionic project. I think he can explain it better than I can, so this is lifted from the Readme;
The motivation behind Angular Fullstack Ionic is to streamline the development of projects that include an API, Angular webapp and Ionic app. It’s core design principles include sharing code and assets wherever possible, creating an efficient workflow and making it super easy to start off a project with handy components available out of the box (e.g. user signup/login).
It is based on the brilliant Yeoman angular-fullstack project
His enthusiasm and passion shone through, and despite the project be very young I can see that it shows potential.
The event was a great success, and I look forward to seeing more from this exciting community. And I’m sure that MobileCaddy will continue to be a part of it.
We’re excited to be presenting at the first meet-up of the West London Salesforce1 Users and Developers Group next Wednesday 21st January, which will take place in the Club Workspace at the Barley Mow Centre in Chiswick, London. The theme of this meet is Creating Mobile Solutions in a Flash, and we’re looking forward to hearing the group’s views on Enterprise Mobility, and listening to the hopes and fears Salesforce users have when it comes to ‘going mobile’ and the projects being undertaken by fellow developers, admins and users.
The meetup was hosted for the first time at the dotmailer offices near London Bridge, they provided excellent facilities which were matched only by the quality (and quantity) of pizza and beer supplied generously by the kind folk at MakePositive. So big thanks to both companies.
Doug and Skip (though mainly Doug, as Skip had laryngitis!) talked and demo’d us through the history of Lightning, the architecture of Lightning Component, some examples and a look into the future to see what’s on the roadmap. There was a lot of information passed on, and I have to be honest and say I don’t want to (or maybe can’t) regurgitate it all here… but I will cover what I seem to believe are the main nuggets that got me thinking.
Lightning and Aura
Before Lightning became available to developers Salesforce had been using it internally for sometime.
In fact SF1 is built using Lightning.
Lightning is also known as Aura. Salesforce’s marketeers didn’t want to call it Visualforce2
Aura is Salesforce open source UI framework, and can be found on github here.
Anyone out there can contribute to Aura through Pull Requests, and with that their work will end up inside Salesforce and powering Lightning.
Aura/Lightning is built by the same team that built Visualforce
Doug also covered (many times) the fact that trust and security were high priorities… obviously that was great to hear. This eye on security has meant a couple of things. 1) lightning components (on the platform) live on a lightning domain. 2) Communication to/from the client/server parts of Lightning components is locked down. This point was one of the very few “guidances” that is put on how components are used.
Here are a few other points on Lightning;
There will be a Component Exchange, a-la AppExchange
The client/server comms are called Action Services. There are options to box car calls as well as other behaviours (display-last-known-good, auto-refresh, etc).
Offline capabilities are limited to read at present. Create and Update are on the roadmap (no dates given).
BIG SAFE HARBOUR – Summer ’15 should see the ability to put Lightning Components inside Visualforce pages.
As well as Lightning Components being available for use in Visualforce pages, Lightning Out will also enable Lightning components to be used within other containers (websites, etc).
All-in, the session was excellent. Both guys showed passion for the platform and certainly for Lightning. If you get a chance to see them talk then I’d definitely recommend it.
Big thanks to Anup and Co. for another brilliant meetup.
Want More Salesforce?
If you have a thirst for more Salesforce goodness then come along to the Create Mobile Solutions in a Flashsession of the West London Salesforce1 Users and Developers group, where our good selves will be among the presenters.
When running up an app built with the Salesforce Mobile SDK there is an option to login to a custom domain. This is useful when testing against a sandbox or developer environment. The option, when running on an Android device, is accessible via the Change Server menu item which is available via the hardware menu button.
The issue comes though if your device doesn’t have a hardware button… what then?
If an acceptable option for you is to have this custom domain hard-coded (so that it cant be changed) then you can modify some code to use your defined custom domain as the default. It is as easy as replacing a single line in one file… so let’s have a look. In the below I have commented out one line and replaced it, and in my example I’m setting the default domain to https://test.salesforce.com (as in my case I’m testing against a sandbox environment).