5 Ways Shockoe Supercharged Mobile Workflow

5 Ways Shockoe Supercharged Mobile Workflow

Here at Shockoe, we work on a variety of applications for clients around the world, so it’s not uncommon for our developers to work on more than one project at a time. It’s pretty standard that everyone, at some point or another, is involved in multiple builds for multiple devices. Multiple builds for multiple devices can get unwieldy, so we have crafted a few solutions to help keep our development smooth and efficient.

We supercharged our mobile workflow by:

1. Building a system to distribute our apps

Shockoe created a system for the app teams, including clients and mobile testers, to download and install the app right on their phones. But this isn’t enough on its own. Developers love to automate things, so along with our distribution system, we have been using Jenkins to automate the process of building the apps and uploading them to the website.

2. Using Jenkins to automate builds

We updated our Jenkins continuous integration system to automatically put new builds on our app distribution system whenever developers push new code. We needed a continuous integration system that was easy to maintain, but powerful and flexible enough to handle all of the projects we work on at any given time.

3. Using Gulp.js to automate building apps

The next hurdle we faced was being able to build a wide array of different mobile platforms and frameworks without overwhelming our developers. Every platform has its own unique build process. At Shockoe, we’ve started using Gulp.js to handle building each project, understanding that each coding language has its own set of unique requirements. Gulp acts as a task runner to allow developers to define and run repeatable build steps using Node.js. Gulp allows us to reuse a lot of code between different platforms, and it makes tracking down any build errors much easier because we know exactly which step failed. Using Gulp for our builds also means that the build process is portable. Any of our developers are able to perform builds and upload the apps in the event that our Jenkins computer ever stops working.

4. Automating the building and deployment of our solutions onto remote servers

After the process of building and deploying apps was finished, we moved on to automating our web projects. This was more straightforward than building an app. Again, we leveraged Gulp to remotely connect to the server that hosts the site, pull any new code changes, and finally build the site again. Automating this process also cut down on the number of errors made when deploying a site, thus avoiding simple mistakes like using a test configuration in a production environment.

5. Running automated tests and reporting the results

Earlier, I mentioned that part of the build process includes running automated tests on our projects. Jenkins has many tools and plugins to simplify this process. There are plugins to automatically launch an Android emulator or an iOS simulator when the tests start, and to close it after all the tests have finished. We chose Appium as our automated testing framework. Appium tests can tap, swipe, and type inside apps automatically. Automating the testing process makes it easier to test our solutions more often and more consistently. Each project in the Jenkins dashboard has a section for the test results of every build. This means you can see which changes were made in a build and whether those changes affected any of the project’s tests. When Jenkins does find a test that fails, it immediately notifies the team using Slack. With multiple developers often working on the same project, this step is helpful in finding bugs as soon as they are introduced.

To Summarize

By automating the process of delivering our apps to our stakeholders, we are able to iterate much more quickly on our products and cut down on the number of errors. Building our own website that allows us to control who can download our apps means we don’t have to worry about uploading our apps to different file share sites, or attaching them to an email and sending it to everyone who needs it. The flexibility of Jenkins means that our build computers can continually be upgraded or replaced if necessary. If our build is ever too slow, we can just add more computing power to our Jenkins setup.

Using Jenkins with Gulp allowed us to really speed things up. Since Gulp is powered by Node, our developers found it easy to jump right in and start extending the build process with new tasks like deploying and updating websites automatically.

The final step was to use the wide array of plugins for Jenkins to run automated tests, report the results, and notify the development team when something goes wrong. All of these steps helped our developers concentrate on what is really important: delivering a high-quality product without worrying about constantly building and sending apps.

 

Note from Editor:

If you’re interested in learning more about what our developers are using as everyday tools, check out these Blogs:

How to Document an Existing API Using Swagger

Debugging Titanium Applications using Safari Web Inspector

Kotlin: Three Reasons To Start Using It Today

Underscore.js – Everything you didn’t know you needed

Underscore.js – Everything you didn’t know you needed

Underscore.js (_.js for short) is a phenomenal javascript library that most web and Titanium developers are likely familiar with at this point.  What you may not know is that _.js is bundled with Alloy, letting you use the awesome collection of commonly used functions with little effort on your part.  I’ve compiled a few of my favorites here:

_.each

Underscore’s each function is a great alternate to Javascript’s built in for function, with the key difference that it allows you to have a local scope to work in (as opposed to Javascript’s built in for, which inherits the parent scope).

_.memoize

Memoize does exactly what the name says!  It takes a function, and returns a version of it that will only calculate its return value once for a given set of inputs, and then cache this value and return it on subsequent calls.  It’s absolutely great for functions that always give the same result but can take a long time to compute (the Fibonacci sequence is an oft-used example).  For more information, Wikipedia has a great page on memoization.

Another great use would be for hash functions (e.g. the also-bundled-with-alloy sha1)

_.isWhatever

Underscore provides a awesome set of isSomething functions that can tell you all kinds of things about a given variable, ranging from its type to whether it is finite. Examples include isEmpty, isArguments, and isDate.

_.once, _.throttle, and other function modifiers

_.once and _.throttle are great for controlling frequency of execution of functions. Simply put, _.once makes it so a function can only be executed once, and _.throttle rate limits a function so that it can only be executed once every so often (e.g. at most once every 200 ms).  Both are extraordinarily useful in the context of Titanium for dealing with issues associated with events getting created too quickly to be handled in a sensical fashion, such as a user tapping a button too quickly or scrolling too fast. Other awesome function processing functions include _.after (provided function is executed after being called a certain number of times), and _.debounce (function is only executed after it hasn’t been called for some period of time).

And more!

Underscore.js contains roughly 80 different commonly used functions for different purposes, too many for me to possibly go over here.  Take a look at their docs, and feel free to leave comments about your favorites below!