Category

iOS

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.

Reconciling iOS, Android & Windows Mobile Apps

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

Android, iOS, and Windows mobile app developers alike are always on the lookout for the latest tools to simplify their workload, especially on multi-platform apps. Whether it’s a more organized way to produce code or creating a friendlier UI experience, our App Experts went on the hunt to look for possible solutions.

With the amount of training that developers go through to hone a native language, it’s dumbfounding to ask them to write code from another language. So, how can they transform their skills and transition seamlessly to another platform?

apple, android, windows, mobile

Our App Experts can code for any device.

The Popular Solution

Introducing PhoneGap, a developmental open source tool created by Nitobi. PhoneGap allows you to take your acquired knowledge from HTML, Javascript and CSS and use it to write for any mobile platform (iOS, Android, Windows). As a bonus, a developer can link your app to any of the main device features, such as a file system, camera, accelerometer or GPS. This allows your app to communicate effectively with the phone.

Alternative Solution

One of our App Experts also uses an open-source library called Scaloid, which enables Scala developers to create Android apps without migrating to Java. It uses many of Scala’s features including creating Domain Specific Languages (DSLs). The goal of Scaloid is to help reduce the cluster of codes as well as any type errors.

Scaloid Code

This example shows you how Scaloid reduces the amount of code that a developer needs to write.

Which Program Works Better?

Although developers can debate about which approach works better, most companies that want to create apps for all devices tend to lean towards PhoneGap. On the other hand, if a company is looking to break in to the Android market, then Scaloid may be the way to go.

What are your thoughts? Let us know below which open source tools you prefer to use and why.

Secure Sockets Layer Explained

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

With all of the chatter about various ways to protect and encrypt our data from prying eyes, The App Experts mobile development team thought it was time to share some insight into SSL or Secure Sockets Layer and how it works to keep data protected during a transfer.

At its most basic level, SSL is a standard security technology leveraged by millions of websites globally. It is used to create a secure link between a web browser and a server, and it is designed to keep the data transmitted between the two private.ssl_logo

Before a secure connection can be established, however, the server requires an SSL Certificate. The certificate in created by answering a series of questions that will play a factorising role in creating two encrypted keys: a private key, and a public key.

The public key, doesn’t need to be secret, and can then be placed into a request known as a CSR, or a Certificate Signing Request for short. The CSR also contains relevant information about the user.

There is an application process for the SSL Certificate that requires validation by the Certification Authority that handles the validation of your details. Once validated, the SSL Certificate is issued aligning with the given details, and the user is able to use SSL.

When used, the webserver matches the SSL Certificate with the users’ Private Key, after which the users’ web browser will establish a secured and encrypted link between itself and website.

All of this happens more or less behind the scenes, which makes for a user friendly process. But for those who seek a little bit of a visual cue that all is secure, there can be found a small icon of a padlock in the web browser to let the user known that they are in safe, SSL standard, hands. Nice, no?

So what’s actually in the certificate, you may well ask? Usually it contains a domain name, company name, country, and expiration date of the Certificate itself, while information about the Certification Authority that issued the certificate is also held within.

After all, we want to know who, what, when, and how when it comes to securing us, right?

When a web browser contacts a web server, it checks the certificate expiration date, whether the certificate was issued by a known Certification Authority and it trusts, and whether the same certificate is being used by the website being accessed. Should any of these checks fail, then the user is informed via a warning before continuing to the web site. The user can still continue if they wish to take that risk, but they will do so knowing that the credentials didn’t match.

In closing, that’s pretty much how SSL works. So how about your experience? Is SSL enough security for you? How do you protect your data? Let us know in the comments section below. Cheers!

Rumours swirl around Apple’s WWDC 2014

By | iOS, Mobile | No Comments

On Monday in San Francisco, Apple will be hosting its annual Worldwide Developer’s Conference.  While we’d love to make the trek to attend, we’ll have to make do with the streaming video of the WWDC.

While we expect that there will be some hardware announcements, we think that will be mostly on the iMac side of things, and probably not the time they’ll unveil a new iPhone or iPad model.  Instead, we think this will be when Apple will focus on the operating systems, and for us, we’re keen to see if there will be a reveal of iOS 8.

If you recall, it was last year at thejune_2014_posterframe WWDC that Apple announced iOS 7, which was a radical departure from the earlier iterations of the operating system.  We don’t anticipate such a game-changer as we had with iOS 7, but this might be when we see a decidedly new core function of the OS – fitness and wellness tracking.

