Now if you’ve not worked with Core Data before, or never had to look hard under the hood at what it’s doing when to add items to it you may never have come across -com.apple.CoreData.SQLDebug before. This is a runtime argument that is passed in to your app at launch that (depending on the logging level – 1 through 3) spews out in-depth info on what is being inserted etc in to your Core Data store.

I tend to use:

-com.apple.CoreData.SQLDebug 3

As I said this worked fine in Xcode 8, but stopped working in Xcode 8.1. Unsurprisingly it was because there had been a change to how logging in general is handled in Core Data with macOS 12.0 and iOS 10.0 onwards. Now you need to add an additional argument to the run arguments:

-com.apple.CoreData.Logging.stderr 1

You can see both entries in the screenshot of my scheme entry below (click to open a larger version).

Obviously if I had read the update notes for Core Data in Xcode 8.1, I would have seen this tucked away near the bottom – but I’m a typical bloke and therefore I read no instructions whatsoever and all of my Ikea furniture is wonky because of it :p.

Hopefully you’re not like me and you’ve had time to read this instead, and your flat-packed furniture is well made?

The post Debugging Core Data In Xcode 8.1 Not Working? first appeared on That Mike Jones.

As part of the update I will be looking at ways to archive a lot of the older articles and fix any broken links, images and the like.

Hopefully you’ll like the new design (whatever that may be) and it will be within keeping to the overall focus and spirit of this site?

Keep watching this space for further updates!

Thanks
–
m

The post Site clean-up and archiving first appeared on That Mike Jones.

I happened to have one of his videos running on my second monitor while I was coding and my ears pricked up when he started speaking about a helper extension he was using (and I assume also created) that took away some of the verbose boilerplate code that you need to write when creating Auto Layout constraints programmatically using the visual formatting language (VFL). Now this may not be useful if you need to add additional NSLayoutFormatOptions beyond the defaults but for the majority of use cases this is very handy.

To that end I wanted to share the code

1. because I think it’s very handy if you do a lot of constraint configuring in code
2. and because Brian’s videos are great and you should check them out (regardless of your ability)

So here’s the code:

import UIKit

extension UIView {
    
    func addConstraintsWithFormat(format: String, views: UIView...) {
        
        var viewDictionary = [String: UIView]()
        
        for (index, view) in views.enumerated() {
            let key = "v\(index)"
            viewDictionary[key] = view
            view.translatesAutoresizingMaskIntoConstraints = false
        }
        
        self.addConstraints(NSLayoutConstraint.constraints(withVisualFormat: format,
                                                           options: NSLayoutFormatOptions(),
                                                           metrics: nil,
                                                           views: viewDictionary))
        
    }
}

Here is how you’d implement it within a custom view for example:

self.addConstraintsWithFormat(format: "H:|[v0]|", views: contentView)
self.addConstraintsWithFormat(format: "V:|[v0]|", views: contentView)

and here is something slightly more complex…

self.addConstraintsWithFormat(format: "H:|-8-[v0(100)]-8-[v1(>=20)]-8-[v2(100)]-8-|", views: previousButton, pageControl, nextButton)

Pretty clean and compact eh? Anyway I hope you find this useful, and thanks Brian!

The post Auto Layout Visual Format language helpers first appeared on That Mike Jones.

Now anyone whoâ€s used Xcode for any amount of time will know all about its concept of groups. Groups to Xcode are a conceptual way of organising your application within the project overview, but unfortunately have nothing to do with how your files are organised on your hard drive. Now for a lot of us this may not be an issue as a lot of iOS apps have a handful of classes, view controllers and storyboards; so keeping them organised isnâ€t a big deal (well not to normal people but I still see the issue :p).

The problem of ‘virtual†grouping and file system organisation raises its ugly head when you work on a more complex and broader application that may have several hundred classes, view controllers or storyboards etc. and being able to quickly jump to one of the files from outside of Xcode can become problematic. If it does you can approach this in a couple of ways:

1. Ignore it and accept this is how it should be
2. Manually create folders in your actual app folder to replicate the virtual groups in Xcode and organise your code the same way
3. Use something like Synx

