Behemoth: xcode4

Showing posts with label xcode4. Show all posts

Sunday, August 21, 2011

Adding Core Data to an already existing XCode4 project

The mechanism to add the model is simple:
```
Ctrl+Click > New File > Core Data > Data Model > Next > Save
```
but this only works if you Ctrl+Click on the project!
- If you Ctrl+Click anywhere else, for example lets say on the Resources folder, then you will get a useless .xcdatamodeld file which simply won't open in the editor.
- So make sure to add the model file by Ctrl+Click(ing) on the project name and nothing else.
- Beware, if try to move it to an appropriate location like Resources at a later time, it will stop working again. After the move, once again, no editor will come up if your try to re-select the .xcdatamodeld file.
- You must have it directly under the project in order to be able to work with it.

Monday, August 8, 2011

Versioning iPhone App: Beta & Production Builds

A little bit of Google search yields the following great resources to help get started in the arena of versioning your iOS apps:

In this blog entry, I'll:

attempt to provide the grand total of everything I learned from these articles which are based in XCode3,
provide instructions on how to do the same in XCode4, and
explain some of the finer points which weren't clear to me without trial & error.

This snapshot shows how to add apple generic versioning to your XCode4 project.

Open YOUR_PROJECT in XCode 4 and navigate to YOUR_PROJECT > Targets > YOUR_PROJECT > Summary > iOS Application Target > Version
Even though it may seem intuitive to think so but this is NOT the version number that the iPhone app users will see.
Instead this is an internal build number that you can increment as many times as you like and whenever you deem appropriate. Follow the links at the top to learn more.

You can easily comfirm this by attempting to edit this property in YOUR_PROJECT > Target > YOUR_PROJECT > Info (maps to YOUR_PROJECT-Info.plist file) > Custom iOS Target Properties > Bundle Version
and then confirming that the change took effect again in Summary > iOS Application Target > Version

If you Ctrl+click and ask it to Show raw keys/values

Then you'll notice that this maps to the key: CFBundleVersion
If you would eventually like to build your "About" page in the app and format a string that shows up something like version 0.1.0 (build 42), where 42 will correspond to the value of CFBundleVersion, then instead of giving it an initial value like 1.0, I would suggest setting it to 1

So now what corresponds to the 0.1.0 part of the version 0.1.0 (build 42) in your about page? Well, the Bundle versions string, short property with the raw key value of CFBundleShortVersionString would make up the 0.1.0 piece of that string.

And could this 0.1.0 be the version # that is displayed as your app's version in the App Store? Yes! this is known as the marketing version and it is what shows up to the users of the App Store.
What's up with the x.y.z version structure? As one of the links in the beginning explains, X - major revision number, Y - minor revision number, Z - maintenance or patch release. This is a very nice & simple concept to use.
Why should the starting of an App's marketing version be from 0.1.0? Because an application would like to enter the App Store as 1.0.0, so you don't want to use 1 as your major (X) version in the very beginning when you are probably in the process of distributing Ad-Hoc builds for alpha/beta testing. 1 as your minor (Y) version makes sense 0.1.0 because your app starts with the smallest set of features and then grows to perhaps 0.2.0, 0.3.0 and so on. Also the 0 as your patch (Z) version makes sense because there is nothing for you to patch at the very start. In conclusion: minor.major.patch is conveniently 0.1.0 for starters.
Here's what my email notification message looks like when I use TestFlightApp to publish beta builds to testers: v0.1.0 (4) of ShoppinPal is ready for a TestFlight
To check your CFBundleVersion via Terminal, use:
```
agvtool what-version
```
All the following commands increment CFBundleVersion by 1 but do nothing to CFBundleShortVersionString:
```
agvtool next-version
agvtool next-version -all
agvtool bump -all
```
To check your CFBundleShortVersionString via Terminal, use:
```
agvtool what-marketing-version
```
To change CFBundleShortVersionString, you will yourself have to understand if the change is major, minor or patch and then use:
```
agvtool new-marketing-version 0.2.0
```
With XCode4 there really shouldn't be any good reason not to use Git so remember to commit to the repository every time after you change the version. Perhaps even take the time to tag the repo so that you can pull the exact source for debugging if someone ever reports an issue against a specific version/build #

Sunday, July 31, 2011

IBAForms: An Engaging Experience

I recently found out about IBAForms, which is an Objective-C framework for easily building forms for the iPhone. I liked it a lot so I thought I'd make it tad easier for other beginners like myself:

I've uploaded How To Use IBAForms Part 1 of the screencast where I cover the basics of importing IBAForms so that you may begin using it. Relying on the screencast isn't necessary as the Adding IBAForms to your project section of the README covers the same content but it may help to watch it in action.
Here's one of the commands used in the screencast, used in the Terminal, which you may find a little bit more helpful than pausing the screencast and trying to visually copy it from there:
```
git submodule add https://github.com/ittybittydude/IBAForms.git IBAForms
```
In case you find the submodule approach less than desirable, feel free to remove it.
In How To Use IBAForms Part 2 screencast, you'll get more hands-on instructions on how to actually start adding the form fields.

When in doubt head over to the user groups for IBAForms.

Wednesday, July 20, 2011

Using Git, XCode4 and Unfuddle together

With XCode4 supporting Git out-of-the-box it is highly encouraging to know that any endeavor that you "the developer" might embark on ... will benefit from a default development branch (on your local box) known as master repository (unless you explicitly de-select a checkbox in XCode4 when creating your project).
As your single-developer project gains a coherent enough form for you to want to share it with other developers ... Unfuddle will pop into the picture because it provides: (a) Git hosting, and (b) it is free for upto 2 developers. This is the perfect setup for figuring out if Git and XCode4 are the right fit for you.

