FS Studio Logo

Today I had a unique xCode scenario crop up that caused multiple files in my project to appear as missing (red in the project file list).  First, the scenario…the project is held in a git repo and development is done using a modified git-flow technique.  As such we are often merging feature branches in to the develop branch and vice versa.

 

After merging the develop branch in to a feature branch and then returning to the develop branch numerous source files appeared as missing.  I verified the files still existed on the filesystem, deleted the files from the project and added them back in with no change in file status in xCode, they still appeared missing.  I then deleted them again, re-added them to the project (still missing) and then tried to adjust the location setting of each file to be "Relative to Project".  This did not work either.   I made another attempt to add the files and then manually select the location of each file in the filesystem.  Although the files were there xCode still showed them as missing.

 

Seeing no other option than to re-create the project file by creating a duplicate project with a different name I came across a fix.  I created the new project and then proceeded to move all of the header files in to one of the new project's sub directories via the Terminal.  As soon as the header files were moved, all missing .cpp files in the original project showed up (file names turned to black from red).  I then moved the header files back to their original location on the filesystem and my original project was back in business.

 

I do not know what the underlying cause of this corruption was, but in the end the fix was to move the files out of their original directory on the file system and then move them back.  Hopefully this saves another developer time trying to figure out why xCode chose to incorrectly mark some files as missing

Are you getting a clang error that you can't track down?  "What the heck is 'clang: error: '-I-' not supported, please use -iquote instead'!?!"  Oh compiler gods please help this poor soul.  Well hopefully you haven't burned a day trying to solve this by tracking down project includes, compiler versions, and lord knows what else.  The answer turns out to be head-slappingly easy, you've got an unsupported character somewhere in the project path.  In our case we had something like this:

 

/Users/joeblow/Devel/Projects/WARU - Joe/testDir/waru/WARU.xcodeporj

[whitespace]

Notice the hyphen in there, that was the cause of all the pain.  The fix was simply to remove the hyphen:

 

/Users/timwmartin/Devel/Projects/WARU/testDir/waru/WARU.xcodeporj

[whitespace]

Hope this helps someone out there!

So you're an early adopter, good for you, although many times it can bite ya in the behind. Xcode is a fickle mistress and the latest release of Xcode 4.3 is no exception. If you're like me and you've got it installed and are cranking happily coding and debugging, you might have run into a strange phenomenon that the debugger doesn't seem to show the variables and their values correctly. This caused me hours of heartache because I was thinking that I had something messed up with my inheritance in my classes and sent me down a wild goose-chase trying to track down why my members weren't being initialized correctly. The it dawned on me, "hey I just updated to Xcode 4.3, I bet somethings up..." Ding ding ding, give the man a booby prize. The problem is the debugger and compiler settings. I changed my compiler to use the GCC compiler ("LLVM GCC4.2") and the debugger to GDB and all was right in the world the next time around. After playing with the settings a bit more, turns out I didn't need to change the compiler at all, just the debugger.

The short version of this post is, if you're having difficulties debugging in Xcode 4.3, simply set your debugger to the GDB and you're good to go.

Good luck and be safe out there!

When I get off my lazy butt, I'll add these to the resources page, but for now here are a list of great resources courtesy of https://www.vfr.org/

Blogs/Websites

Icons/Graphics

Code/Libraries

Just a quick entry to remind people that XCode 4.2 is a beta product and consequently there are certain behaviors that aren't supported, including creating an ipa file archive. When you attempt to create the .ipa, you will get a "file or directory not found" error.

We have an ongoing conversation about the best way to manage our code-base and repository in Git and have found the best solution is by using this branching structure:

https://nvie.com/posts/a-successful-git-branching-model/

 

You can help enforce this practice through good discipline and by using Git-Flow. If you're on a Mac you can use MacPorts or Homebrew. There's also a pretty decent screencast showing you how.

Some comments from our developers and friends:

Yes. Basically, we should be checking in only code that works to 'develop'. If you need to save your latest progress, you should just create your local git branches as many as you like and when you are ready, merge with your local 'develop' branch and then push the changes to the remote 'develop' repo.

ShortForm

We've been using git-flow at ShortForm for about a year now an we love it. The gitflow extensions are also very nice, save a lot of manual branching and tagging as per the process :

https://github.com/nvie/gitflow

There have also been a few moments where the process has broken down for us, but with git it's so easy to do things manually as well that it has not held us back in any way.

