Twitter

Categories

Recently I’ve found myself working with iOS 8 extensions, building Today widgets for Notification Centre using Swift. More specifically, I was attempting to build a widget in Swift for an app built in Objective-C. All was good until I went to run on device, when I received the following error message on the console:

dyld: Library not loaded: @rpath/libswift_stdlib_core.dylib

What I hadn’t noticed was a build setting titled ‘Embedded Content Contains Swift Code’ which by default is set to NO. Flipping this solved the problem, though it’s interesting to note that for projects built in Swift, you can add Swift extensions, leave this setting at NO and run your extensions just fine on device.

A recent feature request stipulated that the user’s location be visible in the various different maps that appear within the app. This is a common enough request and very easy to implement, but what does this mean for battery life of the device? The GPS radio on any iOS device is the most battery-intensive onboard radio and so having GPS running frequently is a bad idea. Time to profile the GPS radio usage!

Given that MKMapView is pretty mature having been around since iOS 3.0, I suspected that it would be intelligent enough to only use the GPS when necessary to determine the user’s location, such as first using wifi, the device’s IP address or some other less battery-intensive operation to determine if the user’s location is actually within the bounds of the displayed map before getting a more accurate reading to display on the map view.

It appears, however, that this is not the case. Rather surprisingly, as soon as showsUserLocation is set to YES until the time it is set to NO or the MKMapView is deallocated, the GPS will run hot, sucking up your juice. Not only will it do this when the user’s location is nowhere near the bounds of the map view, but also when the map view is not even visible to the user, so it turns out that it’s pretty important to manage this property carefully if you don’t want to drain your users’ batteries.

One thing that most consumer software of value does today is to integrate in some way with the major social networking incumbents, Facebook and Twitter. zeebox, naturally, is no different, and we’ve worked fairly closely with Facebook to get our Open Graph implementation right while also ensuring that we make best use of their platform.

There’s been a few bumps along the way. In past, Facebook have gently chided us for pre-filling the message field when posting to people’s walls from the app, which runs afoul of Facebook’s platform policy. Basically, any app that posts to your wall should have an empty field that allows you to express your thoughts about the subject matter you are posting.

But the truth is, there are loads of apps out there that flout this policy.

Draw Something:

Amazon Kindle:

And even some of zeebox’s competitors.. yap.tv:

In all these cases, Facebook’s platform policy is being violated because there is pre-filled content in the field rather than it being blank. In the case of yap.tv, you can’t even edit the text and, worse still, incomplete text is being displayed to the user.

It’s a little frustrating to see that FB’s platform policy isn’t quite enforced with an even hand, though I suppose the benefits of having a good relationship with Facebook outweigh this.

Facebook does many things very well, but most would agree that they are not particularly adept at managing their users’ privacy or security.

A recent example hit me the other day while browsing the Facebook iOS SDK integration docs. Facebook suggest that SDK developers store the Facebook access token that grants a client (e.g. an iPhone app) access to the Facebook platform in the iOS user defaults. This is not secure and could result in someone else masquerading as the user on Facebook or hijacked the user’s identity.

What is a Facebook access token?

A Facebook access token allows a 3rd party app to interact with Facebook on behalf of a particular user. Depending on what permissions the user granted to the app, the holder of the Facebook access token can do anything from posting to a friend’s wall, to accessing all the user’s personal information. It is important, therefore, that this access token is only ever accessible by the app in question.

What are iOS user defaults?

As any iOS developer knows, this is where an app can store a user’s preferences and any other information that might help the app to understand a user better across app sessions. These defaults might store things like a user’s ID, a preferred colour scheme, or the user’s first name, among other things.

User defaults, however, are not secure. Data stored in the defaults is stored in plain text, and while iOS apps cannot access the defaults of another app, anyone who had access to your phone, or a backup of your phone, could easily extract the Facebook access token and use it to masquerade as you. Not a good scenario.

For the past few months I’ve been working at zeebox on a new app for iPad that is genuinely one of the coolest products I’ve come across recently.. and so it has been an absolute pleasure having the opportunity to build it! I’ve been largely working on the social aspects of the app, e.g. Twitter integration, Facebook authentication, and the chat system, which is brilliant as this combines my two favourite spheres of software development: mobile and social.

Basically, zeebox acts as a glorified TV guide with social elements. You can see what your friends are watching ,chat with them about shows, invite them to watch with you and various other things. Despite a huge amount of work going into it, the app is still pretty nascent and it’s clear that it will improve dramatically over time, as long as people within the company continue to dream up more great ideas (this hasn’t been a problem thus far!).

