Categories
Blog

tvOS – How to start

If like me you got excited about the new tvOS platform that Apple launched last week, here are some mandatory documents to read before you start coding away:

While you read this you can download Xcode 7.1 beta that includes the tvOS SDK.

After you finish reading the documents I recommend download the UIKit Catalog for tvOS sample app and have a look around on the code to see how things are done on tvOS.

Have fun!

Categories
Blog

Provision Profiles

Jared Sinclair has very good advice about provision profiles.

Categories
Blog News

Celebrating 10 Years of WordPress.com & Automattic

The WordPress.com Blog

This year marks the 10th birthday of WordPress.com and our parent company, Automattic. We are proud to have served this community of millions: from writers, photographers, artists, and small and large publishers, to business owners and entrepreneurs.

View original post 333 more words

Categories
Blog

Crash Tools Metrics

A nice site provided by HockeyApp to compare all the features of crash analytics tools.

http://www.crashprobe.com/ios/

Categories
Blog Uncategorized

First weeks at Automattic

Everyone that is recruited for Automattic (and I mean everyone), spends is first three weeks doing Happiness Rotation an alternative name for Support.

You could think this looks a waste of precious time for some of the people, but actually it’s a brilliant way to understand the business of the company, its clients and all the systems the company has.

Categories
Blog

Create an IPA using xCodeBuild

Xcode 5 brought a lot of improvements to the xCodeBuild command line tool. The most acclaimed by the developer community was that you finally can run your unit tests trough the command line using the Test build action.

Beside the Test action there was another big improvement: the new -exportArchive option. This new option allows to export archive to IPAs trough the command line and signed them with a designated profile. No more need of the xcrun PackageApplication.

Where before you did something like this:

xcrun -log -sdk iphoneos PackageApplication "$OUTPUTDIR/$APPNAME.app" -o "$OUTPUTDIR/$APPNAME.ipa" -sign "$DEVELOPER_NAME" -embed "$PROVISIONING_PROFILE"

You can now do this:

# First build the archive
xcodebuild archive -scheme $SCHEME_NAME -archivePath $ARCHIVE_NAME
# Then export it to an IPA
xcodebuild -exportArchive -archivePath $ARCHIVE_NAME.xcarchive -exportPath $ARCHIVE_NAME -exportFormat ipa -exportProvisioningProfile "$PROVISIONING_PROFILE" -exportSigningIdentity "$DEVELOPER_NAME"

The syntax is very similar to the PackageApplication command, you just need to create your archive first then export it to the IPA format. For Mac developers out there you can also export to the APP or PKG format.

Categories
Blog

A better UIAppDelegate

One of the most common ugly patterns I see while reviewing iOS code is the overcrowding of the UIAppDelegate with calls for all kinds of services. It all starts with the CoreData stack setup code, then someone adds code to setup an analytics service, short followed by a Push Notification service, InApp Purchase, Crash Reporter, etc…

Before you notice it the AppDelegate gets hundreds of lines of unrelated code, hard to maintain and gets to be a central point of all dependencies. One simple pattern can help us to break this cycle: Delegation.

For each of the services create a controller class that represents that functionality and then delegate the necessary calls from the UIApplicationDelegate to the controller. Let’s see an example with the CoreData code.

Start by creating a Master-Detail Application projet using the XCode and select the CoreData option. You will get an AppDelegate with the following properties and methods:

@property (readonly, strong, nonatomic) NSManagedObjectContext *managedObjectContext;

@property (readonly, strong, nonatomic) NSManagedObjectModel *managedObjectModel;

@property (readonly, strong, nonatomic) NSPersistentStoreCoordinator *persistentStoreCoordinator;

- (void)saveContext;

Why do we need these methods to be were? We can be easily be moved them to a singleton class called DataController and then refer to it instead implementing them in the AppDelegate. The interface of this object can look like this:

@interface SEDataController : NSObject

@property (readonly, strong, nonatomic) NSManagedObjectContext *managedObjectContext;
@property (readonly, strong, nonatomic) NSManagedObjectModel *managedObjectModel;
@property (readonly, strong, nonatomic) NSPersistentStoreCoordinator *persistentStoreCoordinator;

