So after a long hiatus from writing, I’ve decided to try and be a bit more disciplined and write more frequently. This is the first in a series around how we have introduced build time tracking across our CI environments, and how we track it in our development tools.

We at Zendesk use Buddybuild, a CI & CD service for building iOS (and prior to their acquisition by Apple, Android) applications and libraries. Buddybuild is great as it hides a lot of the complexity when it comes to getting setup with CI, and at the time of our initial comparison was a lot faster than our previous CI provider.

The great convenience of hiding the complexity means doing anything out of the ordinary is less than obvious. Custom scripting is a prime example of this. Consider an example of what I wanted to do with two tasks we want to track:

Task 1: Measure the time it takes for a build to complete its execution

Task 2: Measure number of successful and failed builds

Unlike other CI platforms, Buddybuild doesn’t offer a YAML file that a developer/integrator can modify. Instead, one can implement a set of scripts that are executed at different stages of the build process.

Documentation on customising build steps is listed here, but here is a brief description:

buddybuild_postclone.sh — Script called once your repo has been cloned

buddybuild_prebuild.sh — Script called just before your build begins

buddybuild_postbuild.sh — Script called at the end of a successful build

buddybuild_finally.sh — Called at the end of the CI’s build loop regardless

Task 1: Measure time for a build to complete

To do this we need to capture the start and end time, then calculate the difference, and send it to our reporting service.

In `buddybuild_prebuild.sh`, we do the following:

#Get the start time of the build
BUILD_START_TIME=$(date +%s)

#Export the value via .bashrc to be able to read it in other scripts
echo "export BUILD_START_TIME=$BUILD_START_TIME" >> $HOME/.bashrc

In `buddybuild_finally.sh` we do the following:

#Get the end time of the build
BUILD_END_TIME=$(date +%s)

#Calculate the difference between start and end
let "BUILD_TIME = $BUILD_END_TIME - $BUILD_START_TIME"

#Post the result to our metrics service
./metric.sh -m "mobile.build.total.time" -v $BUILD_TIME

We do the time calculation in the final step in order to capture the time for failed and successful builds.

Task 2: Measure successful and failed builds

Buddybuild doesn’t have an environment variable, or state that yields the status of the build within these scripts.

In order to achieve this, we track it in an environment variable in buddybuild_postbuild.sh, which is only called on a successful build. To do this we include the following in our script:

echo “export BUILD_RESULT=\”SUCCESS\”” >> $HOME/.bashrc

Then in buddybuild_finally.sh , we check for the presence of the SUCCESS value or not, which implies the outcome of the build:

if [ “$BUILD_RESULT” -eq “SUCCESS” ]; then 
    ./metric.sh -m “mobile.build.success.count” -v 1
else 
    ./metric.sh -m “mobile.build.failure.count” -v 1
fi

This is all good stuff but how do the metrics actually get from Buddybuild to a reporting platform. In our case we are using Datadog to store and report on these metrics. We do this by leveraging the Datadog REST API.

metric.sh is a bash wrapper around this API but the core of the script can be seen below.

curl -X POST -H "Content-type: application/json" 
\-d "{ \"series\" : [{\"metric\":\"$metric\",          
\"points\":[[$currenttime, $value]],          
\"type\":\"$type\",          
\"tags\":$transformedtags}]}" \"https://api.datadoghq.com/api/v1/series?api_key=$apikey"

We chose bash not for ease of development, but because it doesn’t have any additional dependencies when it comes to running in a variety of CI environments.

Now you too can start to track the outcomes of your builds, and gain more insight into your historical builds, the time spent waiting on a build, and also measure changes as you make them to your overall build performance.

Hopefully someone finds this useful.

Collecting Build Metrics from Buddybuild was originally published in Zendesk Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Something that might go by a lot of people is that the support for generics includes all types, structs, primitive types, objects, everything. Why bring this up I hear you wonder, well my background is primarily from working in Java. Where I first learned to put generics to work in a meaningful way. The subtle gotcha that tripped me up, I will try and explain.

So what I wanted to build is a LIFO (Last In First Out) data structure which would be loosely based on a Stack but without the naming conventions of push and pop. Instead we have add, clear and list. I’m sure you can grasp what they will do.