So letâ€s go through my non-exhaustive list of options one-by-one and see which may be useful, if like me, you feel it needs more thought.

First up we have Option 1 – the head in the sand approach. Itâ€s the way it is and so it shall remain. To be honest, I have no issue with this if it works for you. It doesnâ€t work for me so Iâ€m more interested in options 2 and 3.

Option 2 – manually recreate the groups as actual folders and move the files in to the same structure as Xcode groups. This works but is very manual and will likely not work on the first pass. This is generally because you have to remove all of the compile sources, linked binaries and bundle resource entries in the Build Phase of your project because they will now all be pointing to the wrong location. Plus all of the entries in your actual project will now have probably turned red as Xcode can no longer find the files. The fix for this is to remove all the file references and add them back to the project based on their new location on your hard drive. Thatâ€ll fix it but as you can see itâ€s a bit brittle. Oh and donâ€t forget your info.plist files will need resetting in the project overview for each target you have set.

gem install synx

If youâ€re using the built in version of Ruby youâ€ll likely need to sudo the previous command, (and you should really consider using RVM).

sync path/to/my/project.xcodeproj

If youâ€re using Cocoapods it may have moved some bits around, which will likely confuse Cocoapods – so to be safe run pod install to recreate your Cocoapods repository again.

If youâ€d like to try it out or know more, head over to the Synx repo on Github: https://github.com/venmo/synx

The post Clean Xcode project directories with Synx first appeared on That Mike Jones.

Anyway, my session topic this year was about Swift 1.0 (given that Swift 2.0 wasn’t getting released, literally, until after I had done my presentation).

If you want to have a look through the slides please feel free to do so, and grab a copy if you want to use it as a basis for a Swift 2.0 session.

A big thanks to all those who attended and for the positive and constructive feedback :)

The post Reasons To Be Creative 2015 Slides first appeared on That Mike Jones.

To that end I’ve decided to climb back in to the blogging saddle and get back to writing up my thoughts, processes and approaches to development, design and everything in between, but now on a slightly broader basis. The first step on this ‘rebirth’, if you will, is the obligatory site redesign – responsive of course. Although that may take a while as I’ll need to fit it in with other stuff like paid work :p.

In the interim I’m going to put up a few posts about some of the tools & frameworks I’m now using on a more regular basis, as well as gotchas and tip/tricks. So stay tuned for something new that’s also familiar.

The post Thinking Things Over? first appeared on That Mike Jones.

So back to the case in point. The reason the default Flash Builder directory can’t be removed is because Adobe saw fit to put linked configuration settings in this folder that Flash Builder uses; as you can see below.

Easily Provoked
Now if you find it both annoying and a trifle odd, like I did, that this information wasn’t placed in the Application Support folder, or the Library folder at the very least. And would like to permanently remove them from your Documents folder then read on. Before we continue I just want to point out that this is obviously a solution for OS X, but should work for Windows (if Adobe have done the same thing of creating a default workspace within your user space and added the cascaded configuration to it, although the paths will be different of course :p).

Editing Flash Builder Configurations
The first thing you’ll need to do is edit the configuration files that Flash Builder loads up each time it is opened. I say configuration files, actually there is only one configuration files but it is duplicated within another folder in the Flash Builder application directory – hence editing 2 files.

You’ll find these inside the Flash Builder application folder (Applications/Adobe Flash Builder 4.6/). The files you’ll need to alter are marked in the image to the right.

Before we start hacking around in Flash Builder’s application directory you need to do some house keeping. The first thing to do is MAKE A COPY OF BOTH CONFIG.INI FILES ON YOUR DESKTOP. I know, a bit over aggressive, but if you muck the next steps up you’ll end up with a broken copy of Flash Builder – You have been warned!

Secondly, you’ll need to create a new directory within your home directory that’ll contain the configuration information that is currently in the ~/Documents/Adobe Flash Builder 4.6/ directory, in a folder called cascaded. As an example I have a directory called Development in the root of my home directory and within there I have various sub-folders for Resources, Repos, Workspaces etc. So I have placed my cascaded folder a sub-folder in there. You don’t have to copy me, but put it somewhere meaningful :)

