Article. Communication Patterns - Foundation - objc.io issue #7. Every application consists of multiple more or less loosely coupled objects that need to communicate with each other to get the job done. In this article we will go through all the available options, look at examples how they are used within Apple’s frameworks, and extract some best-practice recommendations regarding when you should use which mechanism. Although this issue is about the Foundation framework, we will look beyond the communication mechanisms that are part of Foundation – KVO and Notifications – and also talk about delegation, blocks, and target-action. Of course, there are cases where there is no definitive answer as to what pattern should be used, and the choice comes down to a matter of taste. But there are also many cases that are pretty clear cut. In this article, we will often use the terms “recipient” and “sender.”
Patterns First we will have a look at the specific characteristics of each available communication pattern. Notifications Delegation Blocks Target-Action. Custom Formatters - Foundation - objc.io issue #7. When formatting data into a user-readable format we tend to use quick one-off solutions. This is a shame because Foundation comes with NSFormatter, which is perfectly suited for this task and can be easily reused throughout your code base. Heck, if you’re on a Mac, AppKit classes have built-in support for NSFormatter, making your life a lot easier. Built-in Formatters Foundation comes with the abstract NSFormatter class and two concrete subclasses: NSNumberFormatter and NSDateFormatter. We’re going to skip these and jump right into the deep end, implementing our own subclass. If you need a more subtle introduction, I recommend reading this NSHipster post. Introduction NSFormatter by itself doesn’t do anything, except throw errors. Because we don’t like errors, we’ll implement an NSFormatter subclass that can transform instances of UIColor to a human-readable name.
KPAColorFormatter *colorFormatter = [[KPAColorFormatter alloc] init]; [colorFormatter stringForObjectValue:[UIColor blueColor]] Linguistic Tagging - Foundation - objc.io issue #7. One of the main challenges when handling natural language (as opposed to programming languages) is ambiguity. While programming languages are designed to have one and only one possible interpretation, human languages derive a lot of their power from being vague and unspecific, because sometimes you don’t want to tell someone exactly how you feel about something. This is perfectly fine for social interaction, but it’s a real pain when trying to process human language with a computer. A straightforward example of this is the use of tokens. A tokeniser for a programming language has unambiguous rules about what constitutes a token, and what type it is (statement separator, identifier, reserved keyword, etc.). In languages, this is far from obvious. Is can’t one token or two?
Sentences are equally bad: Simply assuming a full stop terminates a sentence fails miserably when we use abbreviations or ordinal numbers. The source code is on GitHub, and a sample text is also included. Tag Schemes. Key-Value Coding and Observing - Foundation - objc.io issue #7. Key-value coding and key-value observing are two formalized mechanisms that allow us to simplify our code by harnessing the dynamic and introspective properties of the Objective-C language. In this article, we’ll take a look at some examples on how to put this to use. Observing Changes to Model Objects In Cocoa, the Model-View-Controller pattern, a controller’s responsibility is to keep the view and the model synchronized. There are two parts to this: when the model object changes, the views have to be updated to reflect this change, and when the user interacts with controls, the model has to be updated accordingly.
Key-Value Observing helps us update the views to reflect changes to model objects. Let’s look at a sample: Our model class LabColor is a color in the Lab color space where the components are L, a, and b (instead of red, green, and blue). Our model class will have three properties for the components: Dependent Properties With this, we have all we need for our class interface: and: The Foundation Collection Classes - Foundation - objc.io issue #7. NSArray, NSSet, NSOrderedSet, and NSDictionary Foundation’s collection classes are the basic building blocks of every Mac/iOS application. In this article, we’re going to have an in-depth look at both the “old” (NSArray, NSSet) and the “new” (NSMapTable, NSHashTable, NSPointerArray) classes, explore detailed performance of each of them, and discuss when to use what. Author Note: This article contains several benchmark results, however they are by no means meant to be exact and there’s no variation/multiple runs applied.
Their goal is to give you a direction of what’s faster and general runtime statistics. Big O Notation First, we need some theoretical background. For example, if you sort an array with 50 elements, and your sorting algorithm has a complexity of O(n^2), there will be 2,500 operations necessary to complete the task. Mutability Most collection classes exist in two versions: mutable and immutable (default). What’s the big advantage? NSArray Performance Characteristics Sorting. Travis CI for iOS - Build Tools - objc.io issue #6. Have you ever tried to set up a continuous integration server for iOS? From my personal experience, it is not easy. You have to organize a Mac and install software and plugins. You have to manage user accounts and provide security. You have to grant access to the repositories and configure all build steps and certificates.
During the project lifetime, you have to keep the server healthy and up to date. In the end, you will spend a lot of time maintaining the server – time you wanted to save in the first place. But if your project is hosted on GitHub, there is hope: Travis CI. In this article, I want to show you step by step how to set up your project for Travis. GitHub Integration What I really like about Travis is how well it is embedded in the GitHub web UI. In case the build doesn’t succeed, the page will be colored accordingly on GitHub: Let’s have a look on how to link your GitHub project with Travis.
Once signed in, you have to enable your project for Travis. Language: objective-c #! Re-Designing an App for iOS 7 - iOS 7 - objc.io issue #5. Watching the WWDC presentation of the new version of iOS, we were looking at our app Grocery List and realized: This iOS version is a complete restart, like the first introduction of the iPhone seven years ago. It’s not enough to simply change the design. We had to rethink and rebuild the application to fit within the new environment. So we did. While the basic behavior of an app should not be changed, we decided to do so based on user feedback and our own usage that made us realize we had to improve some workflows.
On our way to achieving this, we encountered some topics that we thought would be useful to share. Animations Current mobile devices are becoming more powerful with each iteration. The new SDK allows you to easily create and use custom animations. In Grocery List, we use a slightly modified transition to display a modal controller. Gestures After several years of experience with touch devices, Apple discovered that the wider use of gestures is becoming more natural to users.
One of the things almost every app developer has to do in his or her life is import things from a web service into Core Data. This article describes how to do that. Everything we discuss here has been described before in previous articles, and by Apple in its documentation. However, it is still instructive to have a look at how to do from start to finish. The full source of the app is available on GitHub.
Plan We will build a small read-only app that shows a list of all the CocoaPods specifications. We proceed as follows: First, we create a PodsWebservice class that fetches all the specs from the web service. Getting Objects from the Web Service First, it is nice to create a separate class that imports things from the web service. We want to create a class that has only one method, fetchAllPods:, that takes a callback block, which gets called for every page. @interface PodsWebservice : NSObject - (void)fetchAllPods:(void (^)(NSArray *pods))callback; @end That’s all there is to it.
Conclusion. Introduction Developing a mobile application is a creative process. You want to build something beautiful and functional. Something that works well on any device. Something that delights your users. One common misconception about Android development is that it’s hard to write these kinds of applications when screen properties vary so widely. The truth is, you will have to put some thought into the design, but not significantly more than you would on other platforms.
In this article, I will focus on three areas of variability in Android devices and how those variations affect the development and design of Android applications. How do Android developers optimize for minor variations in screen sizes? Screen Size Let’s review screen sizes on iOS. The iOS drawing system uses points and not pixels, so the screen’s retina or non-retina status does not impact layout. In contrast, on Android, there are orders of a magnitude of more screen sizes that we must support.
Layout Files Screen Density DIPs. Objc.io. UICollectionView and the set of associated classes are extremely flexible and powerful. But with this flexibility comes a certain dose of complexity: a collection view is a good deal deeper and more capable than the good old UITableView. It’s so much deeper, in fact, that Ole Begeman and Ash Furrow have written about Custom Collection View Layouts and Collection Views with UIKit Dynamics in objc.io previously, and I still have something to write about that they have not covered. In this post, I will assume that you’re familiar with the basics of collection view layouts and have at least read Apple’s excellent programming guide and Ole’s post.
The first section of this article will concentrate on how different classes and methods work together to animate a collection view layout with the help of a few common examples. The two example projects for this article are available on GitHub: Collection View Layout Animations Inserting and Removing Items Which results in this: Oops… Summary. Objc.io. By default, almost every standard property of CALayer and its subclasses can be animated, either by adding a CAAnimation to the layer (explicit animation), or by specifying an action for the property and then modifying it (implicit animation).
But sometimes we may wish to animate several properties in concert as if they were a single animation, or we may need to perform an animation that cannot be implemented by applying animations to standard layer properties. In this article, we will discuss how to subclass CALayer and add our own properties to easily create animations that would be cumbersome to perform any other way. Generally speaking, there are three types of animatable property that we might wish to add to a subclass of CALayer: A property that indirectly animates one or more standard properties of the layer (or one of its sublayers).
A property that triggers redrawing of the layer’s backing image (the contents property). Indirect Property Animation The result looks like this: Objc.io. In issue #5, Chris Eidhof took us through the new custom View Controller Transitions in iOS 7. He concluded (emphasis mine): We only looked at animating between two view controllers in a navigation controller, but you can do the same for tab bar controllers or your own custom container view controllers… While it is technically true that you can customize the transition between two view controllers in custom containment, if you’re using the iOS 7 API, it is not supported out of the box. Far from. Note that I am talking about custom container view controllers as direct subclasses of UIViewController, not UITabBarController or UINavigationController subclasses.
There is no ready-to-use API for your custom container UIViewController subclass that allows an arbitrary animation controller to automatically conduct the transition from one of your child view controllers to another, interactively or non-interactively. Before We Begin Well, sometimes that’s just not what you want. Introducing the API. Objc.io. On iOS, views always have an underlying layer. There is a very strong relationship between the view and its layer, and the view derives most of its data from the layer object directly. There are also standalone layers – for example, AVCaptureVideoPreviewLayer and CAShapeLayer – that present content on the screen without being attached to a view. In either case, there is a layer involved. Still, the layers that are attached to views and the standalone layers behave slightly differently. If you change almost any property of a standalone layer, it will make a brief animation from the old value to the new value.1 However, if you change the same property of a view’s layer, it just changes from one frame to the next.
An explanation as to why this is happening can be found in the Core Animation Programming Guide in the section “How to Animate Layer-Backed Views”: The UIView class disables layer animations by default but reenables them inside animation blocks fromValue is non-nil. Objc.io. The applications we write are rarely a static experience, as they adapt to the user’s needs and change states to perform a multitude of tasks. When transitioning between these states, it is important to communicate what is going on. Rather than jumping between screens, animations help us explain where the user is coming from and where he or she going. The keyboard slides in and out of view to give the illusion that it is a natural part of the phone that was simply hidden below the screen. View controller transitions reinforce the navigational structure of our apps and give the user hints in which direction he or she is moving.
Subtle bounces and collisions make interfaces life-like and evoke physical qualities in what is otherwise an environment without visual embellishments. Animations are a great way to tell the story of your application, and by understanding the basic principles behind animation, designing them will be a lot easier. First Things First A Basic Animation Timing Functions. Objc.io. When Steve Jobs introduced the first iPhone in 2007, the touch screen interaction had a certain kind of magic to it. A prime example of this was his first demonstration of scrolling a table view. You can hear in the reaction of the audience how impressive what seems the most normal thing to us today was back then. A little bit later in the presentation, he underlined this point by quoting somebody he had given a demo to before: “You got me at scrolling”. What was it about scrolling that created this ‘wow’ effect? Scrolling was a perfect example of direct manipulation through capacitive touch displays.
The scroll view obeyed the movements of your finger so closely, and it continued the motion seamlessly after you let go. State of Animations Most animations in iOS still don’t live up to the standard that scrolling set on the original iPhone. However, there are some apps out there that bring that aspect of always in control, direct manipulation to all animations they use. Direct vs. Common Background Practices - Concurrent Programming - objc.io issue #2. Thread-Safe Class Design - Concurrent Programming - objc.io issue #2. The Build Process - Build Tools - objc.io issue #6. CocoaPods Under The Hood - Build Tools - objc.io issue #6. NSString and Unicode - Strings - objc.io issue #9. UICollectionView UIKit Dynamics - iOS 7 - objc.io issue #5. Value Objects - Foundation - objc.io issue #7. Article: Multitasking in iOS 7 - iOS 7 - objc.io issue #5.