9to5Mac.com has reported that Apple is  embracing this in a big way – with what is currently known as project code name Healthbook. 

Based on the images we’ve seen, the look and feel is similar to the current Passbook application.

Of course Apple may surprise us all with an announcement of a ‘phablet’ sized iPhone or a ‘pro’ version of a iPad – one can’t be certain with Apple, until the big keynote address. But based on past announcements, we expect this to lean heavily in the direction of the software, and not the hardware.

What do you think?  Will Apple put something out that we’ve never even considered?  Let us know in the comments section below.

Android vs iPhone: Is marketing influencing mobile loyalty?

By | Android, iOS, Mobile | No Comments

Android or Apple? This debate is something that developers have been talking about for years and countless articles have argued the merits of one over the other. Our App Experts were discussing the two competitors recently, and an intriguing question came up to try and explain Apple’s success:  Can a good marketing strategy beat a cheaper product that’s similar in nature?

Apple completely changed the mobile world when they released the first iPhone. It was a remarkable moment. Blackberry was already in existence by that time, but Apple showed us that smartphones could be more than just a tool for work. They managed to expand from a phone previously used only for calling and texting to the preeminent key to unlocking the web on the go. Someone had to follow.

Android – The New Kids On The Block

When Android first appeared on the market, it was seen as a cheap alternative to having an iPhone. But Android grew in popularity thanks to having an open source policy which allowed developers to code freely. Today, Android captures the spirit of individuality and nonconformity. If you compare Apple’s iOS 7 with Android 4.4 (Kit Kat), you can see huge differences among them, but many functionalities mirror one another. So one has to wonder, if there’s such a massive gap in pricing, surely iPhones must deliver additional features? The answer is a resounding no. 

In fact, Apple is copying some things from Android. The new Apple iOS recently added some features that were around in Android for a long time, like disabling WiFi from the notification screen or the new task manager which is just an Apple version of the existing one in Android. 

Additionally, iOS 7 becomes problematic when you are using an old iPhone, like iPhone 4. Battery life lasts for a shorter time and some features are not available because the hardware is not ready for them. Some would argue this is a way to force people to buy a new phone every two years in order to be able to use the latest features.

So what about Android? They’ve added some interesting features like the new interface with a design that’s very clean and simple. They’ve incorporated some components from the flat iOS design, but it shows the elements in a clear way — not to mention the colour palette is appropriate for a device that the user is going to be looking at for a long period of time.

The question Android fans are puzzled with is why anyone would pay £500 for an iPhone when they can have a Samsung or a Motorola phone which provides the exact same functions for less than half the price of an iPhone? Sure, Apple products are beautiful and easy to use. But at the end of the day, Android gives more freedom to the user with customization capabilities. We’re going to suggest one possible answer for many Apple aficionados is in a genius marketing strategy. 

Power of Brand Awareness

The cult-like following of Apple’s products may be attributed to the hype Apple is able to generate for its consumers year after year. Nobody is able to build buzz and speculation on upcoming products and announcements like Apple. Their brand following is built on creating the ultimate user experience — from the packaging, design, to the products themselves, Apple has capitalized on fans looking to have the latest in gadgets. Just one look at the massive queues outside an Apple store during a new product launch summarizes the incredible demand these products generate.

Having all of this in mind, one must wonder the powerful effects of successful marketing efforts.  If most people aren’t moved by features or specifications, some other channels must be contributing to user preferences. Sometimes, a name seals the deal and you can see that every day in the tube or on the bus.

In a city like London, iPhones and iPads are more widely seen than Android devices. Why? That answer will vary user to user, but there’s no denying Apple’s global brand awareness and more importantly, loyalty. After all, Apple’s cool and sleek designs outsells a product that works on par and is significantly cheaper, so there is a sense of established value with the Apple community. Wherever your personal preferences lay, the war between Apple and Android continues…

We want to know: which operating system do you prefer and why? Comment below and join the debate.

Native versus Cross-Platform Mobile Development

By | Android, iOS, Mobile | One Comment

Mobile app developers are always faced with one of the most challenging decisions when building an application: should I develop native or cross platform? While there are obvious pros and cons for using either approaches, a lot of the determining factors lay in the app’s purpose and audience. Let’s examine the difference between native development and cross-platform development and the tools/frameworks used for them.