Final point, make sure you create the folder within your home folder, not in some funky application level or hidden system folder as Flash Builder runs as you and if you need to SUDO, or authenticate to access, or create the folder you’ve just placed the configuration information in, Flash Builder won’t run. With all that out of the way, let’s get updating our Flash Builder configuration.

Select and open one of them (it doesn’t matter which as they are identical), and follow the steps below:

• locate the line osgi.instance.area.default=@user.home/Documents/Adobe Flash Builder 4.6
• change the path after @user.home/ to point to the directory you created earlier
• next locate the line osgi.configuration.area=@user.home/Documents/Adobe Flash Builder 4.6/cascaded/335153/configuration (I’m assuming the number 335153 to be machine specific, so if yours is different, use the one present in your config.ini file)
• save the file
• repeat the exact same steps on the second config.ini file

Below is a copy of my config.ini file so you can see where I’ve made my edits (I’ve put comments around lines that need changing):

#This configuration file was written by: org.eclipse.equinox.internal.frameworkadmin.equinox.EquinoxFwConfigFileParser
#Fri Jul 30 17:13:05 PDT 2010
org.eclipse.update.reconcile=false
eclipse.p2.profile=epp.package.java
#### Change This ####
osgi.instance.area.default=@user.home/Development/Resources/Flex/Linkages/FB4.6
#### 			 ####
osgi.framework=file\:plugins/org.eclipse.osgi_3.7.0.v20110613.jar
equinox.use.ds=true
eclipse.buildId=I20100608-0911
osgi.bundles=reference\:file\:org.eclipse.equinox.simpleconfigurator_1.0.200.v20110502-1955.jar@1\:start
org.eclipse.equinox.simpleconfigurator.configUrl=file\:org.eclipse.equinox.simpleconfigurator/bundles.info
eclipse.product=com.adobe.flexbuilder.standalone.producte36
osgi.framework.extensions=
osgi.bundles.defaultStartLevel=4
eclipse.application=com.adobe.flexbuilder.standalone.FlashBuilderApplication
eclipse.p2.data.area=@user.dir/../../../p2/
#### Change This ####
osgi.configuration.area=@user.home/Development/Resources/Flex/Linkages/FB4.6/cascaded/335153/configuration
####			####
osgi.shared.configuration.area=file\:configuration
osgi.configuration.cascaded=true?

When you save the files you’ll more than likely need to authenticate the save – this is because you’re editing a file that’s not owned by you – it’s not a problem, just type your password in and click OK to apply the changes. Now that’s all sorted fire up Flash Builder.

The Acid Test
Now that both config.ini files have been updated you need to move the contents of the Adobe Flash Builder 4.6 folder (i.e the folder called cascaded), to the new directory you added in your config.ini file. If you have projects stored in this folder too, you’ll need to move them to a new location (this process is out of scope for this article but a quick Google will provide the relevant answer should you need them). Once you have moved all of the content out of the ~/Documents/Adobe Flash Builder 4.6 folder you are safe to delete it.

Now if you have your Documents directory open when Flash Builder starts up you may notice a strange thing. Flash Builder will more than likely re-create the folder you just deleted. However this time it will be empty.

If it recreates the cascaded folder then you’ve missed something out when updating the config.ini files, so go back and check them again.

There are a couple of reasons why it has recreated that folder again. First up is that you still have it set as your default workspace. If so create a new one, switch to it and restart Flash Builder. The second, more likely reason, is that you still have a reference to it in your Flash Builder preferences. This entry is created the first time Flash Builder runs as it is the default workspace

Delete this entry from Flash Builder Preferences, quit Flash Builder. Delete the directory in your Documents folder again and restart Flash Builder. This time it should behave as expected and no folder will be created.

Perfect, the world is at one again :D

The post Remapping Flash Builder 4.x’s Default Workspace in OS X first appeared on That Mike Jones.

“FlashGen.Com” is committed to ensuring that your privacy is protected. Should we ask you to provide certain information by which you can be identified when using this website, then you can be assured that it will only be used in accordance with this privacy statement.

“FlashGen.Com” may change this policy from time to time by updating this page. You should check this page from time to time to ensure that you are happy with any changes. This policy is effective from 01/01/2012.