So lets look at what that might look like in Swift land, keeping in mind my comments from my other post: Extending Objective-C objects usingSwift. We require a level of inter-operability until we hit full Swift so for now we will lean on objects from Foundation module.

Lets take a look at a first pass approach to the development of this stack.

class Stack<T>: NSObject {

 private var stack: [T]!

 private var stackCapacity: Int!

 private var storageKey: String!

 var hasItems: Bool { return stack.count > 0 }

 convenience init(storageKey: String!) {

   self.init(storageKey: storageKey, stackCapacity: 5)

 }

 init(storageKey: String!, stackCapacity: Int!) {

   super.init()

   self.storageKey = storageKey

   self.stackCapacity = stackCapacity

 }

 func items() -> [T] {

   return stack

 }

 func add(item: T!) {

   if stack.count == stackCapacity {
       stack.removeLast()

   }

   if !stack.contains(item) {

       stack.insert(item, atIndex: 0)

   }

 }

 func clear() {

   stack.removeAll()

 }

}

This appears from the outset to be a legit looking LIFO stack as described, it should just compile and work, WRONG!

So what the above error means is that T in this case doesn’t conform to a protocol that contains depends on in order to check if it is in fact contained within the Array.

Solution, enter Equatable , this is a protocol which defines how in this case objects are compared to each other. The following change fixes the above code.

class Stack<T: Equatable>: NSObject {

}

For completeness sake, let me explain what the above notation is saying, a I should point out what is the actual definition is that T can only be of things that conform to the Equatable protocol.

Why is this important is that, as I mentioned my background is primarily in Java so I naively thought that T could only ever be an object, in fact in Swift, T could be a primitive type, struct, enum or an Object.

For more information on Equatable in Swift NSHipster explains it better than I can: http://nshipster.com/swift-comparison-protocols/

I hope someone finds this useful

In Zendesk our API is provided by a Rails application and as such enums are represented as strings when they are serialised in JSON. Looking at our Developer Portal where you can find about all things Zendesk Rest API. We see this example, ticket fields

{
  "id":                    34,
  "url":                   "https://company.zendesk.com/api/v2/ticket_fields/34.json",
  "type":                  "subject",
  "title":                 "Subject",
  "raw_title":             "{{dc.my_title}}",
  "description":           "This is the subject field of a ticket",
  "raw_description":       "This is the subject field of a ticket",
  "position":              21,
  "active":                true,
  "required":              true,
  "collapsed_for_agents":  false,
  "regexp_for_validation": null,
  "title_in_portal":       "Subject",
  "raw_title_in_portal":   "{{dc.my_title_in_portal}}",
  "visible_in_portal":     true,
  "editable_in_portal":    true,
  "required_in_portal":    true,
  "tag":                   null,
  "created_at":            "2009-07-20T22:55:29Z",
  "updated_at":            "2011-05-05T10:38:52Z",
  "removable":             false
}

The issue with this is that in Objective-C enums are essential typedef’ed as NSUInteger. What does that really mean in simple terms is that enums are Unsigned Integers and only Unsigned integers, converting to and from a JSON representation isn’t clean or trivial.

A naive representation of this in Objective-C would look something like this code block below, using an NSString to represent type.

@interface ZDPTicketField : NSObject

@property (nonatomic, readonly) NSString *title;

@property (nonatomic, readonly) NSString *type;

@property (nonatomic, readonly) NSString *fieldDescription;

@property (nonatomic, readonly) NSNumber *position;

@property (nonatomic, readonly) NSString *tag;

@property (nonatomic, readonly) NSString *regExpForValidation;

@property (nonatomic, readonly) NSArray<ZDPSystemFieldOption *> *systemFieldOptions;

@property (nonatomic, readonly) NSArray<ZDPCustomFieldOption *> *customFieldOptions;

@property (nonatomic, readonly) BOOL active;

@property (nonatomic, readonly) BOOL required;

@end

As you can see comparing strings is not going to be fun and it never is, it’s an enum in the backend and we should be able to offer something similar in our API client.

Enter Swift!

We are always looking to use Swift on a regular basis where and when it makes sense, this is typically brand new code and as we refactor out Obj-C. Before I hear a lot of people talking about performance and the cost of enums, they make consuming model responses from an API easier then I am in favour of it with that trade off.

