Latest posts

Localizing iOS apps with the standard tools is tedious, especially when you use Interface Builder files. To resolve that, I have created a new tool called AGi18n that makes it extremely easy. But let’s first start by analyzing the existing approaches for it together with their problems, to later introduce the library and all the goodies that you get from it.

Today, as part of the MVC in Objective-C series that I am writing, I am going to introduce the best practices that I have found so far when dealing with the Model role in your iOS app. But lets first give a quick introduction about the Model role:

The Model role in MVC is the one responsible for dealing with the state of the app. It encapsulates the code responsible for managing data, applying business rules, etc. This layer is usually the most decouple part of your app as it does not communicate directly with the controllers or views (only indirectly when the other layers request its information).

When implementing the Model in an iOS app you typically have to deal with different kind of problems:

MVC stands for ModelViewController, and it is a pattern that allows developers to differentiate code depending on three different roles. It is extremely popular due to its simplicity and it is implemented in different ways in almost every single technology out there -in different ways though. MVC helps you making your code lot more reusable, maintainable and easier to extend.

NOTE: I am receiving feedback from readers that this solution is not always working. Please, have in mind that this post is old and the content might be outdated.

Introduction

This week I have been delighted with a very attractive (and quite new) acceptance testing framework called “Calabash”. My experience in acceptance testing is limited, but Calabash quickly took my attention for a few reasons:

It uses Cucumber for defining tests. Cucumber is a “language” that is very close to real English, making tests very easy to write and read. Lot better than other alternatives, especially if you have to work with non-technical QA.

It is multiplatform. The same tests can be run both in iOS and Android! How cool is that? write tests once and run in multiple platforms.

It runs on real devices. Nothing else to say, tests should always be run in simulator and real devices. Even more, there are some interesting services in the Internet that allow you to run your Calabash app tests in hundreds of real devices, which can be very helpful for Android apps.

However, integrating the framework in a project with CocoaPods was not as straightforward as I thought. In this article, we are going to see why and how to fix it.

DRM (Digital Rights Management), is a set of access control techniques created to avoid illegitimate use of premium content. Any proper DRM solution should deny the ability to view, copy or share the protected content to any other hardware/software that the one that is has been designed for.

Audio/video DRM solutions use asymmetric encryption together with other obfuscation techniques to protect the content. They are mainly composed by two parts:

Server side: Delivers the streaming content (Live or On Demand media), with some encryption applied to it, only to allowed users. They usually require the users to register somehow (for example with a login) to recognise valid users from the rest.

Client side: Downloads the stream and decrypts it. Because the client side is executed in an unsecured environment (the client), prior to start decrypting they have to implement environment checks to ensure that security has not been compromised. Because of it, DRM clients requiere closed environments where the sourcecode is as protected as possible and where the private key can not be stolen.