What we collect
We may collect the following information:

• name
• contact information including email address
• demographic information such as postcode, preferences and interests
• other information relevant to customer surveys and/or offers

What we do with the information we gather
We require this information to understand your needs and provide you with a better service, and in particular for the following reasons:

• Internal record keeping
• We may use the information to improve our products and services
• We may periodically send promotional emails about new products, special offers or other information which we think you may find interesting using the email address which you have provided
• From time to time, we may also use your information to contact you for market research purposes. We may contact you by email, phone, fax or mail. We may use the information to customise the website according to your interests

Security
We are committed to ensuring that your information is secure. In order to prevent unauthorised access or disclosure we have put in place suitable physical, electronic and managerial procedures to safeguard and secure the information we collect online.

How we use cookies
A cookie is a small file which asks permission to be placed on your computerâ€s hard drive. Once you agree, the file is added and the cookie helps analyse web traffic or lets you know when you visit a particular site. Cookies allow web applications to respond to you as an individual. The web application can tailor its operations to your needs, likes and dislikes by gathering and remembering information about your preferences.

We use traffic log cookies to identify which pages are being used. This helps us analyse data about webpage traffic and improve our website in order to tailor it to customer needs. We only use this information for statistical analysis purposes and then the data is removed from the system.

Overall, cookies help us provide you with a better website, by enabling us to monitor which pages you find useful and which you do not. A cookie in no way gives us access to your computer or any information about you, other than the data you choose to share with us.

You can choose to accept or decline cookies. Most web browsers automatically accept cookies, but you can usually modify your browser setting to decline cookies if you prefer. This may prevent you from taking full advantage of the website.

Links to other websites
Our website may contain links to other websites of interest. However, once you have used these links to leave our site, you should note that we do not have any control over that other website. Therefore, we cannot be responsible for the protection and privacy of any information which you provide whilst visiting such sites and such sites are not governed by this privacy statement. You should exercise caution and look at the privacy statement applicable to the website in question.

Controlling your personal information
You may choose to restrict the collection or use of your personal information in the following ways:

• whenever you are asked to fill in a form on the website, look for the box that you can click to indicate that you do not want the information to be used by anybody for direct marketing purposes
• if you have previously agreed to us using your personal information for direct marketing purposes, you may change your mind at any time by emailing us

We will not sell, distribute or lease your personal information to third parties unless we have your permission or are required by law to do so.

If you believe that any information we are holding on you is incorrect or incomplete, please email us as soon as possible. We will promptly correct any information found to be incorrect.

The post Privacy Policy first appeared on That Mike Jones.

Even though I knew my role was at risk back in November, yesterday was officially my last day, hence my somewhat delayed announcement. Don’t get me wrong, I’m not bitter, I had a great 18 months working and meeting with some truly amazing people and companies. I want to thank everyone I worked with at Adobe for making it a really enjoyable, enlightening and inspiring time – like Flash, you guys ROCK!

So what next? Well, you’ll just have to watch this space :)

The post New year, new beginning first appeared on That Mike Jones.

Diving In

So let’s look at how you start adding, and animating, content with Starling. The first thing you need to do once you’ve created an ActionScript project with Starling support (if you’re not sure how to achieve this check out this article), is create an instance of the Starling core engine.

var _st:Starling = new Starling(AnimationExample, stage);
_st.start();

As you can see, when creating the main Starling() instance you need to provide it with two parameters (it does takes additional parameters but we’ll skip over those for the time being). The first parameter is the root class you want to instantiate when Starling starts up, in this case it is AnimationExample. The second parameter is the location where you want to attach the root class instance. In this example we’re just going to target the main stage instance.

With that done all that is left now is to tell Starling to actually run, and you have probably already worked out how that is done. You just call the start() method on your Starling instance. With those two lines of code in place your main game class is complete (well for this demonstration at least), and it should look similar to this:

package
{
	import flash.display.Sprite;
	
	import starling.core.Starling;
	import com.flashgen.examples.AnimationExample;

	public class Starling101 extends Sprite
	{
		public function Starling101()
		{
			var _st:Starling = new Starling(AnimationExample, stage);
			_st.start();
		}
	}
}