This should be titled, "oh XCode 4 why do you spite me so?". What have I done to deserve being smote by XCode? I ran into an couple issues with the latest version of XCode 4 when I tried to duplicate an existing target that was linked against a bunch of 3rd party libraries. One of the annoying things I ran into is that the new target was autonamed "[projectname] copy". You could rename the target, however internally it was still referred to as "[projectname] copy". You could not change the project id in the target settings and you had to live with this. That's a minor annoyance, what was worse was all my string paths referring to my library search paths got escaped so that the build would fail during the linking phase. So if you have this mystery problem, then go into you Target Build Settings > Library Search Path, then double-click on the path. Notice all your quotes have been escaped with a backslash. Delete those puppies and you'll be good-to-go.

Here's another good explanation:

http://web.archive.org/web/20111208225223/http://www.executionunit.com:80/2011/03/25/xcode-4-duplicating-a-target-to-make-an-ipad-build-link-error/

Be careful out there! XCode doesn't hate us, it just likes our attention and gets jealous when we don't spend enough time tinkering with it...

We had users reporting that the video playback wouldn't work on their iPhones

and iPods. With a testers help we found out, that the video playback in our

Tricktionary iPhone app didn't work on some iPod Touches and iPhones with 4.1

firmware (and probably older). The issue seemed also to be related to the

hardware as well, for instance 2nd generation iPods would not play the video.

The users were reporting that the video player would load, the controls would

appear, the progress bar would indicate playback, however the screen was blank

or black.

Was not easy to find out why exactly. Tests showed, that sample videos from

Apple worked when plugged in there, also the intro video was working most of the

time. We first changed the video encoding from H264 with MAIN 3.0 to Baseline

3.0 - this seemed to work at first, but we soon discovered that it would still

not work on iPhones or iPod Touches with FW 4.1 on. Scratching our heads, because

it was exactly the settings Apple suggested, we finally found out that the

problem was the encoder. Using Adobe Media Encoder CS4 before created the

not-working clips. Using Canopus Procoder with the same settings then helped the

issue, now the video features in our Windsurfing Tricktionary iPhone App are

working on all devices we could test them on (so far).

Unfortunately, Route-Me maps don't have access to the Google tiles (unless something has changed since this post). So if you want to have both Cloudmade's awesome implementation of the route-me OpenStreetMap maps and Google maps via MKMapKit, then you have to do some creative coding. The solution I came up with is to switch between the two views depending on which map type I wanted to display. Showing and hiding the RMMapView view and the MKMapKit view accordingly.  Cloudmade's CTO talks tech.

Now the trick is getting the maps to track each other and getting the correct scale/range/zoom for each of the maps as you navigate around. Here's what I came up with:

#define kMetersPerDegree 111000

if(mMapOptions.mapType == TTMapOptions_MapType_Trails) {

//set the center of the cloudmade map based on the MKMapKit's center

[mCloudmadeViewController.mapView moveToLatLong:mGoogleMapView.centerCoordinate];

//set the scale by taking the latitude distance in meters and dividing it by the width of the view in pixels

// scale = meters/px

float scale = (mGoogleMapView.region.span.latitudeDelta * kMetersPerDegree) / mGoogleMapView.frame.size.width;

[mCloudmadeViewController.mapView.contents setMetersPerPixel:scale];

[mCloudmadeViewController.mapView.markerManager removeMarkers];

[mCloudmadeViewController refreshMap];

[mCloudmadeViewController setMapSource]; } else {

//switching back to google maps from Cloudmade

RMMapView *mapView = mCloudmadeViewController.mapView;

//get the upper right and lower left coordinates

RMSphericalTrapezium trap = [mapView.contents latitudeLongitudeBoundingBoxForScreen];

//determine the deltas

CLLocationDegrees latitudeDelta = trap.northeast.latitude - trap.southwest.latitude;

CLLocationDegrees longitudeDelta = trap.northeast.longitude - trap.southwest.longitude;

//set the span and region MKCoordinateSpan span =

MKCoordinateSpanMake(latitudeDelta, longitudeDelta);

MKCoordinateRegion region = MKCoordinateRegionMake(mapView.contents.mapCenter, span);

[mGoogleMapView setRegion:region];

So this post will be short and sweet. Have you ever been annoyed or flummoxed by dialog boxes that pop up for an application while you're switching between spaces in Mac OS X? For instance you're making a build, you switch spaces to one with your e-mail so you can check your e-mail. Only to have a modal pop-up dialog appear that somehow get's lost in the Spaces ether? You try to interact with the app that's now modally disabled only to get that annoying system beep. Alright here's the quick fix, simply hide the app and un-hide it. The dialog will appear, you can dismiss it, and life can go on.

Hopefully this will make life a little brighter for you and keep you from kicking the dog or scaring your cube-mates with crazed ranting. That is all, move along... 😉

crossmenu