There have been 4 of us working on the iPad app, but naturally there’s also a great team of engineers building the back-end services that tie the whole thing together. iPhone, and Android versions of the app are to follow. Check it out!

After a fair bit of wrangling, it’s finally come together. We’ve partnered with MTV and the Staying Alive Foundation to rebrand iCondom as the MTV iCondom, with a grand portion of proceeds going towards the Staying Alive Foundation, a sexual health charity. MTV will be broadcasting adverts across their worldwide network and ads have been produced in several different languages. See the English-language ad here.

We’re also looking for further partners to help update and maintain our ever-growing database of locations, so please get in touch if this is of interest!

Another raaza app in the wild. This one is US Flu Fighter, which is basically a mashup of various different CDC feeds with Facebook and Twitter in an iOS native app. It’s another one with a Ruby on Rails web services back end, which I’m finding increasingly handy for quickly building such back ends. I used the CorePlot framework to draw the graphs, which was a pleasure to use once i got familiar with it. US Flu Fighter has been submitted to the CDC’s Flu App Challenge so please go ahead and give it a vote.

This is year two for the Addicted to Ibiza Island Guide, a location-based listings app for the Ibiza party crowd. It includes event listings, a club guide, maps, DJ mixes and more.

The back end for this one was built in Java using largely the same components as last year, i.e. Struts 2, Spring, Hibernate, Freemarker and JAXB. If I had to do it again I would probably build it on Ruby on Rails, simply for the increased speed at which the solution could be delivered.

It’ll be available until December this year and then taken out of the store in anticipation of next years guide.

The latest app from raaza, UK Terror Alert, has just gone live in the iPhone App Store. This is another Ruby-on-Rails backed app that feeds data sourced from the UK Home Office and the MI5 Secret Service into native app format. This was the first time I’ve used Apple push notifications in an iOS app and it was a bit of a trying process getting an APN server up and running on top of RoR.

As for the basics, with UK Terror Alert you can:

see the latest alert levels for international and Ireland-related terrorism

There are a number of articles online that claim that neither Objective-C nor Java is better than the other, they’re just different. Well in terms of the mechanics and elegance of the language, I don’t agree– Java is the front-runner. Objective-C feels pretty archaic by comparison, and I suppose it truly is, being only a thin layer on top of standard ANSI C. Here are my top 10 gripes with Objective-C:

1. Lack of abstract/virtual classes and methods. Sometimes I want to ensure that a base class is never instantiated itself, other times I want to be sure that a subclass of a base class implements a particular method. In the case of the former, this is simply not possible– Objective-C has no concept of abstract classes. In the case of the latter, this is only achievable using protocols (i.e. similar to a Java interface) which seems slightly awkward- it requires considerably more code and bother than would be required of an abstract method in Java.

2. Lack of namespace support: It seems a bit silly that object types are prefaced with a Hungarian notation-like two characters indicating their source. The lack of namespaces also drastically increases the probability of naming collisions.

3. Header files… Groan. Defining an interface for every class is such a pain and requires so many more lines of code than are necessary. I find myself dreading every time I require a new class because of this and the fact that XCode’s code completion features are pitiful compared to Eclipse’s.

4. Managing memory: how I miss garbage collection.

5. Pointers: it is exceedingly rare that I would ever want or need to know the memory address of a variable, so why not abstract this information away? It’s easy to forget an * or @ and it can be difficult to debug problems relating to this.

6. Poor logging. NSLog is pretty poor and I haven’t been able to find anything like log4j for Objective-C.

7. Delegation, delelgation and more delegation. Objective-C makes huge use of the concept of delegation and I find that this can lead to spaghetti like code that can be difficult to follow.

8. Compiler reporting: Cryptic error messages and the poor logging described in 7 can make for challenging debugging.

9. Unit testing: OCUnit and OCMock are fairly immature compared to jUnit and jMock. And furthermore, a number of Cocoa classes include real work in their “constructors.” For instance, NSUrlConnection actually opens an HTTP connection and interacts online in its initWithRequest:delegate: method. The problem this creates is that object creation is tied to real work. This makes dependency injection difficult because we can’t separate the creation of the object from the logic, which would be required in order to substitute a test stub with test logic in its place. Dang. For more on this, see Misko Hevery’s great article on unit testing, object creation and logic.

10. No private methods. I often find myself in the position of using private methods within a class to define the specification of a procedure within that class… e.g.

loadSomeData();
doSomethingToData();
sendDataSomewhereElse();

These would all be private methods with the detail abstracted away. Unfortunately such methods need to be defined as part a class’s (public) interface even if only used within that class. Argh.