Creating The Main Game Class

You may have noticed I deftly omitted anything to do with the creation of the main root class, AnimationExample, that we passed in to the Starling() constructor. That’s because I wanted to cover off a particular requirement of Starling. That requirement is that this class must inherit from Starling’s implementation of the DisplayObject class. Now just so you are clear, this isn’t the Flash DisplayObject, it’s the Starling implementation that goes by the same name. The most common implementation is to extend your class from the Starling Sprite class – which as you might gather extends the Starling DisplayObject class. So your base AnimationExample class would look something like this:

package com.flashgen.examples
{
	import starling.display.Sprite;
	
	public class AnimationExample extends Sprite
	{
		public function AnimationExample()
		{
			super();
		}
	}
}


You now need to create a method called init(). This is where you’ll be placing the bulk of your code for this example. The reason you’re not placing it in the actual class constructor is down to the fact that we want to make sure the class has been attached to the stage before anything gets processed. To do this the only thing that needs to be added to the AnimationExample class constructor is an event listener that waits until the class has been added to the main stage.

public function AnimationExample()
{
	super();
			
	addEventListener(Event.ADDED_TO_STAGE, init);
}


One thing to reiterate here is that the event we are listening for isn’t the flash.events.Event implementation it is the Starling implementation i.e starling.events.Event. I know I’m banging on a bit about using the Starling implementations of certain classes, but if you accidentally use the Flash implementation you will get errors.

Adding Assets

Starling differs from Flash in the way you commonly animate content in a couple of ways, but the main one is that it primarily uses texture atlases and sprite sheets* to render, and animate, visual content.

Texture huh? Sprite what!?
Texture Atlases and Sprite Sheets are fairly similar. Both revolve around a single large image that contains numerous smaller images. However they differ mainly in the scope of the content they contain.

A sprite sheet traditionally only contains the graphical information for an individual sprite type – a soldier, for example – and includes all of the frames of animation it may need.

Texture Atlases on the other hand generally contain all of the graphical information required for an entire game, (or if the game is particularly large for each individual level), including the sprites, static assets etc. They also tend to utilize a text file (normally XML), or “atlas”, to indicate where each item is located within this single large image. By using the data in the text file it is easy to extract the items you need; and if done quickly enough you can animate something by swapping the current frame for the next frame in the sequence.

