Skip to content

iOS Development Brain Dump

Apple developers must be really brilliant.  Developing the class of apps they do with the IDE that is known as XCode is a feat worthy of praise.

After XCode, I even miss Visual Studio!  Now that says a lot.  Below is a brain dump of some useful things I have found and don’t want to forget.  My non-technical readers can ignore this one!

XCode has a bug where it will show you the images it finds in your custom bundle and allow you to add them to buttons, but then when running the app, the images doesn’t show.  The trick is to manually put the bundle name in front of the image name.  It will show as broken in XCode, but will work (sort of) in your app.

See http://stackoverflow.com/questions/7733565/ios-how-to-use-images-in-custom-bundle-in-interface-builder

The following site has some nice examples on reusable views and sub-views:

See http://fdiv.net/2011/10/29/reusable-views-ios

Some shortcut links to help make XCode a little bit less frustrating:

http://cocoasamurai.blogspot.com/2011/03/xcode-4-keyboard-shortcuts-now.html

http://pragmaticstudio.com/media/Xcode4Shortcuts.pdf

Re-usable Subviews in iOS

One of the (many) frustrations I ran into programming i-devices was the simple task of creating re-usable subviews.  The idea is to use Interface Builder to design a panel that can be re-used later on any view, any number of times.

During my search, I ran into many ways to make this work, but none of them felt as straightforward as I expected this to be.  The instructions below is the approach that I found least “hack-ish” and with the simplest steps.  Until I find a better way, this will be the way that I use from now on.

I found this approach here and will describe how I did it, step-by-step.  The link does not have a step-by-step on how to do this, but does include a link to an example application that you can download.

Please note that the steps described here are for Xcode 4.2.

Step 1 : Create a new View (.xib) file (eg. TestSubView.xib).

Open the dialogue by right clicking on a folder in your project and selecting “New File”.

Step 2 : Create a new objective C class that extends UIView (eg. TestSubViewController.h and .m)

Open the dialogue by right clicking on a folder in your project and selecting “New File”.

 and 

Step 3 : Set TestSubView.xib file’s owner custom class to TestSubViewController

Step 4: Bind a reference of the View into the TestSubViewController.h

You do this by right click dragging from the word “View” under “Objects” into the TestSubViewController.h code.

Step 5 : Implement the “awakeFromNib” method in the TestSubViewController

-(void)awakeFromNib

{

[[NSBundle mainBundle] loadNibNamed:@”TestSubView” owner:self options:nil];

[self addSubview:self.contentView];

}

Make sure that “TestSubView” above is replaced with your .xib’s name and that self.contentView above is replaced by whatever you named your referencing outlet in Step 4

Step 6 : Use your view

To use your view, add a UIView panel to your view and set it’s class to TestSubViewController.  It shows as a blank panel in the interface builder that you can move and size, but will render the contents of your custom view at run time.

Ants, IDEs and Blaming the Tools

A good pattern in life is to start with the basics.  Yes, I know that is pretty, errr, basic knowledge to most people!

This holds very true for tools too.  You start learning how to cut wood with a plastic saw and fake wood when you are around two years old.  Then you move up to a hand saw which, when mishandled, can make you bleed.  Then only, should you move on to the wood ripping, finger removing table saw that can push your productivity through the roof.

Ashamedly, I have to admit that I started coding Java using the fully automated, computer controlled, coffee making table saw version of the Java world – the Eclipse Integrated Developent Environment (IDE).

As a result, I have taken a long time to catch up on some of the Java basics, such as the compile and build process.

I have also completely skipped the handsaw version of the Java world – Ant build scripts.

It has taken me several years (and several proverbial fingers) to realize how important these “simpler” tools can be.  Not to mention how much better they are suited to some tasks than the shiny high-performance machine that promises to do everything, cannot do well.

Having lost two days trying to sort out a tricky JEE project deployment in the JBoss application server, I finally capitulated, sat down for four solid hours and converted the whole build process to a set of Ant scripts.

Whilst the Eclipse IDE hides and automates a lot of complexity, it would also hides a bunch of control.  The Ant scripts gave me back that control and I managed to make them do what I could not get the Eclipse IDE to do.

Don’t get me wrong, I LOVE Eclipse.  Just like seeing a skilled workman working with that table saw can get you inspired to get into woodworking, Eclipse was the reason I got into Java programming.  The amazing refactoring capabilities and ease at which you can generate lines and lines of quality code is right up with the best of IDEs.  I am pretty sure that my failure to make my deploy work is entirely mine, and someone more proficient with the IDE will be able to solve it easily.

