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

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

How to Document an Existing API Using Swagger

How to Document an Existing API Using Swagger

A few months ago, I jumped into an exciting project with my teammates at Shockoe. My expertise was needed for testing and debugging, which led me to begin working with the middleware API. In this particular case, the project presented new challenges, APIs that had already been set up by a client and the fact that this was an ongoing project, which meant that it was still changing and being updated regularly.

Adding features to the project required new resources and endpoints. Updating how error messages were handled required updating API responses and, after a certain point, enough changes had been made that the documentation had to be remade.

I came across two popular resources for documenting APIs: Swagger and RAML.

RAML takes a top-down approach to defining APIs, which means that you first define what your methods will be and then how they will work. By using a methodology that involves defining the system and providing the details later, this works well while developing an API since it goes alongside the developing mindset.

On the other hand, Swagger uses a bottom-up approach, defining each method one at a time. In my case, I decided to use Swagger because this methodology works better when documenting an already existing API. Swagger basically allows you to work through each API call and document as you go.

Swagger uses JSON objects to describe its API request and responses. For example, an API with a pets endpoint for a GET request could look like the example below, with a separate items object defined later in the document to increase readability.

{
  "/pets": {
    "get": {
      "description": "Returns all pets from the system that the user has access to",
      "produces": [
        "application/json"
      ],
      "responses": {
        "200": {
          "description": "A list of pets.",
          "schema": {
            "type": "array",
            "items": {
              "$ref": "#/definitions/pet"
            }
          }
        }
      }
    }
  }
}

Since I had already been using Postman to test each call, I had a quick way to go through each call, document the request and response, and move on to the next step.  Because the API only returned JSON the similarity between formatting for the response and the swagger response documentation led me to create a simple conversion program. This allowed me to easily input the response from an API call and output a properly formatted swagger documentation for it.

function convertToSwagger(item){
  var string = '';
  if(item === null){
    string += '{\n'+'"type": "string"\n'+'},';
  } else {
    switch(typeof item){
      case "string":
        string += '{\n'+'"type": "' + typeof item +'",';
        if(item.length > 150){
          item = item.substring(0,150);
        }
        if(item.includes('"')){
          string = string.slice(0,-1);
          string += '\n'+'},';
        } else {
          string += '\n';
          string += response ? '"example": "' : '"default": "'
          string += item + '"\n'+'},';
        }
        break;
      case "number":
        if(Number.isInteger(item)){
          string += '{\n'+'"type": "' + 'integer' +'",';
        } else {
          string += '{\n'+'"type": "' + 'number' +'",';
          string += '\n'+'"format":"float",';
        }
          string += '\n';
          string += response ? '"example": ' : '"default": '
          string += item + '\n'+'},';
        break;
      case "boolean":
        string += '{\n'+'"type": "' + 'boolean' +'"\n'+'},';
        break;
      case "object":
        if(Array.isArray(item)){
          string += '{\n'+'"type": "' + 'array' +'",';
          string += '\n'+'"items": ' + convertToSwagger(item[0]).slice(0,-2) + '\n'+'},';
        } else {
          string += '{\n'+'"type": "' + 'object' +'",';
          string += '\n'+'"properties": ' + '{\n' + createProperties(item) + '\n'+'}\n'+'},';
        }
        break;
      default:
        // do nothing
    }
  }
  return string+"\n";
}

At this point the process became simple, look up the API request, document the new path in Swagger (which can be made easier by copying an existing path and changing the different fields), make a request to get a sample response, put the response in the converter and copy it over to the swagger file. From here, I was able to quickly finish documenting the API and set up a process to easily keep it updated or document another finished API.

Documenting a project can seem daunting when you need to do it all at once, but it is still a very important part of the process. In the end, I found Swagger to be a great API document that was easy to use for my project needs. I was able to quickly pick it up and get started. Adding each method was simple to do after the first one and it helped give an overview of all the available methods while showing example requests and responses along the way. I hope this helps you when you find yourself documenting existing APIs, leave us a comment if you have any questions or insight on how to use Swagger.

Editor: Interested in learning how our developers debug applications? You can read more from our last week’s blog. For our blog on API Description Language for the Enterprise click here.

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

Testing in a mobile environment

Want to test on an iPad but don’t have one? Now there are online solutions that will allow you to test on all the devices that you don’t have.  Searching for the right testing software is very important, it needs to be able to support large a variety of devices, test the performance of the apps, be some what user friendly, and at the same time be reasonably priced. When I started my search I found lots of great free testing tools online, but they were all usually limited to one or two devices.

iPhoney is a great way to display your web app in an iPhone setting. You can open any website with Safari, rotate the phone, zoom in and out, test different browser redirection scripts. There is a similar simulator called the iPadPeek which helps you visualize everything on the popular tablet as well. Simulating on an android environment, however,  is a little trickier and involves downloading the Android SDK and setting up a virtual device.

If you do have some room in your budget for App testing then there are definitely a few different tools that are worth your attention.

DeviceAnywhere  is a big name in device testing. The company provides an easy to use web interface which gives the user access to a wide range of devices. The picture quality of the screen shots is very clear and also supports 2-way audio.  DeviceAnywhere can help save  money by letting the user “Release” a device before the reserved amount of time is up (14-16/hr).

Perfectomobile is great because it supports many of the of the same features as DeviceAnywhere but it can come at a lower cost with the right subscription.  The price difference means less handsets to test with but the software does come with the same testing tools.  Perfectomobile is faster than DeviceAnywhere and allows you to change devices with ease. Test automation in Perfectmobile is also structured nicely and very user friendly.

If you are just trying to do general device compatibility testing for your web application you may be more interested in something like Crossbrowsertesting. This application lets you test your next site on over 100 browsers and 25 different operating systems including mobile devices such as: iPhone, iPad, and Android.  While you may not get to test your web app on a wide range of models for mobile devices you still get interactive and side by side testing at prices starting at 29.95 a month.

Overall, mobile app testing and/or mobile website testing is by itself a big part of the process when you develop applications for mobile devices. At Shockoe we are always looking for new and different ways of putting our applications to the test. Selecting the right tools or the right devices for testing and development is essential so everybody is happy with the final result and making sure that it doesn’t have to come back to the developers again in the future.