Objective-C Programming, Chapters 1-11

I just wrapped up Chapters 1-11 of the book I am working through named Objective-C Programming.  I am really enjoying the book.  The first 11 chapters of the book are all about the language C.  I am so excited about several things I get in C.

• Explicit memory management
• Getting memory pointer reference values in code
• Bigger numbers 
• Access to tons of already written C code

A few things I am struggling with

• Pointers vs variables
• When / how to use *
• When / how to deference objects and the heap

I am sure I will figure those out as I progress further down the path.  The combination of the Stanford U iOS videos, working on my own iOS project, and working through this book it really doing the trick for me.  Whenever I feel like I am 'getting it' I go work on my project for a while till I hit a roadblock.  Then I am motivated to slug through the documentation page-by-page filling in the gaps.

I think I am going to love this.  I know I am going to love knowing more about C.

More Objective-C and iOS

Ok, so I am loving this new book I got on Objective C.  It is called Objective-C Programming by Aaron Hillegass by The Big Nerd Ranch.  Just what I was looking for.  Working through it now; baby steps.

http://www.amazon.com/Objective-C-Programming-Ranch-Guide-Guides/dp/0321706285/ref=ntt_at_ep_dpt_2

Native iOS

As many of you know I have been a big fan of the Flash Platform for more then a decade. I fully embraced and evangelized AIR for Android and AIR for iOS. It just made sense, and worked. All the being said, once I got into the details of developing for iOS with Flex I found many things lacking, mostly performance, and the workflow.

I am making the jump and going to learn native iOS development. Here is where I started:

Cocoa Fundementals: http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CocoaFundamentals/Introduction/Introduction.html#//apple_ref/doc/uid/TP40002974

I read through most of that, and then took a break to watch this video series: http://www.stanford.edu/class/cs193p/cgi-bin/drupal/

I am finding that the Apple world has lots of silly names for things, like Quarts, Darwin, Bonjour, etc. It is like stepping onto an island where developers have been building their own fairy tale world for the last 20 years. I am hoping that after I get past the fairy dust I will start to make correlations to other things I know about software development.

So far the good news, for me, is that Cocoa development is done in an object-oriented way, and I have pretty good understanding of developing that way. Also, the notion of MVC seems to be an option for development - may even be prescriptive - I am fine with that. I have not yet found / heard about how to do dependency injection, however.

Back to learning!

Swiz Extension - SignalCommandMap (Part 3)

Unlike me, I have been sticking with writing this Swiz extension. Often I get distracted by other shiny objects, however, with this project I really see some long term benefits in the from of me writing better code, faster. That is keeping the light burning for me.

I have made update to both the example project and the SignalCommandMap. This update adds the ability to map a Signal class type directly to a Command class type. No need to make an instance of the Signal you want to map. Also no need to register the Signal with Swiz. That is done by the SingalCommandMap class.

Signal to Command Mapping

There are two gains that really appreciate the gains in being able to map directly to a Signal class type.

• One - No need to inject the signal into the command map
• Two - No need to add the Signal to the list of 'bean' in the Swiz config

Example: Swiz Single Command Map (rt-click to view source)



Here is the Code!
Link to the Swiz extension (note: dependencies on both Swiz and AS3Signals)
https://github.com/jayfour000/swiz-extension-SignalCommandMap

Link to a very simple example project (note: dependencies on Swiz, AS3Signals, and swiz-extension-SignalCommandMap)
https://github.com/jayfour000/swiz-examples-SwizSignalCommandLogin

Please post back with any questions or comments you have.

--jason

Swiz Extension - SignalCommandMap (Part 2)

Building on the topic in my last blog post I have written a new extension for Swiz.  It is based off of Joel Hooks' SignalCommandMap for RobotLegs, and the CommandMap already in Swiz written by Ben Clinkenbeard.  It takes advantage of the AS3Signals project written by Robert Penner.  It is really not a new idea, just filling a gap in Swiz for those of us who love command maps, but dislike events.  I have basically just mashed up two classes written by folks much smarter then I.

It is a work in progress at this point, but the main functionality is written; and working.  I have also have written unit tests to cover about a quarter of the functionality, so far :).