A lot of folks who make use of GitHub hosting (your source code is open to the world) seem to be concerned about how XCode4 doesn't live up to their expectations because it doesn't provide an automated process or any clear cut instructions for configuring and pushing the local master-repo over to a remote upstream repository (lets call it origin-repo) when this phase in their development life-cycle finally arrives.
Well the instructions over @ Unfuddle couldn't be more direct and clear-cut, they get the job done in under 10 minutes flat. They are suited exactly for a project where a local master-repo already exists and you want to push it to a remote origin-repo.
After the push setup is completed and your team member has cloned the origin-repo onto their own dev machine as a master-repo, you are ready to roll.

Lets say the n00b member makes a change to their local files. They can quickly find out what has changed using
```
git status
```
Now the n00b wants to commit the changes, then they can use
```
git commit -m "comment"
```
But wait, this only committed the changes to the local master-repo on the n00b's machine, next to get this pushed over to the origin-repo use:
```
git push git@subdomain.unfuddle.com:subdomain/abbreviation.git
```
... where subdomain and abbreviation must be replaced with values appropriate to your account and repository.
Now lets say you realize that it doesn't make much sense to have the *.xcodeproj files/folders under source control as their contents might differ based on the machine they are on, well then:
```
git rm --cached <file>
```
would remove file from version control, while keeping it in the working repository. And to avoid from ever mistakenly adding it back to source control, just add a .gitignore file and inside it put the expression to ignore the file/folder in question.
Then use
```
git commit -m "comment"
```
for putting the change into master-repo

And

git push git@subdomain.unfuddle.com:subdomain/abbreviation.git

for pushing the change to the origin-repo

Finally use
```
git pull git@subdomain.unfuddle.com:subdomain/abbreviation.git
```
to get everything back over to your own local master-repo

Some common tasks that may crop-up once you move to a multi-dev env could be simple things like wanting to rename the project. For XCode4 this was a particularly simple yet difficult find for me. Apparently according to Konstantin Salavatov: in XCode4 clicking on the project name after selecting it, starts the process of renaming it. This is absolutely correct.

Here's a set of links to keep close at hand for quick reference:
- http://www.arlt.eu/blog/2009/12/01/importing-iphone-keys-p12-and-pem-into-snow-leopards-keychain/
- https://git.wiki.kernel.org/index.php/GitCheatSheet

Tuesday, July 19, 2011

TestFlight Fever

I recently heard about TestFlight and I became extremely excited. Now having never done any ad-hoc distribution for iPhone apps in the past, I thought that I had hit the jackpot! I quickly signed up, sent invites to my team members and then rushed to upload a build ... so that everyone could start testing instantly :)

But oh boy was I in for a surprise. TestFlight became a victim of my false expectations:

False expectation # 1: I don't have to maintain the profiles for the folks that I invite for testing my app via TestFlight.
- WRONG! The 1st thing that TestFlight warned me about was the fact that it could not accept my build because I was probably using a distribution profile. Now since a dist-profile doesn't have a record for any of the devices from my team members, it wouldn't work. So TestFlight warned me about this and told me to go perform my build with an Ad-Hoc profile.
~~False~~ expectation # 2: TestFlight will clearly document and guide a novice like me how to setup an Ad-Hoc configuration in XCode4.
- UPDATE! They now prompt you with an informative link that will give you all the help you need.
- ~~WRONG! While they may make a welcome improvement in the future, I could not find any help on the immediate TestFlight site~~ ... but just like any good engineer of the Google-era I was able to find an excellent article on the web for it that got me past this hurdle.
False expectation # 3: Just this one time, I can get away by faithfully following the instructions of other folks and not having to bang my head bloody w/ trial & error.
- WRONG! The XCode4 + Ad-Hoc distribution configuration article got me off to a flying start but I quickly realized that I had no idea how to create an Ad-Hoc profile.
- After mucking about I figured out the steps are:
  - Goto iOS Provisioning Portal
  - Select Provisioning from the left pane
  - Select the Distribution tab from the right
  - Click the New Profile button
  - Make sure to mark the Ad Hoc bullet option as the distribution method.
  - Select all the Devices that can use this profile.
  - Download and install this new profile and prepare your build with it.
False expectation # 4: Any TestFlight teammates who accept their invites and whose devices weren't explicitly added as a part of the Ad-Hoc profile at the time of its creation ... will be injected into the Ad-Hoc profile auto-magically.
- SUPER WRONG! You have to go edit you Ad-Hoc profile and add the devices yourself. TestFlight does NOT commandeer your Apple provisioning account to do this for you.
- What TestFlight DOES offer us (the users) is the ability to easily collect the UDIDs of our fellow teammates. Think about it, having your teammates get an email that they open via their iPhone/iPad ... and which results in their UDID being shuttled over to a central location in TestFlight for easy collection is already a huge boon! Perhas the only boon one should be asking for :)
- Gone are the days of running around looking for a computer so that you can connect to iTunes and painstakingly jot down an impossibly long identifier.
- Anyways, make sure to add the UDIDs for all of your team members as they accept the invites and sign up. Collect them from TestFlight and go update your Ad-Hoc profile as & when needed ... by adding and then selecting the decives for inclusion by marking the checkboxes under the Devices section of the Ad-Hoc profile.

In conclusion TestFlight rocks out loud and hopefully I've covered any novice errors that would have otherwise prevented others from thinking likewise.

Behemoth