Xcode 6 - How to Create Vector Image Assets for an iOS App
The Udacity iOS Nanodegree course often asks questions to inspire additional exploration of tools such as Xcode. During the Intro to iOS App Development with Swift lesson, Udacity asked students, “How will you create image assets for your app? In other words, how can you generate 1x, 2x and 3x image assets automatically?” Since Udacity encourages blogging as a strategy for reinforcement and learning, I decided to go ahead and post my findings (and many, many more to come).
In order to save time creating vector images, Xcode 6 has support for creating vector images at build-time. In order to do this:
1. Create the vector image of your choice using vector-based software like Adobe Illustrator. This image has to be the 1x size that you expect to use for your app.
2. Export the vector image to a PDF.
3. Open up Xcode 6 and create an Image Assets (Images.xcassets) if you do not already have one. This file can be found in the Project navigator.
4. Create a "New Image Set.”
5. View the Attributes of the Image Set you just created and change the property "Scale Factors" to "Single Vector."
Note: The Image Set will now show one "Universal" slot for a single image.
6. Drag your exported PDF into the "Universal All" slot in your Image Set / Assets.
7. Build and run your app.
Note: Although at build-time Xcode 6 will generate the additional necessary vector images for your apps, it does not store the images in your Image Set. However, this is a nice way to save space and stay organized since you would not have to manually create a new image for each sizing scale, especially if in the future Apple introduces 4x, 5x, etc.
Ta-da! Hopefully this is a helpful Xcode feature for some of you. If you are interested in reading about this process in detail, there are some great articles here:
Using Vector Images In Xcode 6
Stack Overflow - How do vector images work in Xcode 6 (i.e. pdf files)?
Core Data tutorial part 4.2 / 5 - Using NSFetchedResultsController, Reorder/Moving Table View Cells with Long Press Gesture, and update immediately Core Data displayOrder attribute
IOS 8.1 Xcode 6.1
The full tutorial with explanations
“You must to know!” Collection - Core Data simple explanations
With Core Data framework you can managed your objects in your App. You can manage your object’s life cycle and object graph, so the attributes and relationships of your entities. You can edit, save modify and rebuild your database. You can group, filtering, organizing your data. I try to explain just the basics with my example.
I’m going to create a model with users who are listed some types (family, classmates, friends, love) and they have various hobbies.
In our model a user can belongs to only one type, but one type can contain multiple users. For example, the family type may contain brother, mother, and father as well. But Father user cannot be in the type of “classmates”, if it belongs to already “family” type.
1. ManagedObject, ManagedObjectModel and ManagedObjectContext
First you need to describe your objects or entities, so you have to create a schema, which can tell what is the property or name or class, and which attributes can you use to describe your object, which belongs to an array. This schema will be the Managed Object Model. For example:
Entity Description:
Name: “User”
Classname: “User”
Property: array
The array property consists collection of attributes and relationships. Example:
Attribute ————— collection
Name: “userName”
Type: “string”
ValueClass: “NSString”
Attribute ————— collection
Name: “userBirthDate
Type: “date”
ValueClass: “NSDate”
Relationship ————— collection
Name: “typeofuser”
Destination Entity: Type
More info about Managed Object Model in Developer Library
The ManagedObjectContext is the place or space, her you can manage your collections of managed objects. You can do any modification with your objects and relationships in the same context, so you can manage and follow their life cycle.
More info about ManagedObjectContext in Developer Library
2. PersistentStoreCoordinator
Developer Library gives you a very clear explanation:
"A persistent store coordinator associates persistent object stores and a managed object model, and presents a facade to managed object contexts such that a group of persistent stores appears as a single aggregate store. A persistent store coordinator is an instance of NSPersistentStoreCoordinator. It has a reference to a managed object model that describes the entities in the store or stores it manages.
The coordinator is the central object in a Core Data stack. In many applications you just have a single store, but in complex applications there may be several, each potentially containing different entities. The persistent store coordinator’s role is to manage these stores and present to its managed object contexts the facade of a single unified store. When you fetch records, Core Data retrieves results from all of them, unless you specify which store you’re interested in.”
In our example, we have one type with more users, so this will be a one to many, so “to-many” relationship. We can call this relationship “usersoftype”, which located at Type Entity, but the Destination is User Entity.
It has an Inverse, because we have more users with one type, so this relationship from this side, will be “to-one”. And we can call “typeofuser” which belongs to User Entity, but the Destination will be “Type”, because the connection end/belongs at/to “Type” Entity.
You can see in Xcode the Core Data model in Graph Editor Style, and you can check yourself:
"You can specify a relationship as being to-one or to-many. To-one relationships are represented by a reference to the destination object. To-many relationships are represented by mutable sets (although fetched properties are represented by arrays). Implicitly, “to-one” and “to-many” typically refer to “one-to-one” and “one-to-many” relationships respectively. A many-to-many relationship is one where a relationship and its inverse are both to-many. These present some additional considerations, and are discussed in greater detail in Many-to-Many Relationships.”
Source Core Data Relationships
4. Delete Rules
We have Type Entity and User Entity, and we have usersoftype and typeofuser relationships. When you do the settings, this will look like this:
User Entity
Relationship: “typeofuser”
Destination: “Type”
Type: “To One”
Delete Rule: “Nullify”
In this case we just tell to the destination object “null”, when the object deleted.
Type Entity
Relationship “usersoftype”
Destination: “User”
Type: “To Many”
Delete Rule: “Cascade”
In this case if you delete this type (family), you automatically delete all users, which belongs to this type (brother, mother, father).
"Relationship Delete Rules
A relationship’s delete rule specifies what should happen if an attempt is made to delete the source object. Note the phrasing in the previous sentence—”if an attempt is made…”. If a relationship’s delete rule is set to Deny, it is possible that the source object will not be deleted. Consider again a department’s employees relationship, and the effect that the different delete rules have.
Deny
If there is at least one object at the relationship destination, then the source object cannot be deleted.
For example, if you want to remove a department, you must ensure that all the employees in that department are first transferred elsewhere (or fired!) otherwise the department cannot be deleted.
Nullify
Set the inverse relationship for objects at the destination to null.
For example, if you delete a department, set the department for all the current members to null. This only makes sense if the department relationship for an employee is optional, or if you ensure that you set a new department for each of the employees before the next save operation.
Cascade
Delete the objects at the destination of the relationship.
For example, if you delete a department, fire all the employees in that department at the same time.
No Action
Do nothing to the object at the destination of the relationship.
For example, if you delete a department, leave all the employees as they are, even if they still believe they belong to that department.”
4. Fetch Request, NSPredicate and NSSortDescriptor
If you would like to edit, or show your objects or your object’s attribute, you should do a fetch request. You can call your Entity’s objects in an Array, and then you can work with them. You can use NSPredicate to tell in which parameters would you like to fetch your objects, and of course you can tell for example, that you want to order your results ascending alphabetical. You can do this with NSSortDescriptor.
"A fetch request tells a managed object context the entity of the managed objects that you want to fetch; optionally, it specifies other aspects such as constraints on the values the objects’ properties must have and the order you want the objects returned in. A fetch request is an instance of NSFetchRequest. The entity it specifies is represented by an instance of NSEntityDescription; any constraints are represented by an NSPredicate object, and the ordering by an array of one or more instances of NSSortDescriptor. These are akin to the table name, WHERE clause, and ORDER BY clauses of a database SELECT statement respectively.
You execute a fetch request by sending a message to a managed object context. The context returns an array containing the objects (if any) that matched the request.”
Fetch request source
5. Now you can start the Core Data tutorial
I create a serie, you can learn everything in these parts!
You can find the first part here:
Core Data tutorial Part 1 / 5 - Create Core Data Managed Object Model with Attributes, Relationships and Delete Rules
Core Data tutorial Part 2 / 5 - Save Entity’s Attributes, Relationships, and make FetchRequest
If you would like to be notified of my new solutions, please subscribe to my youtube channel and/ or follow me on twitter!
I have been testing out SceneKit for a couple of days as it will be included in the book on iOS 8 Game Development.
Almost all the tutorials show how to modify the code that is already present in the ViewController class. Although that is fine but I wanted to see how we can create a separate SCNScene class and include all the code that is there in the viewDidLoad() function.
So far I have been quite successful in loading the scene from a class. Lets see how to do it.
I created a new Swift file called testScene.swift and included
import Foundation
import UIKit
import SceneKit
I inherited from the SCNScene class and added a custom init function that took in a view of type UIView. In it I pasted all the code from the viewDidLoad function as below.
init(view: UIView) {
super.init()
scnView = view as SCNView
// create a new scene
let scene = SCNScene(named: "art.scnassets/ship.dae")!
The CLLocationManager, introduced in iPhone OS 2, has always worked the same way: Create, delegate, start, wait. // Import CoreLocation framework // …
Finally updating to XCode 6 and working with iOS 8 caused my Foursquare app to stop updating locations (and thus stop doing anything useful on a first run). After only a couple minutes of digging, I found out that this is a common problem because some small-ish but important changes have taken place with starting the CLLocationManager.
Basically location services are more closely monitored and explicit in usage for iOS 8, and the app needs to reflect these changes or the OS will simply not allow the app to get locations. For my app, I think this is only a couple lines of code in difference, though, so huzzah.