I’ve already created a sprite sheet and the associated XML file using an app called TexturePacker (http://www.texturepacker.com/). I’m not going to go into details on how to use this app in this article – I’ll save that for a dedicated post. The main thing to be aware of is how the two parts (the PNG sheet and the XML file) relate to each other. As I mentioned earlier, the XML file contains a reference to each item in the sheet and provides the x, y, width, and height of each sprite as you can see:

    
    
    
    



However, before we get ahead of ourselves let’s look at how you actually reference both of these files in your game. The first thing you need to do is embed both of these files using [Embed] metadata. One thing to make sure you don’t forget is to set the correct mime type for the XML file (mimeType=”application/octet-stream”). If you forget to include this in your XML file embedding code you’ll get an error and it won’t compile. You don’t need to set the mime type for the PNG sprite sheet though. You code will now look similar to this (obviously the path to your assets may be different)

public class AnimationExample extends Sprite
{
	[Embed(source="assets/spritesheets/Bilbo-walk.xml", mimeType="application/octet-stream")]
	private var AnimData:Class;

	[Embed(source="assets/spritesheets/Bilbo-walk.png")]
	private var AnimTexture:Class;
		
	public function AnimationExample()
	{
		super();
			
		addEventListener(Event.ADDED_TO_STAGE, init);
	}
	
	protected function init(e:Event):void
	{

	}		
}


Once you’ve embedded your sprite assets you need to actually create a reference to them. To do this you need to create an instance of both of these within the init() method. To work with the sprite sheet you need to create an instance of the Starling Texture() class and pass the data from the sprite sheet to this variable:

protected function init(e:Event):void
{
	var _t:Texture = Texture.fromBitmap(new AnimTexture());
}


Notice that you use the static method Texture.fromBitmap() to grab the PNG file instance and assign it. The Starling Texture() class has other “from…” methods, which we’ll be exploring in later articles. Creating an instance of the XML file is pretty simple, you just need to make sure you cast the instance of the XML file as XML() – this is because we’re using the generic Class() class as the data type for both embedded files and to make sure the XML file is assigned correctly you need to cast it.

protected function init(e:Event):void
{
	var _t:Texture = Texture.fromBitmap(new AnimTexture());
	var _d:XML = XML(new AnimData());

}


Now that you have both of these variables you need to combine both parts to create something that Starling can work with behind the scenes. To do this you need to create an instance of the Starling TextureAtlas() class. This creates the relationship between both the sprite sheet and the XML data file that contains the positions of each sprite in that sheet.

protected function init(e:Event):void
{
	var _t:Texture = Texture.fromBitmap(new AnimTexture());
	var _d:XML = XML(new AnimData());
			
	var _ta:TextureAtlas = new TextureAtlas(_t, _d);
}


Making It Move

So far we’ve just been looking at how to set up Starling ready to render content for us. Let’s now look at how you actually get it to render to the screen, so you can actually see your sprites. As I have mentioned throughout this article, Starling has implementations of common Flash API classes and one of those is the MovieClip() class. However, its set up and usage is slightly different (as you would probably expect), compared to the Flash equivalent. When creating an instance of the Starling MovieClip() class.

protected function init(e:Event):void
{
	var _t:Texture = Texture.fromBitmap(new AnimTexture());
	var _d:XML = XML(new AnimData());
			
	var _ta:TextureAtlas = new TextureAtlas(_t, _d);
			
	var _mc:MovieClip = new MovieClip(_ta.getTextures("Bilbo"), 30);
}


Notice that you use your TextureAtlas() instance and call the getTextures() method to retrieve the sprites you want to associate with your MovieClip() instance. You can see that the getTextures() method takes a string that relates to the prefix used in the XML files name attribute:




This provides a mechanism to access elements contained within a single PNG and may relate to different parts of the games visuals. There is a second, optional, parameter you can provide on instantiation, which is the frame rate you wish the MovieClip() to render at. In this example, it is set to 30fps and this can be different to the main game frame rate. All you need to do now is add the MovieClip() instance to the Starling display list as the completed code shows, and test it out.

protected function init(e:Event):void
{
	var _t:Texture = Texture.fromBitmap(new AnimTexture());
	var _d:XML = XML(new AnimData());
			
	var _ta:TextureAtlas = new TextureAtlas(_t, _d);
			
	var _mc:MovieClip = new MovieClip(_ta.getTextures("Bilbo"), 30);
			
	addChild(_mc);
}


Hmm, Is This Broken?
Now if you tested this and Bilbo appeared on screen but wasn’t moving and you’re not sure why–don’t panic. You haven’t missed anything out – it is working as expected. You see, while the MovieClip() instance may have everything it needs to animate you need to use a different mechanism to update the frame it uses on each render cycle. To do this you need to use a Juggler. A juggler (as the name implies) juggles the frames of animation updating it each cycle. Don’t worry if this sounds a bit strange as it will become second nature once you’ve implemented it a few times.

The easiest way to implement a Juggler is to use the one that is part of the main Starling() instance. To access this, you just need reference the Starling() instance and add your MovieClip() instance to the Juggler associated with it.

protected function init(e:Event):void
{
	var _t:Texture = Texture.fromBitmap(new AnimTexture());
	var _d:XML = XML(new AnimData());
			
	var _ta:TextureAtlas = new TextureAtlas(_t, _d);
			
	var _mc:MovieClip = new MovieClip(_ta.getTextures("Bilbo"), 30);
			
	addChild(_mc);

	Starling.juggler.add(_mc);
}


Now if you save the file and test it Bilbo will animate as you would expect.

Summary

In this article you’ve seen how you can start using the Starling framework and how it differs (if only slightly) from animating content using the Flash API. You also saw how Starling works with sprites and textures and the common implementation workflow when working with these asset types.

Related Files
STR001-AnimatingSprites.zip

The post Rendering Sprites With Starling first appeared on That Mike Jones.