All Posts By

TheAppExperts

Define your own constant types in Objective-C

By | iOS, Mobile | No Comments

We are faced with the requirement of using enums frequently within our code but Objective-C Enums only allow for integer values, which don’t always fulfil our requirement. For example, if we need to store the state of a process as a string to later be sent on to a service.

Possible states:

Waiting

Running

Paused

Finished

 

If this were completed using enums, we would have something like this:

typedef enum {

Waiting,

Running,

Paused,

Finished

} ProcessState;

 

Imagine now trying to set a string value for your process property based on the enum. The result would be something like the following:

switch(state){

case Waiting:

<object>.processState = @”Waiting”;

break;

case Running:

<object>.processState = @”Running”;

break;

}

 

A more elegant solution would be to set these values directly, it’s more readable and plays nicely with auto complete. For that you need to do the following:

In your .h file:

typedef NSString ProcessState;

FOUNDATION_EXPORT ProcessState *const Waiting;

FOUNDATION_EXPORT ProcessState *const Running;

FOUNDATION_EXPORT ProcessState *const Paused;

FOUNDATION_EXPORT ProcessState *const Finished;

 

In your .m file:

ProcessState *const Waiting = @”Waiting”;

ProcessState *const Running = @”Running”;

ProcessState *const Paused = @”Paused”;

ProcessState *const Finished = @”Finished”;

 

Now just set values with:

<object>.processstate = Waiting;

 

Prefixes can enhance it further to work even better with code completion. So we can change the constant declarations to have a prefix before:

typedef NSString MPProcessState;

FOUNDATION_EXPORT MPProcessState *const Waiting;

FOUNDATION_EXPORT MPProcessState *const Running;

FOUNDATION_EXPORT MPProcessState *const Paused;

FOUNDATION_EXPORT MPProcessState *const Finished;

MPProcessState *const Waiting = @”Waiting”;

MPProcessState *const Running = @”Running”;

MPProcessState *const Paused = @”Paused”;

MPProcessState *const Finished = @”Finished”;

 

Now when we’re setting our process state property, we’re presented with a nicely human readable solution. That’s it!

OAuth

By | Android, iOS, Mobile, Windows | No Comments

OAuth has become a big technology in recent years, our App Experts are here to give you all the information you need to get started.

What is OAuth?

It’s a secure way to authenticate access to and share resources with third parties.

Example

Say we have a profile on a website x.com and we want to upload pictures from Facebook onto our x.com profile. Without OAuth, the flow would look something like this:

  1. From x.com we click on the ‘Upload pictures from Facebook’ button.
  2. While still on x.com, we’d have to input our Facebook Username and Password.
  3. We’re now able to select which images we want to upload.

In this scenario, we’ve passed our Facebook credentials over to an unverified third party (x.com) for handling. There’s no telling what this third party is doing with these credentials; they could be stored, distributed, or used; without our knowledge.

Now consider the same flow with OAuth:

  1. From x.com we click on the ‘Upload pictures from Facebook’ button.
  2. We get a popup from a verified facebook.com source asking for our Username and Password.
  3. We get another popup from a verified facebook.com source asking us to allow/disallow x.com to use our pictures.
  4. If we allow the service, we can now select the images we want to upload.

Now, in this improved scenario, we’re achieving the same goal, the sharing of images between Facebook and a third party, but without passing any, Facebook-based, secure or sensitive information to x.com (Facebook Password and Username). Our credentials are securely handled by the appropriate services throughout.

OAuth roles

With OAuth we follow the concept of decentralization of control; we have defined a set of roles, each of which will be fulfilled by different, specialized, servers. This improves security while still keeping an eye on efficiency.

The roles are:

Client –The entity requesting access to the resource housed on the resource server. (X.com)

Authorization server – A server, normally owned/operated by the same entity as the resource server, that will process and potentially authorize access to the resource server.

Resource owner – The entity that owns the requested data. (Our Facebook Profile)

Resource server – The server hosting the requested data. (Facebook’s hosting servers)

The way it works

There are 4 flows/grant types in OAuth 2:

Now for the flows