I was inspired to write this extension for Swiz after struggling with Events on my last project.  My workmate Jeff Roberts turned me on to the command map pattern and the CommandMap feature of Swiz.  I fell in love with the way commands enforce good encapsulation practices, are easy to test, easy to digest, and easy to refactor.  The commands are also transient.  That means that they are created, and destroyed, every time the signal that is mapped to the command is dispatched.  This removes the possibility for bugs related to state not getting properly reset that sometimes arise when using a state-full controller.  It also helps mitigate certain types of race conditions and memory issues, in my opinion.

One thing I really did not like about the existing CommandMap in Swiz was that I had to create a new event for about every third command I wrote.  I had to add all the properties I wanted to send along as a payload to the command.  It was kinda a pain, extra code, and just a another chance to make a typo.  I also did not like having to follow the event chain backwards in the stack when  when I would hit a runtime exception.  Sometimes I would just not be able to tell where the RTE was happening at.  My hope is that AS3Signals will solve some of these problems for me :).

Having written several 2000+ line mega-controllers in my past I found the command map pattern completely refreshing.  The command map pattern is especially refreshing after the honeymoon period is past on a project (i.e. nine months into the project when everything needs to change and refactoring takes longer then it would to rewrite the whole damn thing).

Here is the Code!
Link to the Swiz extension (note: dependencies on both Swiz and AS3Signals)
https://github.com/jayfour000/swiz-extension-SignalCommandMap

Link to a very simple example project (note: dependencies on Swiz, AS3Signals, and swiz-extension-SignalCommandMap)
https://github.com/jayfour000/swiz-examples-SwizSignalCommandLogin

Please add any criticisms you have to the comments section below.


Example: Swiz Single Command Map (rt-click to view source)


--jason

Swiz + AS3Signals = SignalMap (Part 1)

I really like Swiz.  It works great with Presentation Models.  It generally just gets out of my way.  I have been using the Swiz Command Map in lue of Mediating events for my last few projects.  It is nice to have the logic broken down in to little single-purpose commands.  The Services and PMs communicate to the Commands by dispatching an event on the global event dispatcher.  The events are mapped to the commands in the Command Map.

The last bit of that kinda irks me.  I don't like creating tons of events and mapping them to commands.  I end up writing much more boiler-plate code then I would like.  Creating the new event classes takes time.  Writing the code to dispatch the events also takes time and space.  It also can create some annoying stack traces when I have to dig back through events.

In a past life I used callbacks in lieu of the event system in Flash with pretty good success.  It was kinda odd at the start, but then I got used to it.  I also have been in love with AS3Signals for some time now, but have not used it much on Flex projects, just pure AS3 ones.

I set out to cut out the .events.* package from my recent standard architecture and replace them with Signals.  One of my goals was to not just end up having to create n number of Signal classes to replace the previous Event classes.  I like what I ended up with so far.  I dumped the Command Map entirely and replaced it with a Signal Map.  I also got rid of all the custom events :).

The big loss is that I do not get strong typing for the properties I want to send along as the payload from the Service, or PM, to the Command like I did with Events.  To be honest, however, I often just had the 2nd or 3rd params of my Events something like data:Object that I would just jam full of whatever data I wanted to send long .. because I was too lazy to make a new event.  Maybe not even lazy; it just interrupted my flow.

Here is a test project I made that follows this pattern.  You can see that I am playing around with the most efficient way to declare a Signal.

EDIT - this was crap.  I deleted it and rewrote it.
https://github.com/jayfour000/IoC-Swiz-SignalMap/tree/master/src
https://github.com/jayfour000/swiz-extension-SignalCommandMap
https://github.com/jayfour000/swiz-examples-SwizSignalCommandLogin

Let me know what you think.  Let me know if you see any issues with scaling, particularly compared to the Swiz Command Map.

I have heard that the Swiz Command Map creates a new instance of the command each time an event fires.  I don't think that AS3Signals can do anything like that, I am also not sure of what impact that will have on memory in a large application if the commands are not garbage collected after they run .. or if I will run into race conditions or state issues.  Thought on this?

snipt.net

I just started using snip.com. I like it. I am going to try posting code there for a while and see if it works out. Posting code in the blog WYSIWYG interface is always so painful. Check out my first snip!

http://snipt.net/jayfour000/pass-param-vs-ref-class-property