First iPhone App – LDS Gems

By brad | Published: May 8, 2010

After a bit of work, I finally got my first iPhone app on the App store. It’s nothing extraordinary, but was a learning experience for the most part. It’s called LDS Gems, and is an easier way to manage, read, and share the quotes and stories provided by the LDS church at http://gems.lds.org.

I used Titanium Appcelerator to build it, and was really impressed with how much easier it was to develop using Javascript as opposed to Objective-C. This is probably due to having quite a bit more experience with Javascript than the later, but I really enjoyed it and would recommend it to anyone wanting to dive into iPhone App development, but not ready to take on learning Objective-C.

  • del.icio.us
  • Digg
Tagged , | 3 Comments

Doctrine Model Hydration

By brad | Published: March 30, 2010

I was just deep into figuring out what was causing a certain bug and wanted to take the time to share my findings. When working with Doctrine we were having some scattered issues of models that we had loaded from the database, modified, and then they were getting stomped on by the database again before saving, wiping out all modifications we had made. In this particular case we changed one attribute of a model, then called save. Our save triggers some validation that checks quite a few relationships and business rules between them. Somewhere in that process, a new copy of the model we were trying to save was being hydrated from the database, and overwriting our previous version. This seemed like pretty odd, and unwanted behavior, especially in our situation.

After digging around Doctrine’s documentation and user group a bit, I came across an attribute setting that enables/disables this exact feature, Doctrine::ATTR_HYDRATE_OVERWRITE. By default this is set to true. If you hydrate a model from the database, and then somewhere later grab that same model through a reference, or a request to the Doctrine_Table, it will overwrite the model that is currently in memory for that key with a clean one from the database. Setting this attribute to false was a great fix for us, and ensures our code will run as intended.

$doctrine = Doctrine_Manager::getInstance ();
$doctrine->setAttribute ( Doctrine::ATTR_HYDRATE_OVERWRITE, false );
  • del.icio.us
  • Digg
Tagged , | Leave a comment

Getting keycode values in Javascript

By brad | Published: September 16, 2009

I’ve had to work with getting user input values based off of the keycode from the event a few times, and figured I’d throw together some of that functionality in case anyone else is wrestling with this functionality. Below is a simple “keycode” object that has a few utility functions, and maps of values to keycodes.

keycode = {

	getKeyCode : function(e) {
		var keycode = null;
		if(window.event) {
			keycode = window.event.keyCode;
		}else if(e) {
			keycode = e.which;
		}
		return keycode;
	},

	getKeyCodeValue : function(keyCode, shiftKey) {
		shiftKey = shiftKey || false;
		var value = null;
		if(shiftKey === true) {
			value = this.modifiedByShift[keyCode];
		}else {
			value = this.keyCodeMap[keyCode];
		}
		return value;
	},

	getValueByEvent : function(e) {
		return this.getKeyCodeValue(this.getKeyCode(e), e.shiftKey);
	},

	keyCodeMap : {
		8:"backspace", 9:"tab", 13:"return", 16:"shift", 17:"ctrl", 18:"alt", 19:"pausebreak", 20:"capslock", 27:"escape", 32:" ", 33:"pageup",
		34:"pagedown", 35:"end", 36:"home", 37:"left", 38:"up", 39:"right", 40:"down", 43:"+", 44:"printscreen", 45:"insert", 46:"delete",
		48:"0", 49:"1", 50:"2", 51:"3", 52:"4", 53:"5", 54:"6", 55:"7", 56:"8", 57:"9", 59:";",
		61:"=", 65:"a", 66:"b", 67:"c", 68:"d", 69:"e", 70:"f", 71:"g", 72:"h", 73:"i", 74:"j", 75:"k", 76:"l",
		77:"m", 78:"n", 79:"o", 80:"p", 81:"q", 82:"r", 83:"s", 84:"t", 85:"u", 86:"v", 87:"w", 88:"x", 89:"y", 90:"z",
		96:"0", 97:"1", 98:"2", 99:"3", 100:"4", 101:"5", 102:"6", 103:"7", 104:"8", 105:"9",
		106: "*", 107:"+", 109:"-", 110:".", 111: "/",
		112:"f1", 113:"f2", 114:"f3", 115:"f4", 116:"f5", 117:"f6", 118:"f7", 119:"f8", 120:"f9", 121:"f10", 122:"f11", 123:"f12",
		144:"numlock", 145:"scrolllock", 186:";", 187:"=", 188:",", 189:"-", 190:".", 191:"/", 192:"`", 219:"[", 220:"\\", 221:"]", 222:"'"
	},

	modifiedByShift : {
		192:"~", 48:")", 49:"!", 50:"@", 51:"#", 52:"$", 53:"%", 54:"^", 55:"&", 56:"*", 57:"(", 109:"_", 61:"+",
		219:"{", 221:"}", 220:"|", 59:":", 222:"\"", 188:"<", 189:">", 191:"?",
		96:"insert", 97:"end", 98:"down", 99:"pagedown", 100:"left", 102:"right", 103:"home", 104:"up", 105:"pageup"
	}

};