Authorization Code Grant
  1. Client sends a request to Resource Owner providing Client Id (x), Redirect Url (http://www.x.com), and scope (Photos).
  2. Resource Owner responds with an Authorization Code.
  3. Client then passes Authorization Code to the Authorization Server and receives Access Token.
  4. Client can now access the protected resource on the Resource Server with the Access Token.
Implicit Grant
  1. Client sends an authorization request to Resource Owner and gets the Access Token.
  2. Client can then use Access Token to access protected resources on the Resource Server.

This is basically the same as Authorization Code Grant, but the Resource Owner and Authorization Server roles are combined to one entity.

You may be, like I was, asking what’s the point of the Authorization Code Grant method if Implicit Grant is easier and uses the same principle. Basically, most people use Implicit Grant, but the Authorization Code Grant method provides an extra level of security and decentralization. Also, if we’re dealing with a large resource provider that has a lot of Authentication Servers, the Resource Owner server can send different Authentication Server urls depending on the load of particular authentication servers.

Resource Owner Password Credentials Grant
  1. Resource Owner provides his own credentials to the Client in order for the Client to access the protected resource.
  2. Client provides credentials to Authorization Server and gets an Access Token in response.
  3. Client can then use that Access Token to access protected resources on the Resource Server.
Client Credentials Grant
  1. Client provides credentials to Authorization Server and gets an Access Token in response.
  2. Client can then use that Access Token to access protected resources on the Resource Server.

Basically that was OAuth 2.0 simplified. Hope you enjoyed the read.

3rd Party Technologies Every iOS Developer Should Use – Part 1- Appledoc

By | iOS, Mobile | 2 Comments

As part of a new series, we’re going to be looking at various tools that our App Experts have encountered during our mobile app experience that we feel no iOS developer should be without. To get the ball rolling, we have the solution to every developers most dreaded task, documentation. So what is this remarkable tool? The answer is Appledoc.

What is it?

Appledoc is a tool for building and maintaining documentation for your apps/libraries. After a quick setup, it compiles together your code-comments into a fully Apple-styled docset that can be kept up-to-date with a simple press of a button. For hassle free documentation on the fly, it’s the best option around for iOS developers.

Setup

Appledoc has a quick and easy installation process. First things first, you’ll need to download it:

You can download it manually from the developers’ github or just run this simple command in the terminal:

git clone git://github.com/tomaz/appledoc.git

Next up, install. To install appledoc use the following command:

sudo sh install-appledoc.sh

Add the build script to your project:

Once Appledoc is installed, you’ll need to add it into your project (note: you’ll need to repeat this step for every new project you start if you want to use Appledoc with it).

Select your project in the Project Navigator and select the plus icon at the bottom left of the view window to add a new target. We’re going to add our script as an ‘Aggregate’ target, which can be found in the ‘Other’ tab. For this new target, go to the ‘Build Phases’ tab and add a new ‘Run Script Build Phase’ by selecting the plus sign in the top left of the view window. Paste the following script into this new phase’s script window:

#appledoc Xcode script
 # Start constants
 company="YOURCOMPANYHERE";
 companyID="com.YOURCOMPANYHERE";
 companyURL="http://YOURCOMPANYHERE.com";
 target="iphoneos";
 outputPath="~/help";
 # End constants
 /usr/local/bin/appledoc \
 --project-name "${PROJECT_NAME}" \
 --project-company "${company}" \
 --company-id "${companyID}" \
 --docset-atom-filename "${company}.atom" \
 --docset-feed-url "${companyURL}/${company}/%DOCSETATOMFILENAME" \
 --docset-package-url "${companyURL}/${company}/%DOCSETPACKAGEFILENAME" \
 --docset-fallback-url "${companyURL}/${company}" \
 --output "${outputPath}" \
 --publish-docset \
 --docset-platform-family "${target}" \
 --logformat xcode \
 --keep-intermediate-files \
 --no-repeat-first-par \
 --no-warn-invalid-crossref \
 --exit-threshold 2 \
 "${PROJECT_DIR}"

Utilization

With all of that done, all that’s remaining is to build your new target and your Docset will be created.

Appledoc has it’s own commenting syntax to distinguish between code comments and documentation. So if we want to add a comment to our documentation, we’ll use either /// or /** as opposed to the usual // or /*.

When writing the documentation for class methods, we’re going to get prompted to provide documentation for any parameters and returned objects. We can do this using @param <parameterName> and @return. For example:

/**Provides functionality to do stuff with a string
@param input String value passed into our method to do stuff with
@return Returns the result of the stuff we did to our string */
-(NSString *)doStuffWithString:(NSString *)input

That’s the basics of Appledocs! There’s a lot more to the syntax — Part 1 of this series is meant to show developers enough to get started. If you’re looking for additional information,  you can find a comprehensive document here. What are some of the major challenges you’ve faced with documentation as an iOS mobile app developer? Give us a shout in the comments section below and be sure to check back for our next post in this series!

How I Learned to Stop Fighting and Love (well… like) the iPhone

By | Android, iOS, Mobile | No Comments

When I started as an iOS developer, it was largely by accident. I was looking for work as an Android developer and ended up in a situation that will be familiar to most mobile developers out there. I was called by a recruiter one day, and the conversation went like this:

 Recruiter: Hi, I have a mobile development role, I’ve read on your CV that you’re experienced with mobile development.

Me: Yessir, I have very strong skills in Android development.

Recruiter: Well I’ve sent you over a job spec, this sounds perfect for you.

Me: Ah, yeah, this job spec is for an iOS role, I’m an Android developer.

Recruiter: It’s fine, it’s just a boilerplate job spec, I assure you it’s 100% an Android role.

And so I ended up in my first iOS role…

Some background on me, up until this point I’d held a dislike for Apple so vocally and for so long that it had become ridiculous. It was a standing joke in my social circle, when forced to develop on Macs I’d wear gloves, when answering phone calls from iPhones, I’d cover my mouthpiece with a tissue to prevent contamination. I was the anti-Apple guy.iphone side

So I started working with the iOS SDK and, to my horror, it was great. Android at the time was a very messy SDK, everything you tried to do was an uphill struggle, but iOS was showing itself to be very straight-forward and simple. Because of Apple’s tight grip on what can be done with iOS and how, the SDK is a lot more comprehensive. Android’s buggy process of linking interface controls through an XML layer and then to the code was replaced with a single click-and-drag, the process of passing information to a new view through intent flags and intercepting it on the other end was replaced by the much easier process of creating a view with the information it needed and then just presenting it.

As I work more and more with iOS and its technologies I see more of what it is that makes it such a popular platform, elegant simplicity from interface to code. Back in my days of Android-fanaticism, I imagined iOS to be a claustrophobically restrictive platform, informed by horror stories of apples widget prohibition and restrictions on access to information on the device, but these restrictions have affected me probably twice in my career. In my day-to-day development it does everything I need in the simplest of ways.

How about you? Have you had your “come to Apple” moment, or have you always been keen to work with it? Love to hear from you in the comments section below.