This week we pushed a considerable update to our seed and shell apps and I thought I’d give some thoughts as to what they included, why they were done and what the future holds for them too.
For those of you that don’t know, our shell apps are repositories that can be used as starting points when first beginning the process of building mobile apps for Salesforce. They contain some skeleton code as well as the dependencies needed to install all the tooling-goodness that MobileCaddy provides to make the app building process and breeze and a joy. Our seed apps are similar, but instead of a skeleton app they are a full blown demo apps, useful if you want to quickly see an application in action.
What changed?
Well, we’d known for a while that our current shell apps could be improved when it came to scaling out to full enterprise requirements and use cases… and then we came across this John Papa talk on his Angular Style Guide that he presented at ng-conf.
This led us to his style guide over on github and this gave us a clear way forward, and we definitely recommend you give it a read.
From this list of recommendations we have picked off some of the bigger changes and they’re now in the shell and seed apps that are used by our MobileCaddy CLI tool when you start off a new project. The changes included in the lastest release are;
- Single Responsibility
- IIFE
- Module Setter/Getter
- Bindable Members Up Top
- Accessible Members Up Top
- Function Declarations to Hide Implementation Details
- Manually Identify Dependencies
- Naming Guidelines
Why did you do this?
The style guide mentioned above does a really great job of explaining the benefits of each, but along with all of that comes the alignment to one of our favourite taglines here at MobileCaddy, an app is for life, not just for Christmas. A mobile app should be around for many, many years, delivering value to your business day-after-day; but it shouldn’t stagnate, it should evolve along with your business and it’s demands.
An app is for life, not just Christmas
The approach outlined in John Papa’s guide allows for good code management and maintainability. It means that a team of developers could be working on it at the same time. It means that a new developer, perhaps a contractor, should be able to take a look at the project and it’s structure and known where to look for relevant code and functionality relating to a change or bug. It means your application will be in the best state to facilitate updates and fixes.
And are you done?
Oh no… there are a host of other items in the guide that we want to take on too, and these should be rolling out to our public repos once tested over the coming weeks.