+ (SEDataController *)sharedInstance;
- (void)saveContext;
- (NSURL *)applicationDocumentsDirectory;

But this will only solve part of the issue, we still have calls being made on the AppDelegate to the singleton. Instead of flooding the AppDelegate with calls on each delegate method we can make our controllers implement UIApplicationDelegate protocol.

@interface SVEDataController : NSObject 

@property (readonly, strong, nonatomic) NSManagedObjectContext *managedObjectContext;
@property (readonly, strong, nonatomic) NSManagedObjectModel *managedObjectModel;
@property (readonly, strong, nonatomic) NSPersistentStoreCoordinator *persistentStoreCoordinator;

+ (SVEDataController *)sharedInstance;
- (void)saveContext;
- (NSURL *)applicationDocumentsDirectory;</pre>
and then on the .m file we implement the UIApplicationDelegate methods that make sense for this service:
<pre>#pragma mark - UIApplicationDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    [self managedObjectContext];
    return YES;
}

- (void)applicationWillTerminate:(UIApplication *)application
{
    [self saveContext];
}

For this methods to work you need to refactor your AppDelegate in a way that it forwards the calls to available services

- (NSArray *) services {
    static NSArray * _services;
    static dispatch_once_t _onceTokenServices;
    dispatch_once(&amp;_onceTokenServices, ^{
        _services = @[[SVEDataController sharedInstance]];
    });
    return _services;
}

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    id service;
    for(service in self.services){
        if ([service respondsToSelector:@selector(application:didFinishLaunchingWithOptions:)]){
            [service application:application didFinishLaunchingWithOptions:launchOptions];
        }
    }
}

As you can see we know have a service array that holds all of our services. These services can them respond to the UIApplicationDelegate selectors that are relevant for their execution.

You can now easily add more services, for more services  check the example project for SVEApplicationDelegate in github.

Categories
Blog

OCLint

While developing for iOS one of tools that I missed a lot from my C# projects  was FxCop. FxCop was a tool that analysed your assemblies and reports information about the assemblies, such as possible design, localization, performance, and security improvements.  On Xcode the only similar tools is the static analyser but it’s scope its limited to memory issues.

So it was with great excitment  that I found out about the OCLint project. As they say in their website

OCLint is a static code analysis tool for improving quality and reducing defects by inspecting C, C++ and Objective-C code and looking for potential problems

  • Possible bugs – empty if/else/try/catch/finally statements
  • Unused code – unused local variables and parameters
  • Complicated code – high cyclomatic complexity, NPath complexity and high NCSS
  • Redundant code – redundant if statement and useless parentheses
  • Code smells – long method and long parameter list
  • Bad practices – inverted logic and parameter reassignment

The documentation is excellent and it’s very simple to integrate it to Xcode or better yet to your Jenkins build server ( just missing a easy way to use it on Travis CI easily can someone provide a brew for it?).

My selected approach was using it with xctool but I need to tweak a bit the default values :(20 characters for a objective C variable name is a bit on the short side). Here is the script that I’m using at the moment for Xcode

For Jenkins I’m using this variation that allows to create PMD reports

Categories
Blog

Styling your app

One of the great challenges in iOS development is how to do the styling if your app in a easy maintainable way.
A lot of people start by doing it in their nib or storyboards directly, but they quickly find the limitations: no way to set custom fonts in your components, no way to refer any kind of global variables for things like background color or image, standard offsets etc…

My favourite approach at the moment is to set all these values by code on viewDidLoad methods using the help of category methods on UIFont, UIColor, UIImage, UIFont and others.

To help in more tricky styling I sometimes use the Paint Code App (Apple should copy some  of the ideas here to their IB editor)

Recently I found a very powerful alternative: Pixate. This tools is a iOS framework that allows you to style your interface using CSS files. It even allows download and applying of style files while the application is running! I’m seriously considering giving it a go it for my next project.

Categories
Blog

Fast Android Emulators

One of the big pains of Android development was the lack of a fast Android emulator to test apps. Until recently to do any kind of development you need to own a actual device and with the fragmentation on Android this could very expensive…

Say hello to GenyMotion a company that provide super fast emulators. They are based on Virtual Box  images done for Intel processors and they even support Google APIs.

Android programmers heaven!