Anyone that have recently developed any pods for Cocoapods know that resources should be gathered using the resource_bundles option. What is quite hard to figure out is how, exactly, to access those resources once they’re set up in the bundle. It seems obvious now that I got it working, but I struggle a lot since there wasn’t anything in Stackoverflow or anywhere else that provided the answer I came up with.

After setting up the resource_bundles, Cocoapods copies the resources found in a “resources” folder within the Pods project, but none of them are added in the target’s “Copy bundle resources”. For that reason, I couldn’t access any of the Pod’s images or xibs in my project. Every time XCode threw me this error:

‘Terminating app due to uncaught exception ‘NSInternalInconsistencyException’, reason: ‘Could not load NIB in bundle:<{PATH_TO_APP}> (loaded)’ with name ‘{VIEW_CONTROLLER_NAME}’

The obvious solution that wasn’t listed anywhere is using the Cocoapods generated bundle (which the folder actually doesn’t exist) as a NSBundle:

NSString *bundlePath = [[NSBundle mainBundle] pathForResource:@"MyBundle" ofType:@"bundle"];

NSBundle *bundle = [NSBundle bundleWithPath:bundlePath];

MyViewController *viewController = [[MyViewController alloc] initWithNibName:@"MyViewController" bundle:bundle];

[self.navigationController pushViewController:viewController animated:YES];

Yes, it’s that simple, that obvious, though it’s not listed anywhere. I believe to be prudent and convenient to write about it in order to help anyone who encounter themselves in the same situation as I did.

This morning, Cicada 3301 went back to active! In his/hers Twitter account used on last year’s challenge there was new link to an image posted on imgur.

First Chapter

Reproducing the tradicional previous steps, by extracting the image using outguess we came onto a message, once again signed. Its authenticity could be proved using Cicada’s previous known public key.

Now let’s get our hands dirty! The first task was easy, since it’s steps were already elucidated on previous years. Now things start to get interesting.

If you’re interested in following the challenge progress, Uncovering Cicada is on a good pace.

Good luck, and good hunting!

I believe that every iOS developer is already aware of Apple’s new directive forbidding any apps using frame to be submitted to the Appstore when the new iOS 7 goes public. That means that ALL new app will have be developed using this tool created by the son of a devil called autolayout.