But that is the very reason for using the “simpler” tool.  If you are not skilled enough to use the high-end tool, you will probably do more damage trying (and lose more fingers).

So, learn from this old fool’s lesson: make time to learn the basics, however hard it is to find this time.  Then you will understand your tools much better and won’t have to resort to blaming them.

Now close that IDE, open your browser and go find out how you can put (those) Ant(s) to work!

An EAR Full (of JARs)

One of the long time frustraions I had with EAR (Enterprise Archive) projects in MyEclipse was adding module projects. (Ok, technically it’s an EAP – Enterprise Application Project)

To add a project to the EAR, you will usually do the following:

1. Right Click the EAR Project

2. Go MyEclipse -> Add and Remove Modules

3. Click on the Add button

4. Select the project you want to add.

Now this is where the problem occurs – sometimes a project will not show under the list of available projects to add.

The answer (in my case) turns out to be fairly simple and obvious.  Especially if you happen to know the answer!

The EAR project will not show projects that was created with a “higher” EJB spec than the EAR project.  The simplest way to fix this, is to upgrade the EAR project to be at least at the EJB spec level of the highest project you are trying to add.

To do this, go to the .mymetadata file (this file may be hidden and you may have to set your package explorer to show hidden files) in the root of the EAR project and search for the j2ee-spec attribute in the project-module tag.

Change that to the correct spec level (in my case I went from 5.0 to 6.0) and your other higher spec project should show up.

Of Bricks and Mortar

For many people I will be stating the obvious. But obvious, like common sense, is not as common as one may think.

Software developers work in a world where projects are run to bring about tangible outputs by manipulating tangible inputs.

To build a building you use bricks and mortar (or wood and other fuels) to bring about something you can see and touch. The modern world has fine tuned this process over hundreds of years to a point where a building can be designed, planned and built to fairly predictable costs and time lines using well established rules and guidelines.

Problem is, should you get this wrong, it’s very hard to “patch” your building’s “bugs” as you are working with large heavy physical “stuff”.

In the software world everything except the visual GUI is intangible. We don’t have tangible physical stuff to move around and manipulate – except for the mouse, keyboard and occasional cup of coffee.

This leaves some people thinking that software development is easy. Popular movies and TV series showing weirdo wizard hackers whipping up perfectly working code in seconds (on whirring and beeping computers nonetheless!) helps reinforce this notion.

What very few people realize is that our bricks and mortar many times have to be invented from scratch or at least heavily customized for what we need to achieve.

Our bricks have to be micrometer perfect or they can bring our whole building down. To compound our problems, I cannot hold the brick in my hand and see it’s obviously cracked.

Of course good software development practices are emerging to make software less fragile. This usually entails spending much much more thought on designing the bricks and mortar than maybe the building itself.

If we get this right, building and changing the “building” becomes much easier. Then you truly get the advantage of not having physical stuff to lug around. Extending our “building”, or adding that door becomes so much easier if the bricks and mortar was designed right. If not, the whole thing becomes a network of cracks and the smallest change can bring it tumbling down.

As our software bricks and mortar are totally abstract and intangible, it becomes hard to sell to a client things that he have spent thousands on and that can’t be seen yet. And then I have the gall to try and convince the client that these expensive intangibles are really important and he should be happy that I’ve spent so much time and money on it.

This places an enormous burden of trust in the developer on the client.

I look forward to the day when the software industry is governed by understood and accepted rules and guidelines such as in the building industry. It may remove a lot of freedom for us as developers, but will surely make our lives easier when it comes to selling the process to a client.

Then I’ll be less tempted to public violence when someone says : “… it should be easy to quickly change …”

Clients and Requirements

I guess I have to start this blog with something more substantial than blogging about starting the blog!  So I will start off with one of my all time favorite quotes regarding the software development process.  Aptly involving one of many programmers’ biggest nemesises (nemessii?) : clients and requirements.

The quote is from the excellent “Dive Into Python“,  a book I can gladly recommend for experienced Python developers and newbies alike.

Despite your best efforts to pin your customers to the ground and extract exact requirements from them on pain of horrible nasty things involving scissors and hot wax, requirements will change.

Blog Started

After procrastinating on this for literally years, I have finally been inspired by a good friend over at kaalvoetklonkie.wordpress.com to start a blog of my own.

I hope to blog about my experiences as a software developer and so capture all those valuable nuggets that can so easily get lost with time.

If nothing else, this blog will hopefully at least serve as a brain dump for myself which I can use in the future should my memory fail me.  A not to uncommon occurrence!