Native Development:

Native is code compiled for the specific devices using fixed development languages.

  • For iOS,  Xcode is used as the development tool and Objective C as development language.
  • For Android, Eclipse or Android Studio is the development tool and Java as development language.

Cross-Platform Development:

In cross-platform development, code is used and compiled for multiple platforms. Usually, HTML/CSS and Javascript are used as development languages.  Some solutions will compile it into native code, but they are never truly native.

  • Example Solutions: RhoMobile, Appcelerator, PhoneGap, MoSync.

Why choose native?

  1.  Better Performance: When coding with the indented programming language, you have access to the full device APIs. Though cross-platform solutions offer native APIs to use, you will have to wait until it is released in order to use it. When it comes to animations and gestures, native code will be more polished and slicker than cross-platform solutions.
  2. Better Solutions: There are some cross-platform solutions that will compile code into the native language, but none of them compile it to completely native so it becomes very hard to do the custom changes for the specific platform for the developer.  In native, there are less serious limitations between creativity and platform capabilities, which provides a developer better solution.
  3. Better Support: Developers we work with often say that they like to work in native code because it is easier to get help. They can go online to forums like Stack Overflow and quickly get answers since there are so many more people writing native code.
  4. Better Deployments: Issues with deploying  cross-platform codes are more prevalent compared to the native deployments because of its built in packages. Additionally, applications tend to suffer from real performance pains during run time.

The Verdict

When using cross-platform solutions, fragmentation is a major concern developers must overcome. The notion of a one size fits all approach to building apps is not realistic.

What do you think?  Let us know in the comments section below.

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.

One Month Later: iOS 7.1

By | iOS, Mobile | No Comments

It has been just one month since Apple released the update to iOS 7, iOS 7.1, to the masses.  With 30 days to play with the final version, we have some observations to share about changes, features and performance.Man with iPhone

First announced as a beta back in November, many have suggested that the 7.1 update is what Apple should have released as version 7.0.  Debatable as that may be, we do understand that 7.1 came packed with many tweaks and enhancements that make the OS run more smoothly, but perhaps with some head scratching moments.

What we like

There is no denying that the operating system seems far sprightlier than it did in its first incarnation as iOS 7.  Apps seem to open more quickly and the responsiveness of them in action seems to also be enhanced.

Some of this is smoke and mirrors – there have been some changes to the actual animations that give the appearance of faster processing speeds.  But there have been some real performance upticks, and for those with older devices, like the iPhone 4/4s benefitting the most.  But even my iPhone 5 has been positively impacted.  It just feels faster – almost like a new device despite its 2012 vintage.

Those applications that have been updated with the new specs Apple has in place to mesh with the new iOS have also seen appreciable improvements.  Commonly installed apps like Twitter, Instagram and Facebook all seem to operate more smoothly.  Granted, with millions of apps out there, it would be a massive task to test them all, but the top ranked apps in the iTunes store all seem to have benefited.

What we don’t like

Those with “fat fingers” like your truly may not be so keen on the changes to the phone interface.  Especially as they have taken away the larger rectangular buttons to accept or end a call, and replaced them with much smaller circular ones.  While it might look more polished, it has done so at the expense of ease of use.  We’d ask for the option to go back to larger buttons if desired.

There was a great hope that battery life would be extended, but in random samplings of people at The App Experts, we’re not seeing an increase.  Indeed, some suggest that the battery life has been reduced.  This could be anomalous behavior and external factors could be at play, such as use patterns and recharge frequency.  But still, it doesn’t look like a positive to our iOS developers.

We’d also like to see a patch to address the distressing news that thieves can exploit a bug which disables the “find my phone” feature.  While this is a newly reported issue, it is one that we’d push to critical level if we were at Apple.  Hopefully that will be addressed in a 7.1.1 update directly.  We should also point out that this issue has a simple work around – put a passcode on your phone that can’t be guessed, and you should keep a thief from accessing your apps and settings.

Summing up

If you have yet to upgrade to iOS 7.1, it is worth doing as you will see some performance benefits.  Those with fat fingers, may wish to experience the phone app on a device that has the update, as you may grow daffy trying to hit the wee little circles.

What do you think?  Are you satisfied? What should come about in iOS 8? We’d enjoy getting your thoughts in the comment section.  Until next time, cheers!