Anyone that has already used autolayout knows that margin, width, height and other properties are calculated in runtime, therefore, they consume sometimes unnecessary CPU time. For some inescrutable reason, Apple decided to create this new concept from scratch to ease working with different sized screens, while they could easily reuse existing CSS concepts like marginpadding, among others. In addition to being extremely confusing (a UIView's margin constraints are in its superview), having a pitiful syntax  (“V:|-(-5)-[view1]-(>=10)-[view2]-(912837)-|”)autolayout also makes everything slow.

Protip: if you’re configuring your coinstraints via code, never forget seting self.translatesAutoresizingMaskIntoConstraints = NO in your view. It took me a couple of coffee cups to realise this was the reason why my  constraints weren’t being executing along with [self layoutIfNeeded].

I recently had to work with a UICollectionView and the scroll was getting really laggy. Anytime a new cell was loaded, the framerate dropped. After spending a few hours trying to find the root of the problem with a couple of friends (we even considered the problem being the SDK’s dequeue thanks to  Profiler) some inspired insight hit us and we decided to disable autolayout on the UICollectionViewCell's xib and everything flowed like a beautiful stream under the morning sunlight of tropical woods. So let us analise what happened: Apple created a new concept, from the grounds, that theoretically would solve all problems when working with screens of different sizes, but this devilish concept is composed of runtime calculated values that ruin the app’s smoothness. Yep, it gets hard to work happily…

This view that is the UICollectionView's cell will not have autolayout. Nobody knows what will happen when we submit the app to the Appstore and we sincerely hope that Apple doesn’t mind this view that, although is not explicitly using frames, also is not configured to accept autolayout.

I’m yet to find an iOS developer that has nothing to complain about this weird invention, but, as usual, Apple’s “this is what we want, so deal with it” policy doesn’t give us any alternatives. Instead of easing developers’ work, they’re making our daily lives every more difficult while Android scores another point Apple is walking backwards.

Fork me on GitHub

In any kind of environment, visual marks ease and enhance the comprehension of information. Countless researches studied the best way to display data, which colors induce what emotions, the association of geometric shapes with pre-formed concepts. The fact is that a sign or plaque draws much more attention than plain text. After all, an image is worth a thousand words, therefore, an image sends a much more significant message than some written words.

That’s one of the reasons many development tools have featured badges (or  shields) to inform the status of an application/framework/library/etcetera. It’s the case of Travis CICode ClimateGemnasium, among others, all following olivierlacan/shields` trend, available Github.

I’m an iOS developer and previously have worked with Python/Django (though I still fool around) and I’ve always found very interesting this creative way of sharing the state of a service dynamically, but sadly, there were no solution to Python nor iOS featuring badges (except for Travis CI for tests). But, recently, appeared - out of nowhere - pypip’s shields for Python packages that allows the visualisation of the latest available version of a package on pypi or how many downloads some release *had.* When I came aware if it I resented for taking so long for solution so simple and effective to come up (or at least for I to discover it)… but it got over the top when I found out… or better, did not found out a similar solution for Cocoapods.

I’m one of those who doesn’t miss a chance to solve a problem and endeavour an opportunity. That’s how the Cocoapod Badges  project started. Since Cocoapods doesn’t provide an API, any info on the number of users/downloads, nor any kind of useful data, it proved to be a challenge, and all I could use had to be what was at hand: the latest version of a pod. But even though, mistaken are those who thought it easy. As mentioned, there’s no API!

Cocoapod Badges NSStringMask 1.1.2

Digging through Cocoapod’s and Cocoadocs’ websites, I tried, first, to use the documents.jsonp  file that I found in the source of the pod’s documentation website, however, I soon gave up for realising that its update frequency is too high (above one hour). At last, I had to content with the unfortunate /search?q= requested when searching for a pod in Cocoapod’s main page. At first, it looked like an excellent solution since it returned a json object with some info, until I realised that inside the object was a string with some html code and only inside that code was the pod’s latest version. “God dammit!” Now I have to run a request on a “pseudo-webservice” and parse it with XPATH to get the latest version!

Super easy! But, as my mother would on a brazilian saying: “few shit is silliness”. The damned “API” doesn’t return the requested pod, but anything with the searched string. To get something more useful, I figured that  /search?q=name:POD_NAME searches only in the pod’s name and not in its description, what significantly reduces the results, specially when dealing with popular pods such as AFNetworking.

After all that suffering, I finally got the information I wanted, but then, how do I show it in an image? Olivier Lacan’s repo, that enabled all the existing  badges, provides, beyond the .png to existing services, .SVG vectorial files that render xml data to images. So, accidentally, I double-clicked the  .SVG file and the holy Google Chrome opened it as an image! Finally good news! As the information about the version is in plain text inside the xml, all I had to do was to set the mimetype so Django could provide the file as an image.

Heroku dyno later and the service is available fulltime (depending on Cocoapods website) through the images’ url:

http://cocoapod-badges.herokuapp.com/v/$PODNAME/badge.png

All you have to do is replace the $PODNAME with the name of the pod you want. Simple and easy, isn’t it? Use it at will! And suport the Github repo!

This is an article I originally wrote for the brazilian online magazine DevMedia’s Mobile Magazine. This first part is the article’s introduction, so seat back and relax. Soon I’ll post the second - and final - part with a tutorial to the Apple like documentation generator appledoc.

“In the agile programming environment, using methodologies such as SCRUM, Agile and Lean, we can’t always document our sources. After all, pragmatics as we developers are, why would we lose time if the documentation won’t be compiled, won’t do any difference in the code’s performance and demands a considerable slice of our time? But despite all that, the lack of documentation hurts. A lot.

Who’s familiarised, knows that in the ultra accelerated rhythm of startups, where everything is at the top of the list, there’s not always time to apply some of the good programming technics that aren’t crucial to the sanity and speed of the code. Oftenly, there’s no time to formally test classes and methods because of the virtually null due time that is given. It’s easy to find developers awake all night in hackatons to successfully deliver that key feature that will make “the whole difference”. Test? Document? Review? There’s so much to do and so little time!

That’s the reality of many young developers who enter this ultra competitive environment searching for the dream of running their own companies. The responsibilty of satisfying potential investors, the pressure for deploys and the client’s needs frequently obfuscate technics that improve development and maintenance experiences, but that are not considered primordial to the construction of an application. How often didn’t I went back to an undocumented code done less than two months before and thought “what the flock does this loop do?” or “why, on earth, is this class here and not there?” Of course, when those lines of code were written, everything made perfect sense, but the moment those ifs and fors went out of the conscious mind, their meaning were long gone. After all, quoting the chinese saying: “the ink is better than memory”.

So let us document. It doesn’t hurt, doesn’t make you fat and isn’t illegal. Actually, documenting is like eating vegetables: no one really likes it, but we do it hopping that, in the end, it’s worth the result. But unlike the vegetables, it’s proved that documenting helps. Contrary to the common thought, the time spent documenting a day’s work is reasonably irrelevant and the benefit in return is definitely worthy. With practice and experience, no more than 30 minutes can be lost documenting everything that was made in a whole day. That way, the developer stays focused in his activity and doesn’t deviates doing other stuff that draws his attention or stand in his way of writing the best possible algorithm. Therefore, don’t wait until the end of the week, when the work pile up, part of the features were already forgotten and we’re all dying to that ice-cold friday-night-beer. Personally, I recommend documenting in the end of the day. In my case, it’s always the last thing I do before leaving, because everything is still fresh in memory and the amount of code produced in one day doesn’t compare to what’s done in one week. If that’s not enough, I realised that I do a final unconscious revision before the final commit when I’m passing by the code documenting it.

A well documented code is good for everybody. What would be of us without the independent frameworks, packages and repositories used daily if they weren’t documented, or even had a bad documentation? Even senior programmers, frequently, return to Apple’s documentation to a better understanding of Cocoa’s classes. Whether consulting a less used protocol, or lower level functions to manage sockets, threads or semaphores. Nobody can remember everything, so don’t try it, you’re not an elephant. It’s not rare to find developers who use the documentation as a last resource to understanding some tool. This line of thought makes sense if we think that we want everything to be as explained as possible so we don’t lose any time trying to interpretate any possible use, when trying to comprehend some feature. But we must never forget that even when visiting forums, asking more experienced developers or reading articles in blogs, EVERYTHING had a documentation as basis. Well, even this article wouldn’t exist if wasn’t for appledoc’s documentation.

Documenting - or at least commenting - source codes is fundamental to the intelligibility of the code. Implementing these technics with developers that never done it, oftenly is seen with prejudice and suspicion that are common to the staunch and stubborn nature of young programmers. I must confess that I didn’t wanted to document when people first told me to. Moreover, because of it’s so unusual syntax, it’s interesting to verbalize what’s developed in ObjC to ease it’s lecture, specially by more unexperienced programmers.

As time goes by, with the expansion of the startup, the pressure and need of code documentation is felt. Contrary to many programming languages - such as Java with it’s hideous GUI Javadoc - Objective-C doesn’t have an “official” documentation generator. In our quest to find a differentiated framework, which could make us feel as if we were really making difference, we found the excellent appledoc that, using code comments à la Javadoc, generates Apple like documentation, with a docset automagically installed in XCode, static HTML sources which can be uploaded to a cloud (vide  NSStringMask which uses appledoc) and an interface identical to Cocoa’s.

Among appledoc)’s already described advantages, are also the documentation parsing through code comments, wich allow the developer to consult the documentation without the need of opening a new window, since everything is in the code. The integration with XCode allows the visualisation of tooltips with quick access to the documentation by simply holding the Option key and clicking a method or class. Moreover, by “compiling” appledoc) in your documented project, the library’s docset is already imported to your Organizer. Simple or not? But, undoubtedly, appledoc)’s main advantage is it’s interface that’s identical to Apple’s documentation. I think it’s very unlikely that there’s any ObjC developer that has never read Cocoa’s documentation, be the one embedded on XCode or the on in Apples developers portal. By reusing the known model, it terminates the problem of having to familiarise to a new layout.”

Soon I’ll be posting the second part with a tutorial.