We created the following which works well in Swift classes however currently the converted Swift back into Objective-C doesn’t support the this notation. It means this connivence is reserved to our Swift classes but as we migrate more and more code to Swift I think it’s an acceptable compromise.

extension ZDPTicketField {
 
    enum TicketFieldType: String {

    case TicketForm = “ticket_form”,
             TicketProblem = “ticket_problem”,
             TicketIncidents = “ticket_incidents”,
             Tag = “tag”,
             Requester = “requester”,
             CC = “cc”,
             DueDate = “due_date”,
             Subject = “subject”,
             Description = “description”,
             Comment = “comment”,
             Status = “status”,
             Type = “tickettype”,
             BasicPriority = “basic_priority”,
             Priority = “priority”,
             Group = “group”,
             Assignee = “assignee”,
             Tagger = “tagger”,
             Checkbox = “checkbox”,
             Integer = “integer”,
             Regex = “regexp”,
             TextArea = “textarea”,
             Decimal = “decimal”,
             Text = “text”,
             Date = “date”,
             Brand = “brand”
    }
 
    var typeEnum: TicketFieldType! { 
        return TicketFieldType(rawValue: self.type!)
    }
 
}

What this results is that in Swift we can now access this extended computed property in our code and it will look and feel like an original part of our model definition.

var currentTicketField = getSelectedTicketField()

if let type = currentTicketField.typeEnum {

    switch type {

        case .Subject:

        //Do something...
        break

    }
}

I hope someone else finds it useful, I certainly had a little grin when it worked for me.

Android hasn’t helped the cause with it’s old permission model, what has been introduced in M aka Marshmallow is a vast improvement for users and developers. It offers developers the opportunity to explain to users why and what we are asking from them in terms of access to their device and or data.

But enough of a discussion on Android and it’s Permission model. Lets look at the problem at hand. We have added the FileProvider to our app in order to control access to files to and from our application.

The issue faced was when completing the action of taking a picture, the Camera/Gallery app would crash and the onActivityResult would be called.

java.lang.SecurityException: Permission Denial: opening provider android.support.v4.content.FileProvider from ProcessRecord{423c0ad0 13416:com.google.android.gallery3d/u0a10020} (pid=13416, uid=10020) that is not exported from uid 10079

An example of how to define the Support v4 FileProvider looks as follows:

<manifest>
    ...
    <application>
        ...
        <provider
            android:name="android.support.v4.content.FileProvider"
            android:authorities="com.mydomain.fileprovider"
            android:exported="false"
            android:grantUriPermissions="true">
            ...
        </provider>
        ...
    </application>
</manifest>

A naive approach would be to simply update the FileProvider definition and set the XML attribute export to true. Doing that would resulted in another SecurityException.

Ultimately after a lot of head scratching and soul searching I decided to try the following method that is provided within the Context object grantUriPermission and revokeUriPermission.

Solution, give possible apps permission to the URI in order to complete the action. The following code snippet shows using the PackageManager to lookup for Activities that will respond to the ACTION_IMAGE_CAPTURE

Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);

List<ResolveInfo> resolvedIntentActivities = context.getPackageManager().queryIntentActivities(intent, PackageManager.MATCH_DEFAULT_ONLY);

for (ResolveInfo resolvedIntentInfo : resolvedIntentActivities) {
    String packageName = resolvedIntentInfo.activityInfo.packageName;

    context.grantUriPermission(packageName, fileUri, Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_GRANT_READ_URI_PERMISSION);
}

Similarly one needs to revoke access once you are done relying on the URI.

context.revokeUriPermissionfileUri, Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_GRANT_READ_URI_PERMISSION);

I hope the following will help others who find themselves scratching their head and wondering what on earth is going on.

I welcome feedback on format and my communication of the issue, I am always keen to refine the craft of sharing knowledge.

As part of some day to day development work and trying to make my colleagues subsequent work easier I wanted to create a Utility class which would provide him with a simplified way of interacting from one app to another. In order todo this we landed on Intent juggling and relying onActivityResult

Here is the code, before the fix:

PackageManager manager = context.getPackageManager();

...
intent = manager.getLaunchIntentForPackage(APP_PACKAGE_NAME);
...

