More than 3 million people use MailChimp to design and send email marketing campaigns. And today they launched a native iPad client that lets you create and edit such campaigns. For the parts of that which require rich text editing they rely on our DTRichTextEditor component.
As of this version BarCodeKit gains implementations for all of the most important 1D symbologies. Most of the work on this release was done by Jaanus Siim and Geoff Breemer in exchange for licenses to use this library for their own projects. BarCodeKit 1.1 is a free update for existing users and available for purchase on our Parts Store.
Apple recently added the ability for Xcode to automatically create instance variables for you. This means you no longer need to add an @synthesize for each property you create.
But does it really do that always, or are there scenarios where no _ivar is needed? Are there situations wehre you do need an explicit synthesis? For example what about properties which are just passing through values to a sub-object?
I wanted to know, so I experimented a bit. I even filed a Radar with Apple for clarification which came back with a good explanation.
If you have an project that is accepting code contributions then you will want to make sure that those well-meaning additions don’t break existing functionality. Services like GitHub allow you to review such pull requests via their colored diffs or even give instructions as to how to manually pull the commits into a local branch for evaluating this.
But there is a limit that is quickly being reached if you need to check all those pull requests manually. Even worse, this is a mundane task, usually trying out if the targets build and running the unit tests. Repetitive tasks like this are boring and thus nobody can be faulted for starting to neglect them.
In this blog post I will explain how to set up Travis-CI to have all pull requests be automatically checked for you. You will know for each pull request if merging it into your develop branch would break the build or unit tested functionality.
UICollectionView was added last year with iOS 6 and to this date I had no real chance to get acquainted with it since most of my apps were still supporting iOS 5. Doing a fresh app only supporting the latest iOS version finally allowed me to dig into it and share the journey with you.
The special scenario we want to look at today is how we could configure variable-sized collection view cells for items like tags. We want to have the cells adjust their size automatically based on the tag string and ideally we don’t want to have to write any layout code for determine the needed sizes.
Please forgive if the following has a few places where I stumbled. It is these temporary snags that I believe you learn from the most, so I left them in the final article.
This is a maintenance release addressing several crashing problems.
iOS7 will have the ability to scan 1D and 2D bar codes built-in. The same is true for generating 2D bar codes. Which begs the question why Apple opted to omit support for creating 1D bar codes. (rdar://14694904)
One second hand explanation I heard was that laser-based scanners might have trouble reading 1D codes from the screen of an iPhone, whereas 2D codes require a camera anyway and therefore can be easily scanned even from a display.
While this explains the omission to a certain degree, I don’t buy it. I can think of many scenarios where you would want to print a 1D bar code, or put it into a PDF that is supposed to printed. Also, as CCD-based scanners become more prevalent they will soon be available in larger numbers than laser-based scanners.
In short, I am seeing a niche that is not being served. Thus I’m announcing BarCodeKit.