Typically, you would have an event listener on an input that would call keycode.getValueByEvent(). You would have to pass in the event, (which is by default the first parameter passed into your event listener function). This code handles the shift key modifier and the value that results from using it.

  • del.icio.us
  • Digg
Tagged | 3 Comments

Scoping Javascript closures in loops

By brad | Published: January 23, 2009

It must have been something I ate, cause this is like the third post in 2 days I think! This is a quick one, but super handy to know if you don’t already. There is semi-common problem I run into, and it has to do with scoping of closures inside of loops. Lets get straight to the code so its easier to understand what I’m talking about:

<html>
<script type="text/javascript" src="http://yui.yahooapis.com/2.6.0/build/utilities/utilities.js" ></script>
<script type="text/javascript">
	var values = [0,1,2,3,4,5,6,7,8,9];
	for(var idx in values) {
		//First Test - will have incorrent scoping
		YAHOO.util.Event.addListener(window, 'load', function() {
			YAHOO.util.Dom.get('wrong-scope').innerHTML += ' '+values[idx]+' ';
		});
		//Second Test - scoping will be correct
		YAHOO.util.Event.addListener(window, 'load', function(scopedValue) {
			return function() {
				YAHOO.util.Dom.get('right-scope').innerHTML += ' '+scopedValue+' ';
			}
		}(values[idx]));

	}
</script>

<body>
<div id="wrong-scope">
<h1>Wrong Scope</h1>
</div>
<div id="right-scope">
<h1>Right Scope</h1>
</div>

</body>
</html>

In this example, there is a simple array of ordered values, and then a loop over those values. For each iteration of the loop, there is an onload listener added that will dump that value into a div. You’ll see the first loop always dumps 9, because the scoping is wrong when the closure executes, and the last time through the loop sets the scope of values[idx].

The second section does some unique handy-work to correct the scoping. A listener is added like before, but the closure is created in a specific fashion in order to get the scope to be the way we want at runtime. For the closure in the second section, we create a function, and immediately execute that function, passing in a parameter that is the current value in our array of numbers. That function runs, and returns another function that does the appending to the div of the value. This second, inner-function is what will execute on page load. Because of the outer-function we immediately called, the variable passed into it, the current value from our array, will be available, and properly scoped for our inner-function.

scoping

This is a handy trick when you have a situation where you are looping over a collection, and are providing some type of callback/closure for each entry, but need some proper scoping.

  • del.icio.us
  • Digg
Tagged , , | 1 Comment

Browser autocomplete and keyup events

By brad | Published: January 23, 2009

Browser oddities are nothing new, but I came across one today that I haven’t heard about before, and couldn’t seem to find many comments about on the interwebs. To get to the gist of it, when the native browser autocomplete functionality pops up for a text input, it also triggers a keyup event for the input. I had some logic going on where I was firing an ajax lookup request as a user types in a value, and was waiting for a delay in their typing to fire the ajax request. I noticed I would often get two events fired at almost the same time. At first I chalked it up to oddities with setTimeout() not being completely accurate, but with more investigation, the native autocomplete that the browser supplies was the culprit.

To try this for yourself, here is the test code I was using:

<html>
	<script type="text/javascript">
		function handleEvent() {
			document.getElementById('keyup-test').innerHTML += document.getElementById('test').value + '<br />';
		}
	</script>
<body>
	<form action="">
	<div id="keyup-test"><h1>Test Keyup Event</h1></div>
	<input type="text" id="test" onkeypress="handleEvent();" value="bradharris" />
	</form>
</body>
</html>

You’ll see the current value of the input written out into a div above the input on each keyup event. To get the autocomplete functionality of the browser working, just type in a value, and then submit the page by pressing enter when the input is focused. The browser will then have that entry in its history of values for that input, and will start firing the keyup an extra time when it finds a match and shows the autocomplete box. To turn it off, just add autocomplete=”off” to the input tag, then it should only fire once per keyup. I’m pretty perplexed as to why this exists, and I’ve seen it in IE7 and Firefox3 (Linux and Windows). If anyone knows why its around, I’d love to hear.

  • del.icio.us
  • Digg
Tagged | 1 Comment