return intent;

The problem, onActivityResult was returning before the called Activity had even rendered. Something was up, so I started to hunt in the usual places. Make sure singleTop or singleTask wasn’t set on the calling Activity, no joy…

I eventually decided to dig into some source code and found that the method PackageManager#getLaunchIntentForPackage adds a flag to the Intent it returns, flag in question is: FLAG_ACTIVITY_NEW_TASK

For those of you who are interested can find the Source to the concrete implementation of PackageManager aka ApplicationPackageManager

Fix for the problem, clear the set flags, in our case we didn’t need any set

PackageManager manager = context.getPackageManager();
...
intent = manager.getLaunchIntentForPackage(APP_PACKAGE_NAME);

if (intent != null) {
    intent.setFlags(0);
}

...
return intent;

I am writing this up so that it hopefully helps someone else and saves some time and also for my own sanity if ever happens again, I can recall my notes.

This being my first blog post I am going to try and make the post small and concise and hopefully as I practise my writing I will be able to refine the process further and further and hopefully deliver content people will want to read.

This first blog post is hoping to save people the time and effort it took me to figure this stuff out, while straight forward once you know how, there is a distinct disconnect in the documentation I was using.

Google Analytics SDK Documentation (v3, because thats the version I’m currently working with)

Google Analytics offers a wealth of information and power in terms of tracking user behaviour while using your app. Recently I was asked to see if we could enhance the data collected to extract what screen orientation user actions were taking place.

My first thought was that the EasyTracker in Google Analytics should have had this by default but it appears not.

The best approach to achieve this is to use a custom dimension. I have broken it down into three succinct steps:

Step 1: Configure you Analytics Account with the new Custom Dimension

Launch your Google Analytics Account and Access the Admin tab

Once selected you should see the following:

Here you can select the “Custom Definitions” section which will expanded a list of a available options; here select “Custom Dimensions”

Once selected it will present you with a table view of all the already defined custom dimensions if any.

As table views aren’t that exciting I decided you didn’t need a picture of it.

The next to step is to create a new custom dimension definition.

This can be done by click on the button titled “+ New Custom Dimension”

Next you will be presented with a couple of options when defining the custom dimension.

Here you have three options.

Name — An arbitray string, you wish to use to describe the data collection

Scope — Three available options are here Hit, Session, User (I’ll explain these in a moment)

Active — A boolean of if the data should be gathered

Hit — is a value that is tracked per event

Session — is a value that is tracked per user session

User — is a value that is tracker per user

More information can be found here: Scope value explained

As I mentioned at the start of the blog this was the piece of the puzzle I had been missing from the documentation of the SDK, either I missed it but I am pretty sure it makes no reference to needing to complete this step.

Without the definition, your code can send custom data to it’s heart’s content but Google Analytics will rightly just ignore it.

Last step is to click “Create”. This will then show up in the table of available of Custom Dimensions defined for the Application you wish to track.

The piece for you as the developer is to make note of the Index, this Integer is now valuable to you when adding the custom event to your tracking code.

Step 2: Add the appropriate code to include the new Custom Dimension

Hopefully this should be a pretty short step, the Tracker APIs that I am currently using are pretty straight forward to use and provides an Event Builder which makes the majority of the Event Map creation very straight forward.

Here is an example of some code that tracks events and send them to Google

Now to add in the Custom Dimension code

Thats all you have todo to track the now custom event, for brevity sake, assume that getScreenOrientation returns a string of the device’s current orientation. Additionally I know referencing the 1 in is very bad practise but for purpose of spelling out the relationship between the index presented in the admin panel and your code.

Step3: Test on a developer account

Great success you have achieved custom dimension tracking as part of your standard Google Analytics Event tracking. The difficulty here is that testing has a 24 hour lead time, once you have your event tracking code in place, test out your app using a test app profile.

Once you have data in place you can view this in the Google Analytics Reporting -> Behaviour -> Top Events

Here you can should see a list of events that have occurred in your app, next step is to include the custom dimension. Pressing the “Secondary Dimension” button should present a popover with all the available options.

Selecting Screen Orientation, will include the newly collected data as part of your report and should provide you with better insight to how people are using your app and in what orientation.

As a first blog post I hope someone else finds it somewhat useful.